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

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

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

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

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

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

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

Наименование объекта закупки: На выполнение работ по развитию и оказанию услуг по технической поддержке Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте Информационно-аналитической системы регулирования на транспорте (АСУ ТК) в 2026 году

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

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

Номер типовых условий контракта: 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. Ответственное должностное лицо Заказчика: Теселкин В.А.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- 62.01.11.000 - Этап№1: Техническое проектирование ОКПД2: 62.01.11.000 ОПРЕДЕЛЕНИЯ, ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ Автоматизированная система (АС) Система, состоящая из комплекса средств автоматизации, реализующего информационную технологию выполнения установленных функций, и персонала, обеспечивающего его функционирование (ГОСТ Р 59853-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения») АРМ Автоматизированное рабочее место АСУ ТК, Система Информационно-аналитическая система регулирования на транспорте АТС Автоматическая телефонная станция БД База данных ГИС Государственная информационная система ГОСТ Государственный стандарт ГЦОД СИЦ Минтранса России, ГЦОД Головной центр обработки данных ФГБУ «СИЦ Минтранса России» Дашборд Интерактивная аналитическая панель, графический интерфейс. ЕИС Единая информационная система в сфере закупок ЕСИА Единая система идентификации и аутентификации Заказчик Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» КИИ Критическая информационная инфраструктура Кластер Кла?стер (англ. cluster) – объединение нескольких однородных элементов, которое может рассматриваться как самостоятельная единица, обладающая определёнными свойствами Компонент Часть АС, выделенная по определенному признаку или совокупности признаков и рассматриваемая как единое целое (ГОСТ Р 59853-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения») Контракт Контракт на выполнение работ по развитию и оказанию услуг по технической поддержке Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК в 2026 году, заключаемый по результатам проведения конкурентной процедуры закупки в соответствии с требованиями Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» ... 1. ОБЩИЕ СВЕДЕНИЯ 1.6. Перечень документов, требования которых должны быть учтены при выполнении работ – Федеральный закон Российской Федерации от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации»; – Федеральный закон Российской Федерации от 27.07.2006 № 152-ФЗ «О персональных данных»; – Федеральный закон Российской Федерации от 06.04.2011 № 63-ФЗ «Об электронной подписи»; – Федеральный закон Российской Федерации от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации»; – Указ Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации»; – Указ Президента Российской Федерации от 01.05.2022 № 250 «О дополнительных мерах по обеспечению информационной безопасности Российской Федерации»; – Указ Президента Российской Федерации от 31.03.2010 № 403 «О создании комплексной системы обеспечения безопасности населения на транспорте»; – постановление Правительства Российской Федерации от 30.07.2004 № 395 «Об утверждении Положения о Министерстве транспорта Российской Федерации»; – постановление Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации»; – постановление Правительства Российской Федерации от 16.11.2015 № 1236 «Об установлении запрета на допуск программного обеспечения, происходящего из иностранных государств, для целей осуществления закупок для обеспечения государственных и муниципальных нужд»; – постановление Правительства Российской Федерации от 23.12.2024 № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц»; ... 2. ЦЕЛИ И НАЗНАЧЕНИЕ ВЫПОЛНЕНИЯ РАБОТ 2.1. Назначение АСУ ТК АСУ ТК предназначена для автоматизации и информационно-аналитического обеспечения процессов управления развитием транспортного комплекса Российской Федерации, обеспечения публичности деятельности органов государственного управления транспортным комплексом. Основными целями АСУ ТК являются: – повышение эффективности процессов управления функционированием и развитием транспортного комплекса на основе создания единой информационной среды и комплекса информационно-аналитических услуг на уровне органов государственного управления ТК; – повышение уровня безопасности ТК на базе получения полной, достоверной и оперативной информации о происходящих изменениях, своевременного выявления негативных тенденций и для принятия соответствующих мер по их устранению и ликвидации последствий ... - Условная единица - 1,00 - 7 083 909,67 - 7 083 909,67

- Наименование характеристики Значение характеристики Единица измерения характеристики Инструкция по заполнению характеристик в заявке ОПРЕДЕЛЕНИЯ, ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ Автоматизированная система (АС) Система, состоящая из комплекса средств автоматизации, реализующего информационную технологию выполнения установленных функций, и персонала, обеспечивающего его функционирование (ГОСТ Р 59853-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения») АРМ Автоматизированное рабочее место АСУ ТК, Система Информационно-аналитическая система регулирования на транспорте АТС Автоматическая телефонная станция БД База данных ГИС Государственная информационная система ГОСТ Государственный стандарт ГЦОД СИЦ Минтранса России, ГЦОД Головной центр обработки данных ФГБУ «СИЦ Минтранса России» Дашборд Интерактивная аналитическая панель, графический интерфейс. ЕИС Единая информационная система в сфере закупок ЕСИА Единая система идентификации и аутентификации Заказчик Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» КИИ Критическая информационная инфраструктура Кластер Кла?стер (англ. cluster) – объединение нескольких однородных элементов, которое может рассматриваться как самостоятельная единица, обладающая определёнными свойствами Компонент Часть АС, выделенная по определенному признаку или совокупности признаков и рассматриваемая как единое целое (ГОСТ Р 59853-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения») Контракт Контракт на выполнение работ по развитию и оказанию услуг по технической поддержке Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК в 2026 году, заключаемый по результатам проведения конкурентной процедуры закупки в соответствии с требованиями Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» Значение характеристики не может изменяться участником закупки Модуль iМинтранс Модуль сбора данных и представления показателей деятельности Министерства транспорта Российской Федерации iМинтранс АСУ ТК Модуль СЦ Модуль сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК НС Нештатная ситуация НСИ Нормативно-справочная информация ОТИ Объект транспортной инфраструктуры П-ГИС Геоинформационная подсистема П-ИВ Подсистема информационного взаимодействия П-НСИ Подсистема ведения нормативно-справочной информации и метаданных ПО Программное обеспечение Подрядчик, Исполнитель Организация, с которой будет заключен контракт на выполнение работ по развитию Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК П-СД Подсистема сбора данных Работы Работы по развитию Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК СЗИ Средство защиты информации СМЭВ Система межведомственного электронного взаимодействия СУБД Система управления базами данных ТЗ Техническое задание (настоящий документ) ТС Транспортное средство ТК Транспортный комплекс Учреждение Учреждения в области информационной безопасности ФГБУ «СИЦ Минтранса России» Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации», Заказчик Федеральный закон № 44-ФЗ Федеральный закон от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» ФЗ Функциональная задача ФЗ «Реестр объектов» Функциональная задача «Формирование и ведение единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации» ФСБ России Федеральная служба безопасности Российской Федерации ФСТЭК России Федеральная служба по техническому и экспортному контролю ЧС Чрезвычайная ситуация ЭВМ Электронно-вычислительная машина API От англ. Application Programming Interface – интерфейс прикладного программирования – совокупность инструментов и функций в виде интерфейса для взаимодействия с программой CSS От англ. Cascading Style Sheets — каскадные таблицы стилей FPS От англ. frame per second - количество кадров в секунду HTML От англ. HyperText Markup Language - стандартный язык разметки документов, создающий основу и структуру всех веб-страниц JSON От англ. JavaScript Object Notation – текстовый формат обмена данными, основанный на JavaScript WebAssembly (Wasm) Открытый стандарт, представляющий собой низкоуровневый бинарный формат инструкций, который позволяет выполнять код, написанный на языках C++, Rust или Go, в браузерах с производительностью, близкой к нативной 1. ОБЩИЕ СВЕДЕНИЯ 1.6. Перечень документов, требования которых должны быть учтены при выполнении работ – Федеральный закон Российской Федерации от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации»; – Федеральный закон Российской Федерации от 27.07.2006 № 152-ФЗ «О персональных данных»; – Федеральный закон Российской Федерации от 06.04.2011 № 63-ФЗ «Об электронной подписи»; – Федеральный закон Российской Федерации от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации»; – Указ Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации»; – Указ Президента Российской Федерации от 01.05.2022 № 250 «О дополнительных мерах по обеспечению информационной безопасности Российской Федерации»; – Указ Президента Российской Федерации от 31.03.2010 № 403 «О создании комплексной системы обеспечения безопасности населения на транспорте»; – постановление Правительства Российской Федерации от 30.07.2004 № 395 «Об утверждении Положения о Министерстве транспорта Российской Федерации»; – постановление Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации»; – постановление Правительства Российской Федерации от 16.11.2015 № 1236 «Об установлении запрета на допуск программного обеспечения, происходящего из иностранных государств, для целей осуществления закупок для обеспечения государственных и муниципальных нужд»; – постановление Правительства Российской Федерации от 23.12.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 Федерального закона «Об электронной подписи»; – постановление Правительства Российской Федерации от 08.06.2011 № 451 «Об инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг и исполнения государственных и муниципальных функций в электронной форме»; – постановление Правительства Российской Федерации от 30.01.2013 № 62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин»; – приказ ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации»; – приказ ФСТЭК России от 11.04.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений»; – приказ ФСБ России от 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.7. Сроки начала и окончания работ Начало работ: с даты заключения Контракта. Окончание работ: не позднее 15.12.2026. Работы выполняются в соответствии с этапами. Сроки выполнения этапов работ по развитию и технической поддержке Модуля СЦ определяются Календарным планом. Календарный план, приведен в разделе 5 настоящего ТЗ 1.8. Общие сведения об источниках и порядке финансирования работ Источником финансирования являются средства субсидии федерального бюджета Российской Федерации, предоставленной в соответствии с абзацем вторым пункта 1 статьи 78.1 Бюджетного кодекса Российской Федерации (код цели 08-01) 1.9. Порядок оформления и предъявления результатов работ Подрядчик должен передать Заказчику результаты работ в порядке, определенном Контрактом в сроки, установленные п. 5 настоящего ТЗ, в соответствии с Календарным планом 1.10. Место выполнения Работ Работы выполняются удаленно на комплексе технических средств Заказчика. Адрес размещения комплекса технических средств Заказчика: Московская обл., Богородский район, пос. Горбуша, Радиоцентр. Техническая возможность удаленного подключения обеспечивается Заказчиком (в части предоставления параметров доступа). Оплата телематических и иных услуг, технических и программных средств, необходимых Подрядчику для удаленного подключения и для выполнения требований по информационной безопасности, осуществляется Подрядчиком самостоятельно за свой счет 1.1. Наименование Системы Полное наименование системы: Информационно-аналитическая система регулирования на транспорте. Условное обозначение системы: АСУ ТК. Полное наименование модуля: Модуль сбора, ведения и анализа информации о нештатных ситуациях на транспорте. Условное обозначение модуля: Модуль СЦ. Модуль СЦ создан в рамках контракта от 05.08.2024 № ОК/24_04 на выполнение работ по развитию АСУ ТК в части создания модуля «Сбора, ведения и анализа информации о нештатных ситуациях на транспорте». Развитие Модуля СЦ осуществлено в рамках контракта от 19.05.2025 № ОК/25_09 на выполнение работ по развитию Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК 1.2. Шифр темы или номер контракта Присваивается Заказчиком по результатам организации закупочных процедур. 1.2.1. Предмет контракта Выполнение работ по развитию Модуля СЦ. Код по ОКПД2: 62.01.11.000 – услуги по проектированию и разработке информационных технологий для прикладных задач и тестированию программного обеспечения. Оказание услуг по технической поддержке Модуля СЦ. Код по ОКПД2: 62.02.30.000 – услуги по технической поддержке информационных технологий. Выполнение работ по развитию Модуля СЦ предусмотрено с учетом ключевых результатов (ОКР) Ведомственной программы цифровой трансформации Минтранса России на 2026-2028 (далее - ВПЦТ Минтранса России) в составе мероприятия № 103.002 «АСУ ТК» ИТ расхода 103.26.000005 «Развитие Информационно-аналитической системы регулирования на транспорте (АСУ ТК)»: · «Обеспечено информационное взаимодействие с Минобороны о происшествиях на транспортных объектах»; · «Обеспечена автоматизация формирования отчетов о нештатных ситуациях на транспорте, в том числе по данным внешних систем». Выполнение работ по технической поддержке АСУ ТК предусмотрено ВПЦТ Минтранса России в составе мероприятия № 103.002 «АСУ ТК» ИТ расхода 103.26.000021 «Эксплуатация Информационно-аналитической системы регулирования на транспорте (АСУ ТК)» 1.3. Заказчик Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» (ФГБУ «СИЦ Минтранса России»). Адрес: 107078, Москва, Садовая-Спасская ул., д.18, стр. 1. Оператором Системы является Заказчик - Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» (ФГБУ «СИЦ Минтранса России) 1.4. Подрядчик Определяется по результатам проведения конкурентной процедуры закупки в соответствии с требованиями Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (далее – Федеральный закон № 44-ФЗ) 1.5. Основания для выполнения работ Работы осуществляются на основании следующих документов: – постановление Правительства Российской Федерации от 30.12.2003 № 794 «О единой государственной системе предупреждения и ликвидации чрезвычайных ситуаций»; – постановление Правительства Российской Федерации от 08.11.2013 № 1007 «О силах и средствах единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций»; – распоряжение Правительства Российской Федерации от 27.11.2021 № 3363-р «О Транспортной стратегии Российской Федерации до 2030 года с прогнозом на период до 2035 года»; – Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 26.08.2025 №ЕФ-3; – Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 27.11.2025 №ЕФ-23; – Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 19.02.2026 №ЕФ-1; – План мероприятий по профилактике случаев непроизводственного травматизма граждан на железнодорожном транспорте, являющийся приложением к постановлению коллегии Министерства транспорта Российской Федерации от 11.03.2026 № 2 2. ЦЕЛИ И НАЗНАЧЕНИЕ ВЫПОЛНЕНИЯ РАБОТ 2.1. Назначение АСУ ТК АСУ ТК предназначена для автоматизации и информационно-аналитического обеспечения процессов управления развитием транспортного комплекса Российской Федерации, обеспечения публичности деятельности органов государственного управления транспортным комплексом. Основными целями АСУ ТК являются: – повышение эффективности процессов управления функционированием и развитием транспортного комплекса на основе создания единой информационной среды и комплекса информационно-аналитических услуг на уровне органов государственного управления ТК; – повышение уровня безопасности ТК на базе получения полной, достоверной и оперативной информации о происходящих изменениях, своевременного выявления негативных тенденций и для принятия соответствующих мер по их устранению и ликвидации последствий Значение характеристики не может изменяться участником закупки Основными задачами АСУ ТК являются: – автоматизация процессов прогнозирования развития транспортного комплекса и поддержки принятия управленческих решений; – автоматизация процессов мониторинга безопасности и устойчивости транспортного комплекса, управления в чрезвычайных и нештатных ситуациях; – автоматизация процессов управления программами и проектами развития и модернизации транспортного комплекса; – автоматизация процессов мониторинга состояния транспортного комплекса, в том числе с использованием набора ключевых показателей эффективности деятельности транспортного комплекса; – информационно-технологическая поддержка взаимодействия субъектов транспортного комплекса Российской Федерации, органов государственного управления и контроля, международных организаций на основе создания единой технологической среды взаимодействия и управления движением данных (и связанных с ними документов) в транспортном комплексе; – использование в процессах управления транспортным комплексом РФ современных технологий электронного документооборота и электронного обмена данными; – организация межведомственного электронного взаимодействия подразделений Министерства транспорта Российской Федерации, подведомственных агентств и службы с другими организациями 2.2. Назначение и цели развития и технической поддержки Модуля СЦ Назначение Модуля СЦ: – оперативный мониторинг нештатных и чрезвычайных ситуаций на транспорте ; – оповещение заинтересованных лиц и структур о нештатных и чрезвычайных ситуациях; – сбор, обработка и хранение данных о нештатных и чрезвычайных ситуациях. Целями развития Модуля СЦ являются: – расширение состава данных об оперативной обстановке на транспорте; – оптимизация процесса сбора данных об оперативной обстановке на транспорте; – повышение информированности пользователей за счет визуализация данных Модуля СЦ; – автоматизация процесса формирования отчетов о ЧС и нештатной ситуации на транспорте; – обеспечение информационного взаимодействия с заинтересованными организациями по вопросам ведения. Целями оказания услуг по технической поддержке являются: – обеспечение информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы; – поддержание параметров функционирования ППО Системы, удовлетворяющих требованиям производственных процессов, включая их непрерывность; – обеспечение бесперебойного функционирования ППО и своевременное устранение сбоев и аварийных ситуаций в Системе; – своевременное устранение уязвимостей при выявлении таковых, в соответствии с требованиями к обеспечению информационной безопасности; – адаптация, конфигурирование, коррекция программного обеспечения в соответствии с изменениями нормативно-правовой базы и запросами уполномоченных сотрудников органов государственной власти, включая выполнение процедур тестирования и участие в обновлениях ППО на стендах Заказчика; – обеспечение сохранения работоспособности ППО в изменяемой среде эксплуатации; – ведение документации по настоящему ТЗ, инициирование и актуализация документации на Систему по результатам обработки запросов Заказчика и внесении соответствующих изменений в ППО. Модуль СЦ применяется в деятельности Министерства транспорта Российской Федерации, подведомственных агентств и службы и другими организациями в соответствии с соглашениями об информационном обмене 3. ХАРАКТЕРИСТИКА ОБЪЕКТА АВТОМАТИЗАЦИИ 3 Информирование – ведение справочника способов оповещения (веб-интерфейс, мессенджер); – формирование сценария выполнения оповещения (настройка условий, способа, параметров оповещения); – выполнение оповещений пользователей 4 Отчетность – формирование отчета и справки о событиях; – фильтрация событий для выгрузки в справку о событиях или в отчет о событиях 5 Администрирование – ведение ролей пользователей; – ведение учетных данных пользователей; – ведение справочника организаций; – ведение справочника групп системы мгновенного обмена сообщениями; – выполнение исходящего звонка на контактный телефонный номер организации; – формирование матрицы эскалации событий Архитектура Модуля СЦ представлена на рисунке 1. Рисунок 1. Архитектура Модуля СЦ Значение характеристики не может изменяться участником закупки 3.3. Состав используемого ПО Модуля СЦ Программная архитектура Модуля СЦ разработана как трехуровневая клиент-серверная архитектура. Архитектура включает в себя следующие уровни: • уровень представления – презентационный уровень, обеспечивающий взаимодействие с пользователя с клиентскими приложениями с использованием веб-браузера («тонкий» клиент); • уровень приложений – реализован в виде сервисов, обеспечивает обработку запросов, поступающих от клиентских приложений, формирование ответов на запрос в доступном пользователю виде (формирование пользовательских интерфейсов); • уровень хранения данных – реализуется как сервер БД и обеспечивает хранение и целостность хранимых данных, создание резервных копий, ведение журнала транзакций, восстановление данных после сбоев. Программная архитектура Модуля СЦ включает в себя сервисы и интерфейсы, указанные в Таблице 3. Таблица 3. Программная архитектура Модуля СЦ Программный сервис/интерфейс Технологии реализации Уровень представления Интерфейс пользователя и администратора (front-end) Javascript Уровень приложений Сервис (GateWay) Kotlin Сервис геокодирования (geocoding-service) Kotlin Сервис уведомлений (notifiсation-service) Kotlin Сервис работы с файлами (file-service) Kotlin Сервис отчетности (report-service) Kotlin Сервис управления событиями (event-service) Kotlin Сервис информирования через мессенджер (messenger-notifier) Python Сервис внешних интеграций (integration-service) Сбор информации из внешних систем и сервисов Брокер сообщений Kafka Уровень хранения данных Файловое хранилище MinIO S3 СУБД Postgres Pro Enterprise 3.4. Информационное взаимодействие программных сервисов и интерфейсов Модуля СЦ Объект автоматизации функционирует в распределенной информационной среде. Обмен данными осуществляется по защищенным каналам связи (в том числе ведомственным сетям передачи данных). Источники информации включают: · внешние автоматизированные системы (органов государственной власти); · внутренние базы данных (реестры объектов транспортной инфраструктуры, паспорта регионов и пр.); · оперативная информация от персонала, поступающая через автоматизированные рабочие места (АРМ) и мобильные устройства. 3.4.1. Взаимодействие Модуля СЦ со смежными подсистемами АСУ ТК Модуль СЦ входит в состав АСУ ТК и взаимодействует со следующими ее функциональными задачами и подсистемами: · Функциональной задачей «Формирование и ведение единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации» (ФЗ «Реестр объектов»); · Геоинформационной подсистемой АСУ ТК (П-ГИС); · Подсистемой ведения нормативно-справочной информации и метаданных (П-НСИ); · Подсистемой сбора данных и централизованное хранилище данных (П-СД); · Подсистемой информационного взаимодействия (П-ИВ). 3.4.2. Взаимодействие с внешними информационными системами Список внешних информационных систем, с которыми осуществляется взаимодействие Модуля СЦ: · ЕСИА; · мессенджер; · Яндекс Геокодер; · Информационная система «Централизованная система сбора информации систем-112»; · ПВК «Поиск-Море», АИС РПТ; · облачная АТС 3.1. Описание объекта автоматизации АСУ ТК Объектом автоматизации являются процессы основной и обеспечивающей деятельности, направленные на управление транспортным комплексом, в том числе, процессы информационного взаимодействия с другими организациями и субъектами транспортного комплекса. АСУ ТК относится к государственным информационным системам, а также к информационным системам персональных данных и значимым объектам критической информационной инфраструктуры Российской Федерации. АСУ ТК соответствует требованиям, предъявляемым к: – ГИС второго класса защищенности в соответствии с приказом ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах»; – ИС персональных данных при обеспечении третьего уровня защищенности персональных данных в соответствии с требованиями постановления Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»; – значимым объектам КИИ Российской Федерации второй категории значимости с постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении Правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений». Модуль СЦ является подсистемой АСУ ТК. Перечень платформенных решений и функциональных задач АСУ ТК представлен в Таблице 1 Таблица 1 – Перечень платформенных решений и функциональных задач АСУ ТК № Наименование подсистемы/ функциональной задачи/ модуля Назначение 1 Подсистема сбора данных и централизованного хранилища данных Подсистема обеспечивает выполнение сбора данных в АСУ ТК, и в т. ч., в рамках функциональных задач «Формирование и ведение межрегионального транспортного баланса пассажирских перевозок в дальнем (межрегиональном) сообщении» и «Формирование и ведение транспортного паспорта региона» 2 Подсистема информационного взаимодействия Подсистема информационного предназначена для обеспечения информационного взаимодействия подсистем АСУ ТК, а также, взаимодействия АСУ ТК с АС федеральных органов исполнительной власти 3 Подсистема ведения нормативно-справочной информации и метаданных Подсистема предназначена для автоматизации функций формирования и актуализации справочников, классификаторов, реестров и регистров, необходимых для обеспечения информационной поддержки пользователей НСИ и интеграции подсистем АСУ ТК в части применения НСИ 4 Модуль СМЭВ Модуль взаимодействия со СМЭВ представляет собой набор сервисов взаимодействия: сервис синхронного взаимодействия и сервис отправки, осуществляющих дополнительную обработку сообщений, отправляемых в СМЭВ и принимаемых из СМЭВ 5 Геоинформационная подсистема Программное обеспечение геоинформационной подсистемы предназначено для обеспечения смежных подсистем АСУ ТК возможностью работы с картографической информацией, в том числе, отображения на электронных картах объектов транспортной инфраструктуры и получения информации о местоположении, характеристиках контролируемых транспортных объектов 6 Подсистема информационного портала АСУ ТК Подсистема информационного портала предназначена для отображения и входа в функциональные задачи АСУ ТК 7 Подсистема технического портала АСУ ТК Подсистема технического портала АСУ ТК предназначена для управления заявками пользователей и технологического документооборота заявок 8 Подсистема проектного архива АСУ ТК Подсистема проектного архива АСУ ТК предназначена для автоматизации деловых процессов должностных лиц Министерства транспорта Российской Федерации, подведомственных агентств и службы, в том числе, и процессов информационного взаимодействия внутреннего и внешнего характера 9 ФЗ «Реестр объектов» Функциональная задача предназначена для формирования и ведения единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации 10 ФЗ «СТП» Функциональная задача предназначена для организации информационно-аналитической поддержки процессов территориального планирования Российской Федерации в области федерального транспорта 11 ФЗ «МРТБ ПП» Функциональная задача предназначена для формирования и ведения межрегионального транспортного баланса пассажирских перевозок в дальнем (межрегиональном) сообщении 12 ФЗ «МДД» Функциональная задача предназначена для осуществления мониторинга дорожного движения 13 ФЗ «ТПР» Функциональная задача предназначена для формирования и ведения транспортного паспорта региона 14 ФЗ «Данные по грузообороту» Функциональная задача предназначена для обеспечения подсистем и пользователей АСУ ТК данными по грузообороту между Российской Федерацией и зарубежными странами 15 ФЗ «МЖТ» Функциональная задача предназначена для осуществления мониторинга железнодорожного транспорта 16 ФЗ «МГМП» Функциональная задача предназначена для осуществления мониторинга грузопотоков в морских портах с целью формирования единой цифровой среды мониторинга и планирования перевозок в/из портов Дальнего Востока 17 Модуль ГЭТ Модуль предназначен для получения, хранения данных инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по отдельно взятому предприятию-перевозчику. Формирования отчетов об инвентаризации с детальными данными по каждому разделу инвентаризации с маршрутизацией в муниципалитет / регион / Минтранс. Содержит агрегированные данные инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по всем перевозчикам, относящихся к данному муниципалитету. Формирует сводный отчет по муниципалитету по каждому разделу инвентаризации с маршрутизацией в регион / Минтранс. Формирует агрегированные данные инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по всем перевозчикам, относящиеся к данному региону и по всем муниципалитетам, относящимся к данному региону. Аналитические и статистические данные о состоянии ГЭТ региона. Содержит данные о видах транспорта, цифровых транспортных сервисах и платежных инструментах Региона. Формирует сводный отчет по каждому разделу инвентаризации с маршрутизацией в Минтранс. Формирует агрегированную статистику и аналитику по всем регионам страны в разрезе транспортных средств, маршрутов, пассажиропотоков, инфраструктуры ГЭТ. Данные о рейтинге регионов и перевозчиков на основании выбранных параметров, документооборот с участниками Системы: получение подписанных печатных форм, их утверждение, возврат на доработку. 18 Модуль iМинтранс Модуль создан для отчета по ключевым показателям транспортного комплекса России (Отраслевые и статистические показатели, исполнение бюджета, исполнение поручений, аналитика СМИ, происшествия по видам транспорта). 19 Модуль СЦ Модуль СЦ предназначен для оперативного мониторинга нештатных ситуаций транспортной отрасли, оповещения заинтересованных лиц и структур и предоставления данных о нештатных ситуациях 3.5. Требования к эксплуатации Применяемое в Системе программное обеспечение, программно-аппаратные и аппаратные комплексы должны соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации» АСУ ТК осуществляет идентификацию и авторизацию посредством Единой системы идентификации и аутентификации (ЕСИА). Информационный обмен с внешними информационными системами осуществляется посредством СМЭВ 3 и СМЭВ 4. АСУ ТК развернута на вычислительных мощностях ГЦОД СИЦ Минтранса России 3.2. Описание и текущее состояние объекта автоматизации Модуля СЦ Объектом автоматизации является процесс организации мониторинга информации о НС и ЧС на транспорте. Предметом деятельности Учреждения являются следующие функции: – информационное обеспечение в области транспортной безопасности, защиты населения и территорий от чрезвычайных ситуаций природного и техногенного характера в транспортном комплексе; – подготовка справочных материалов при угрозе возникновения и возникновении чрезвычайных ситуаций и иных происшествий в транспортном комплексе; – взаимодействие и обмен оперативной информацией с органами управления Единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций; – организация оперативного мониторинга обстановки на объектах транспорта при угрозе и возникновении чрезвычайных ситуаций и иных происшествий. Перечень компонентов Модуля СЦ и выполняемые ими функции представлены в Таблице 2 Таблица 2. Перечень компонентов Модуля СЦ и их функции № п/п Компонент Выполняемые функции 1 Регистрация событий – ведение карточки события; – удаление комментария; – динамическое отображение существующих событий в заданном радиусе и за заданный период; – возможность автоматической проверки вводимых данных в части количества пострадавших; – отображение карточки ОТИ, ТС в соответствии с ФЗ Реестр объектов; – сохранение и отображение версии карточки события; – привязка события к координатам по картографической основе; – указание признака выполнения действия по отработке события; – перевод статуса события; – закрытие карточки события; – публикация информации о событии в канале мессенджера; – возможность перехода из карточки события на картографическую основу для просмотра местоположения события 2 Визуализация – отображение событий на картографической основе в виде пиктограмм; – масштабирование карты; – отображение краткой карточки события при выборе события на картографической основе; – отображение списка событий; – отображение карточки события; – отображение журнала действий пользователя; – отображение дополнительной информации (текстовая информация и приложенные файлы); – отображение справки о событиях и отчета о событиях; – отображение фильтров и количества отфильтрованных объектов; – отображение результатов поиска; – отображение статистики по событиям на экране; – возможность создания события с картографической основы; – отображения картографических слоев в зависимости от примененных фильтров; – возможность настройки шага картографической сети; – возможность настройки географической точки центра карты; – отображение количества непрочитанных сообщений; – возможность перехода к детальной карточке события из краткой карточки события при выборе события на картографической основе 4. ТРЕБОВАНИЯ К МОДУЛЮ СЦ 4.1. Требования к структуре Модуля СЦ В процессе работ по развитию Системы должны сохраниться основные требования к построению архитектуры Системы в соответствии с принципами трехуровневой архитектуры: 1. уровень хранения данных или уровень базы данных (сервер СУБД); 2. уровень сервера приложений (сервер аналитической обработки); 3. презентационный уровень, обеспечивающий взаимодействие с клиентскими приложениями. В состав Системы должны входить следующие основные компоненты: 4. сервер баз данных; 5. сервер приложений; 6. веб-сервер. Сервер баз данных должен обеспечивать хранение и целостность хранимых данных, создание резервных копий, ведение журнала транзакций, восстановление данных после сбоев. Сервер приложений должен обеспечивать обработку запросов, поступающих от клиентских приложений (через веб-сервер), формирование ответов на запрос в доступном пользователю виде (формирование пользовательских интерфейсов). Веб-сервер должен обеспечивать взаимодействие с оператором и внешними системами по HTTP / HTTPS протоколу в режиме «запрос-ответ» (получения запросов от пользователя и передачи ответа в виде соответствующей информации, обработанной серверами приложений). Взаимодействие Системы с пользователем должно отвечать требованиям модели «тонкого клиента» (т.е. представлять на стороне клиента (пользователя) лишь графический пользовательский интерфейс). Все составляющие Системы должны использовать единую методологию и отвечать единым принципам взаимодействия, надежности и управления. Перечень компонентов Модуля СЦ представлен в Таблице 4. Таблица 4. Перечень компонентов Модуля СЦ, в отношении которых выполняются работы по развитию № п.п. Наименование компонента Модуля СЦ Раздел ТЗ 1 Компонент регистрации событий 4.2.1. 2 Компонент отчетности 4.2.2 3 Компонент визуализации 4.2.3 4 «Интерактивная карта» (компонент создается) 4.2.4 5 Компонент администрирования 4.2.5 Значение характеристики не может изменяться участником закупки 4.2. Требования к дорабатываемым функциям модуля СЦ 4.2.1. Развитие компонента регистрации событий (1 очередь) Должны быть выполнены следующие доработки: – обеспечение логирования действий пользователя, связанных с карточкой события; – доработка объектной модели в части создания новых типов сущностей (карточек) с учетом реализуемых интеграций с информационными ресурсами (силы и средства предупреждения и ликвидации ЧС и нештатных ситуаций на транспорте, ТС, ограничения воздушного пространства, неблагоприятные и опасные природные явления); – реализация механизма установления связи между сущностями в Модуле СЦ автоматизированным и ручным способами (события, природные явления, силы и средства предупреждения и ликвидации ЧС и нештатных ситуаций на транспорте, ограничения воздушного пространства, ОТИ, ТС и др.); – отображение в карточке установленных связей между сущностями. Оказание услуг в рамках данного технического задания осуществляется Подрядчиком по обращению (заявке) Заказчика, направляемой посредством СРО Заказчика. Регистрация обращений, поступивших непосредственно в Модуль СЦ регистрации обращений Заказчика, производится сотрудниками Заказчика, которые обеспечивают первый уровень технической поддержки Модуля СЦ. В случае назначения приоритета «Критический» или «Высокий», информация о назначении также дублируется оповещением ответственных представителей Подрядчика посредством звонка на предоставленные номера телефонов. Обращение (заявка) должна содержать следующую информацию: – контакты пользователя/организации; – приоритет обращения, соответствующий Приложению 2 к Регламенту; – время обнаружения; – наименование компонента АСУ ТК - Модуль СЦ; Информация может быть расширена по согласованию с Заказчиком. Обращения (заявки) сотрудников Заказчика должны приниматься Подрядчиком через веб-интерфейс СРО. В процессе обработки обращений (заявок) Подрядчик должен обеспечить выполнение следующих процедур: – прием обращений(заявок) от сотрудников Заказчика; – оказание информационно-консультационной поддержки в соответствии с требованиями настоящего Технического задания; – информирование сотрудников Заказчика о статусе обработки и результатах обработки обращений(заявок). Подрядчик осуществляет обязательную регистрацию и учет всех обращений и заявок, поступивших к Подрядчику от представителей Заказчика в рамках оказания настоящих услуг Примечание: в случае приостановки работы по обращению или заявке (обращение или заявка находится в статусе «Приостановлено»), указываются причины, по которым работы по обращению или заявке приостановлены с указанием перечня действий/информации, запрошенных у инициатора обращения, а также даты, формы и адресата такого запроса. В случае отклонения обращения или заявки (заполняется в случае, если обращению или заявке присваивается статус «Отклонено»), указываются подробно причины такого отклонения, а также фиксируется дата и время перехода в статус «Отклонено». В случае, если обращение или заявка отклонены (отменены) самим Инициатором, то указывается дата и способ, которым от инициатора получено соответствующее уведомление. В случае невыполнения Подрядчиком регламентного времени реагирования или решения обращения (заявки) Заказчик вправе отозвать обращение и направить его Подрядчику повторно. При этом каждое отозванное обращение учитывается в Отчёте об оказанных услугах, как обращение с превышением времени реагирования или решения, но оплате не подлежит. В случае, если обращение (заявка) связано с некачественным выполнением Подрядчиком другой задачи, такое обращение решается в регламентное время, установленное Техническим заданием, при этом оплате такие обращения не подлежат, о чем указывается в Отчете об оказанных услугах в графе «Примечание» Работы по устранению неисправности приостанавливаются (по согласованию с Заказчиком) в следующих случаях: – если Подрядчиком в результате диагностики выявлено, что неисправность находится в зоне ответственности Заказчика. Подрядчик информирует Заказчика о выявленной неисправности в зоне его ответственности по согласованным каналам связи; – требуется действие со стороны Заказчика – до момента выполнения данного действия Заказчика. Заказчик информируется о необходимых действиях по согласованным каналам связи; – отсутствие возможности связаться со специалистами Заказчика, участие которых необходимо для устранения неисправности; – требуется доставить оборудование на объект – до момента доставки и установки оборудования. В случаях, представленных выше, время приостановки работ не входит в учет продолжительности устранения неисправности. Учет времени устранения неисправности Подрядчиком считается с момента назначения Инцидента специалисту Подрядчика, ответственному за оказание услуг технической поддержки 3 уровня. Подтверждение необходимости приостановления работ находится в зоне ответственности Подрядчика. Приостановление сроков выполнения задач в соответствии с настоящим пунктом подтверждается Заказчиком по мотивированному обращению Подрядчика в СРО, основанному на данных диагностики или на иных фактических обстоятельствах В случае непринятия Подрядчиком необходимых мер по информированию Заказчика (отсутствие надлежащего обращения от Подрядчика или отсутствие уведомления о необходимости осуществления каких-либо действий Заказчиком) не может являться основанием для приостановления работ по устранению неисправности. В отдельных случаях Подрядчику может потребоваться выполнение технологических работ для устранения причин неисправности или недопущения повторения их в будущем. Для обеспечения устранения неисправности Модуля СЦ Заказчиком проводится классификация в соответствии с приоритетами по степени срочности их устранения. Продолжительность устранения неисправности, а также периодичность информирования Подрядчиком Заказчика о ходе устранения неисправности, определены в Регламенте оказания услуг. При подаче обращения (заявки) наивысшего приоритета через СРО Заказчик должен дополнительно проинформировать службу поддержки Подрядчика о созданном обращении (заявки) по телефону уполномоченного сотрудника Подрядчика. При этом временем подачи обращения (заявки) считается время подачи обращения (заявки) через СРО 4.2.2. Развитие компонента отчетности (3 очередь) Должна быть обеспечена автоматизация процессов формирования отчетов о ЧС и нештатных ситуациях на транспорте, в т.ч. на основе данных из внешних систем. Включает следующие доработки: – разработка шаблонов отчетов в различных форматах (табличный, текстовый); – реализация выбора фотоматериалов для включения в справку; – форматирование содержимого справок с учетом правил русского языка в отношении окончаний слов (в зависимости от падежа, склонения, числа и рода); – автоматизированное формирование выводов к содержимому справки на основе настраиваемых критериев; – создание интерфейса выбора параметров (фильтрации) для формирования отчетов: o состав полей для включения в отчёт; o настройка диапазонов значений характеристик и дат; o порядок отображения полей; o настройка заголовка. – реализация способа подготовки отчётов в асинхронном режиме (очереди); – реализация интерфейса компонента формирования отчетности для отображения очереди формирования отчетов и статусов их подготовки; – экспорт отчётов в форматы xlsx, csv и справок в форматы pdf, docx. Необходимо разработать не менее 10 шаблонов отчетов и/или справок. Перечень, структура и содержание шаблонов должны быть согласованы с Заказчиком на этапе технического проектирования. 4.2.3. Развитие компонента визуализации (2 очередь) В рамках развития компонента визуализации должны быть выполнены следующие доработки, обеспечивающие: – вывод перечней (списков) сил и средств предупреждения и ликвидации ЧС и нештатных ситуаций на транспорте с отображением мест их постоянного размещения (дислокации) на карте, включая: o отображение зон ответственности на карте; o возможность их фильтрации (по видам транспорта, регионам и пр.); o реализацию инструмента расчета расстояния (с использованием сети автомобильных и железных дорог) между местом события и местами дислокации сил и средств, а также вывода маршрутов на карте; – отображение зон (полигонов) с установленными ограничениями движения в воздушном пространстве на карте; – отображение термических точек; – реализация возможности отображения данных из паспорта региона, отображаемого в модуле iМинтранс (модуль АСУ ТК); – отображение краткой карточки сущностей и ОТИ (краткой информации и/или динамических характеристик объекта) при выборе объекта на карте с возможностью перехода в полную карточку сущности и ОТИ; – отображение данных от Росгидромета, предусматривающих: o отображение неблагоприятных и опасных природных явлений на карте (с заданным периодом обновления данных); o управление отображением явлений на карте, включая настройку состава отображаемых объектов, поиск, фильтрацию, с использованием соответствующей панели управления; o выведение краткой карточки явления при выборе объекта, с возможностью перехода в полную карточку объекта – отображение на карте связанных сущностей и ОТИ; – реализация функции выбора темного и светлого стилей отображения элементов интерфейса, карточек сущностей, картографической основы и объектов, отображаемых на карте; – реализация механизма для выбора картографической основы в одном из распространенных форматов WMTS, TMS, MVT и др. Должна быть предусмотрена возможность настройки перечня картографических основ и параметров доступа к ним; – настройка базового набора дашбордов, содержащих преднастроенные виджеты о количестве событий в разрезе видов транспорта с возможностью перехода к исходным данным (карточкам событий, ОТИ и т.д.), с фильтрацией по параметрам. Параметры фильтрации должны быть определены на этапе технического проектирования. Должно быть обеспечено автоматическое и принудительное обновление данных, отображаемых на дашбордах 4.2.4.1. Требования к технической реализации компонента «Интерактивная карта» При реализации компонента «Интерактивная карта» должны учитываться требования, указанные ниже. 4.2.4.1.1. Требования к отображению элементов Повторяющихся элементы карты (ТС, ОТИ, события и пр.) должны отрисовываться с использованием аппаратного создания экземпляров объектов на пользовательском устройстве (WebGL/WebGPU)). Отрисовка каждого объекта отдельным запросом не допускается, должна обеспечиваться возможность одновременного отображения не менее 5 000 объектов без снижения производительности (30 кадров в секунду на тестовой конфигурации). 4.2.4.1.2. Уровни детализации объектов Для управления отображением сложных объектов должно быть создано не менее 3-х уровней детализации, отображаемых при изменении масштаба с возможностью автоматического переключения между уровнями. Все отображаемые объекты должны масштабироваться с учетом разрешения экрана пользователя с сохранением качества детализации. 4.2.4.1.3. Полигональная оптимизация и текстурирование При реализации компонента «Интерактивная карта» должна обеспечиваться технология рельефного тестурирования объектов. Не должны использоваться высокополигональные трехмерные модели. Все повторяющиеся элементы должны генерироваться единоразово и повторно использоваться при последующих отображениях. 4.2.4.1.4. Управление памятью Требуется реализовать потоковую загрузку на устройство пользователя элементов карты и текстур. Загрузка данных целиком при старте приложения не допускается. Необходимо реализовать механизм очистки памяти от элементов, которые находятся вне области видимости камеры в течение заданного времени. 4.2.4.1.5. Требования к взаимодействию пользователя с интерфейсом компонента «Интерактивная карта» Программная реализация механизмов управление камерой (масштабирование и навигация) должна быть выполнена с поддержкой технологии WebAssembly (WASM). Элементы управления должны являться неотъемлемой частью интерактивной карты. 4.2.5. Развитие компонента администрирования (3 очередь) Должна быть выполнена доработка ролевой модели. Ролевая модель должна обеспечивать управление доступом к отдельным объектам Модуля СЦ и их элементам (атрибутам) с разграничением по видам транспорта, регионам и пр., в частности: – определение набора конкретных действий, доступных пользователям (выполняемых над объектом доступа, например, удаление записи, редактирование записи, формирование отчета и др.); – реализация возможности объединения пользователей в группы; – определение прав доступа для групп пользователей; – реализация интерфейса визуальной настройки прав доступа пользователей к объектам Модуля СЦ 4.3.1.3. Требования к регламенту оказания услуг Подрядчик должен руководствоваться Регламентом оказания услуг по технической поддержке Модуля СЦ. Регламент оказания услуг содержит следующую информацию: – порядок оказания услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Модуля СЦ; – порядок оказания услуги по решению инцидентов, связанных с работой ППО; – порядок оказания услуги адаптационного, конфигурационного и коррекционного сопровождения Модуля СЦ (в рамках действующих программных модулей и функциональностей); – порядок оказания услуги по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности. – Регламент содержит следующие формы заявок на оказание услуг: – форма заявки на оказание услуги по информационно-консультационной поддержке сотрудников Заказчика; – форма заявки на оказание услуги по решению инцидентов, связанных с работой ППО; – форма заявки на оказание услуг адаптационного, конфигурационного и коррекционного сопровождения Модуля СЦ (в рамках действующих программных модулей и функциональностей) (приоритет заявки определяется Заказчиком); – форма заявки на оказание услуги по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности 4.3.2. Требования к режиму обеспечения функционирования Модуля СЦ Режим оказания услуг определен в Приложении Б к настоящему ТЗ. По согласованию с Заказчиком, в целях недопущения остановки функционирования Модуля СЦ в период интенсивной работы пользователей в Модуле СЦ, отдельные услуги могут оказываться по специальному графику (в нерабочее время Подрядчика) в соответствии с заявками Заказчика 4.3.3. Требования к качеству оказываемых услуг Качество оказываемых услуг поддерживается Подрядчиком в соответствии с определяемыми данным ТЗ условиями и правилами и контролируется Заказчиком на постоянной основе, в том числе по соблюдению сроков исполнения и подтверждениям исполнения от инициаторов обращений и другим параметрам. По результатам выполнения работ по устранению инцидента должна быть устранена корневая причина инцидента с окончательным решением, устраняющим причину возникновения проблемы и исключающим вероятность повторного возникновения проблемы (инцидента). Время устранения корневых причин проблемы (инцидента) не должно составлять более 40 рабочих часов 4.4.7. Требования к программному обеспечению Общесистемное ПО, используемое в составе Модуля СЦ, должно быть зарегистрировано в Едином реестре российских программ для электронных вычислительных машин и баз данных и соответствовать рекомендованным показателям эффективности и соответствующим им значениям индикаторов эффективности перехода подведомственных организаций на использование российского ПО, заданных Приказом Минцифры России от 18.01.2023 № 21 «Об утверждении методических рекомендаций по переходу на использование российского программного обеспечения, в том числе на значимых объектах критической информационной инфраструктуры Российской Федерации, и о реализации мер, направленных на ускоренный переход органов государственной власти и организаций на использование российского программного обеспечения в Российской Федерации». Применяемое в системе программное обеспечение должно соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации, постановления Правительства Российской Федерации от 23 декабря 2024 г. № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц» Прикладное программное обеспечение должно отвечать следующим требованиям: – совместимость программных продуктов в части используемых технических средств, системного программного обеспечения и общесистемной инфраструктуры в пределах требований к техническому обеспечению, а также их информационная совместимость в пределах требований к информационному обмену; – обеспечение трехуровневой архитектуры с разделением на уровень хранения данных (сервер БД), уровень бизнес-логики (сервер приложений) и уровень представления ( 4.4.7.1. Требования к инструментам разработки и процессу контроля версий программного обеспечения 4.4.7.1.1. Система контроля версий Для управления исходным кодом должна использоваться система контроля версий кода, развернутая в инфраструктуре Заказчика. 4.4.7.1.2. Правила именования веток Имя ветки должно соответствовать следующему формату: / / Категории веток: ? feature/ — разработка новой функциональности, а также рефакторинг или удаление существующей; ? fix/ — исправление ошибок; ? hotfix/ — срочные исправления, применяемые в обход стандартного процесса разработки; ? test/ — для проведения экспериментов, не влияющих на основную разработку. Идентификатор задачи: после категории указывается ссылка на задачу (issue) в системе контроля версий кода. Описание: добавляется краткое описание решаемой задачи в формате kebab-case (слова разделяются дефисами, например, add-user-auth). Примеры именования веток: ? feature/#123/add-payment-integration; ? fix/#45/correct-calculation-logic; ? hotfix/#67/urgent-database-connection-patch. 4.4.7.1.3. Правила именования коммитов Сообщение коммита должно соответствовать соглашению Conventional Commits и состоять из категории и описания: : ? fix — исправление ошибки. Примеры сообщений коммитов: ? feat: добавление формы регистрации пользователя; ? fix: исправление ошибки валидации email-адреса; ? refactor: оптимизация алгоритма сортировки данных; ? chore: обновление версий в файле dependencies. 4.4.7.1.4. Модель ветвления В процессе разработки используются следующие основные ветви: ? main / master — стабильная ветка, содержит только код, прошедший полное тестирование и развернутый в продуктивных контурах; ? dev — ветка для интеграции завершенных задач, предназначенная для сборки и тестирования в тестовых средах. Попадание кода в main осуществляется только через Merge Request (MR) из dev 4.2.4. Создание компонента «Интерактивная карта» (2 очередь) В составе создаваемого компонента должны отображаться данные, доступные в компоненте визуализации. Требования к интерфейсу интерактивной карты: – интерактивная карта должна быть представлена в виде объемной карты с учетом макетов, представленных в Приложении А к ТЗ; – интерфейс должен корректно отображаться на экранах мониторов (разрешение Full HD 1920?1080), телевизоров (разрешение 4К 3840?2160), жидкокристаллических панелей для видеостены, используемой Заказчиком, с параметрами каждой панели: диагональ 55 дюймов, разрешение 1920x1080; – интерфейс должен корректно отображаться на планшетных устройствах с диагональю экрана 10-12 дюймов, конкретные требования должны быть уточнены на этапе технического проектирования; – должна быть обеспечена кластеризация и генерализация отображения объектов на карте при изменении масштаба; – должно быть обеспечено отображение основных характеристик объектов при выборе их на карте; – должно быть обеспечено управление отображением слоев на карте; – должна быть обеспечена настройка цветовой индикации отображаемых объектов транспортной инфраструктуры; – должно быть обеспечено отображение легенды карты, содержащей отображаемые объекты на карте; – должна быть обеспечена возможность одновременного отображения не менее 5 000 ОТИ и ТС на карте. На интерактивной карте должны быть отображены подвижные объекты совместно с объектами транспортной инфраструктуры (ОТИ), включая следующие возможности: § отображение местоположения транспортных средств (воздушный, водный и автомобильный транспорт) на карте в режиме реального времени (с заданным периодом обновления данных); § отображение маршрутов движения всех ТС за выбранный период времени, в том числе с использованием эффектов анимации; § отображение маршрутов движения ТС, связанных с карточкой события: ТС, являющихся участниками события, и ТС, находящиеся в заданном радиусе от события; § управление отображением сущностей и ОТИ на карте, включая настройку состава отображаемых объектов, поиск, фильтрацию, с использованием соответствующей панели управления и наглядным представлением результатов; § автоматическое изменение вида отображения объектов (цветовая индикация) по заданным условиям (например, при достижении критических значений параметров, характеризующих функционирование объекта); Должна обеспечиваться производительность обновления изображения на экране в 30 кадров в секунду на тестовой конфигурации пользовательского устройства (модель Бештау AIO2402/B560, входящая в Реестр российской промышленной продукции под номером 10394100 или аналог) при одновременном отображении не менее 5 000 объектов и 200 уникальных моделей объектов. Макеты интерфейсов Модуля СЦ должны быть предварительно согласованы с Заказчиком и разработаны с учетом требований ГОСТ Р ИСО 9241-161-2016 «Элементы графического пользовательского интерфейса» 4.2.6. Взаимосвязи с внешними автоматизированными системами (1 очередь) Способы взаимодействия с внешними информационными системами должны быть определены на этапе технического проектирования. Должны быть выполнены следующие доработки: – интеграции с информационными ресурсами в целях получения данных о движении подвижных ТС (воздушные суда, суда водного транспорта); – интеграция с информационным ресурсом в целях получения данных о событиях на железнодорожном транспорте. Реализация интеграций должна включать проектирование и реализацию интеграционных механизмов обмена данными с учетом доступных вариантов реализации, обеспечение защищенных способов взаимодействия, настройку отображения отдельных данных на карте (настройка слоев). Взаимодействия, имеющие каналы связи, выходящие за пределы контролируемой зоны взаимодействующих систем, считаются защищенными, если для их защиты используются программные и/или программно-аппаратные шифровальные (криптографические) средства, сертифицированные ФСБ России (далее – СКЗИ). Выбор СКЗИ, схемы подключения и требуемого класса криптостойкости должен производиться в соответствии с Техническими условиями на подключение к информационным ресурсам ФГБУ «СИЦ Минтранса России» и инструкциями по подключению пользователей к ресурсам инфраструктуры Головного центра обработки данных, утвержденных приказом директора ФБГУ «СИЦ Минтранса России» от 24.05.2024 № 21-ОД 4.3. Требования к оказанию услуг по технической поддержке Модуля СЦ 4.3.1. Общие требования к оказанию Услуг Техническая поддержка Модуля СЦ должна осуществляться с учетом требований постановления Правительства Российской Федерации от 06.07.2015 N 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации». Подрядчик обязан выполнять требования законодательства в сфере защиты информации, требования по защите информации, информационной безопасности, указанные в локальных нормативных актах ФГБУ «СИЦ Минтранса России», регламентирующих условия информационного взаимодействия, защиты информации и подключения к информационным ресурсам ФГБУ «СИЦ Минтранса России», участвующих в информационном взаимодействии в рамках оказания услуг по технической поддержке АСУ ТК в 2026 году 4.3.1.1. Требования к составу и содержанию услуг третьего уровня технической поддержки Оказание услуг по технической поддержке Системы осуществляется в рамках этапов в соответствии с календарным планом. Подрядчик в течение 5 рабочих дней с даты заключения Контракта должен предоставить со своей стороны, а Заказчик со своей стороны Матрицу ответственных за взаимодействия в соответствии с Приложением 1 к Регламенту оказания услуг по третьему уровню технической поддержки Модуля СЦ (далее – Регламент, Приложение В). Подрядчик в течение 10 рабочих дней с даты заключения Контракта должен провести мероприятия по организации третьего уровня технической поддержки в соответствии с Регламентом. Услуги по третьему уровню технической поддержки Модуля СЦ должны включать: – организацию Подрядчиком третьего уровня технической поддержки; – информационно-консультационную поддержку работников Заказчика; – решение инцидентов, связанных с работой ППО; – адаптационное, конфигурационное и коррекционное сопровождение Модуля СЦ (в рамках действующих программных модулей и функциональности); – устранение уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности 4.3.4. Требования к документированию результатов оказываемых услуг Для обеспечения контроля оказываемых услуг по поддержке Модуля СЦ со стороны Заказчика, по окончании каждого отчетного периода по контракту в соответствии с календарным планом, Подрядчик обязан предоставить Заказчику Отчет об оказанных услугах. Отчет должен содержать детальную информацию об оказанных услугах с указанием даты выполненных мероприятий и приложением обосновывающих документов (заявок, запросов, требований) или ссылкой на такие документы, если они содержатся в Модуле СЦ. Информация о выполненных мероприятиях по заявкам должна быть сформирована на основании соответствующих записей СРО по каждому этапу исполнения Контракта. В случае оказания услуги адаптационного, конфигурационного и коррекционного сопровождения Модуля СЦ, должны быть предоставлены документы, подтверждающие выполнение требований п. 29.3 приказа ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации». Фактическое время реагирования и время решения по всем обращениям, поступившим в СРО, формируется в СРО по итогам отчетного периода в разделе «Отчеты». Фактическое время реагирования и время решения по обращениям учитывает суммарное время, затраченное на реагирование и, соответственно, на работу по обращению с момента назначения обращения специалисту Подрядчика или группе исполнителей, ответственным за оказание услуг технической поддержки 3 уровня от начала до завершения работ Подрядчиком. При этом принимается суммарное время нахождения заявки в соответствующих статусах заявки СРО на стороне Подрядчика 4.3.5. Требования к классификации обращений и заявок Обращения и заявки Заказчика классифицируются в соответствии с приоритетами и регламентными сроками, указанными в Приложении 2 к Регламенту. Регистрация обращений и заявок предусматривает создание новой записи в СРО с присвоением поступившему обращению или заявке (новой записи) уникального идентификатора. Запись в СРО должна содержать вопрос или проблему, которую требуется решить или оказать консультацию. Состав обязательной информации, которую должно содержать обращение или заявка, зафиксирован в Регламенте оказания Услуг. Если обращение или заявка автоматически зарегистрированы в СРО при отправке представителем Заказчика, Подрядчик проверяет корректность классификации обращения или заявки и может обратиться к Заказчику с просьбой корректировки, предоставив обоснования в соответствии с настоящей классификацией (Таблица 6) 4.3.6.3.1. Требования к порядку оказания услуги по решению инцидентов, связанных с работой ППО При поступлении от Заказчика обращения (заявки), являющегося неисправностью в работе Модуля СЦ (инцидентом), Исполнитель реагирует на инцидент в СРО в срок не более 30 минут с момента поступления. В случае необходимости, для решения инцидента ответственный специалист должен связаться с инициатором обращения (заявки) для уточнения условий воспроизведения проблемы или для получения дополнительных сведений. После получения необходимых сведений от инициатора обращения (заявки) ответственный специалист производит диагностику с целью выявления причины инцидента и возможных путей устранения. В случае, если инцидент невозможно решить без получения дополнительных сведений от инициатора, и не удается связаться с инициатором в течение пяти рабочих дней, обращение (заявка) отклоняется в связи с недостатком данных для его решения, Заказчику направляется уведомление об отклонении обращения (заявки). Время, в течение которого невозможно связаться с инициатором, вычитается из общего времени обработки обращения (заявки). Все попытки связаться с инициатором должны фиксироваться с указанием даты и времени попытки, используемого способа связи (номер телефона, адрес электронной почты) и результата попытки (не удалось дозвониться, абонент недоступен, и т.д.) Факт и время решения инцидента должны быть зафиксированы и отражены в СРО. В случае, если причиной сбоя в работе Модуля СЦ является выход из строя аппаратного обеспечения или неработоспособность смежной информационной системы, время работы над инцидентом приостанавливается до момента устранения неисправности. В ходе решения инцидентов могут быть выявлены дефекты ППО Модуля СЦ. В случае обнаружения дефектов ППО, Подрядчик информирует об этом Заказчика. Исполнитель может быть привлечен к проверке результата устранения дефекта по инициативе Заказчика. Приоритеты инцидентов приведены в Приложении Б к ТЗ. Детальный порядок оказания услуги по решению инцидентов, связанных с работой ППО Модуля СЦ определен в Регламенте оказания Услуг 4.3.6.4. Требования к услугам адаптационного, конфигурационного и коррекционного сопровождения и доработки Модуля СЦ (в рамках действующих программных модулей и функциональностей) Услуги адаптационного, конфигурационного и коррекционного сопровождения и доработки Модуля СЦ включают: – управление изменениями и адаптация функций Модуля СЦ; – изменение настроек функционирования Модуля СЦ; – внесение изменений и/или модификаций Модуля СЦ (в рамках действующих программных модулей и функциональностей), направленных на улучшение их работоспособности и функциональных возможностей; – подготовка и передача Заказчику SQL запросов в СУБД для получения агрегированной информации из Модуля СЦ, которую невозможно получить с использованием графического пользовательского интерфейса; – адаптация модулей интеграций со смежными информационными системами 4.4.7.1.5. Требования к используемым зависимостям (библиотекам) Все внешние зависимости проекта должны быть зафиксированы с указанием точных версий. Для контроля версий зависимостей в репозиторий обязательно должны быть включены следующие файлы: · Для JavaScript: package-lock.json или yarn.lock; · Для Python: requirements.txt (с зафиксированными версиями) или Pipfile.lock; · Для Go: go.mod и go.sum; Загрузка всех зависимостей должна производиться исключительно через внутренний прокси-репозиторий Заказчика, настроенный в соответствующем системе менеджере пакетов. Запрещается: · Использование плавающих версий (например, ^1.2.3, ~4.5.0, latest); · Использование библиотек, содержащих критические уязвимости, в том числе зарегистрированные в реестре CVE (Common Vulnerabilities and Exposures). 4.4.7.1.6. Требования к процессу непрерывной интеграции (CI) Сборка программного обеспечения, включая этапы компиляции, тестирования и анализа кода, должна выполняться исключительно в инфраструктуре непрерывной интеграции Заказчика. 4.4.7.1.7. Требования к хранению артефактов сборки Все артефакты сборки (результирующие пакеты, Docker-образы и т.д.) подлежат обязательному хранению в предназначенной для этого инфраструктуре Заказчика (артефакторий). Запрещается размещение финальных артефактов сборки на сторонних ресурсах 4.4.8. Требования к техническому обеспечению Количество серверов, подключаемых и настраиваемых сервисов, их параметров, схемы соединений и настройки межсетевого взаимодействия должны быть согласованы с Заказчиком на этапе № 1 Техническое проектирование. Доступ к комплексу технических средств предоставляется Заказчиком по письменному запросу Подрядчика. Применяемые в Системе программно-аппаратные и аппаратные комплексы должны соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации», требованиям Постановления Правительства Российской Федерации от 23 декабря 2024 г. № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц». Модуль СЦ, работающий в составе АСУ ТК, развернут на вычислительных мощностях ГЦОД СИЦ Минтранса России 4.5. Общие технические требования 4.5.1. Требования к численности и квалификации персонала и пользователей Модуля СЦ Программное обеспечение Модуля СЦ не должно требовать изменения штатной численности персонала Заказчика. Программное обеспечение Модуля СЦ не должно требовать наличия у пользователей дополнительной квалификации в сфере информационных технологий, кроме базовых знаний в обращении с персональным компьютером, базовых навыков работы в интернет-обозревателях и знаний о Модуле СЦ в объеме документов Руководство пользователя, Руководство администратора 4.3.1.2. Требования к общему порядку оказания услуг Техническая поддержка Модуля СЦ должна быть организована на трех уровнях: – первый и второй уровни технической поддержки организуется Заказчиком; – третий уровень технической поддержки организуется Подрядчиком. Перечень действий на каждом уровне технической поддержки указан в Таблице 5: Таблица 5 – Перечень действий на каждом уровне технической поддержки Уровень технической поддержки Доступные действия Условия передачи задачи на следующий уровень Первый уровень технической поддержки (далее – 1-й уровень) – принимает обращения (заявки) пользователей Модуля СЦ и работников Заказчика; – регистрирует обращения в Модуле СЦ регистрации обращений; – присваивает уникальный идентификационный номер, классифицирует обращения; – самостоятельно решает обращения, которые связаны с недостаточной квалификацией пользователей или настройками в рамках своей компетенции; – взаимодействует с пользователями Модуля СЦ при решении проблемы Передает обращение на второй уровень поддержки в случае невозможности решения на своем уровне Второй уровень технической поддержки (далее – 2-й уровень) – принимает обращения от 1-го уровня; – уточняет классификацию обращения в результате дополнительного анализа; – самостоятельно решает обращения в рамках своей компетенции; – осуществляет техническую и консультационную поддержку Модуля СЦ; – взаимодействует с сотрудниками 1-го и 3-го уровня и пользователями Модуля СЦ; – формирует заявки для 3-го уровня и контролирует исполнение Передает обращение на третий уровень поддержки в случае невозможности решения на своем уровне Третий уровень технической поддержки (далее – 3-й уровень) – принимает обращения от 2-го уровня; – обеспечивает выполнение требований, предъявляемых Контрактом и настоящим Техническим заданием к Услугам, оказываемым Подрядчиком Все поступающие обращения должны быть исполнены Подрядчиком Для обеспечения взаимодействия с Заказчиком Подрядчик со своей стороны определяет ответственных лиц, уполномоченных в структуре Подрядчика за своевременное и качественное оказание Услуг в рамках настоящего ТЗ, а также контактную информацию ответственных лиц (телефон, электронную почту). Подрядчик должен предоставить Заказчику единый адрес электронной почты для приема обращений (заявок) в течение 3 (трех) рабочих дней после заключения Контракта. Указанный в настоящем пункте адрес электронной почты (способ направления обращений (заявок) применяется в случае сбоя в работе СРО Заказчика. Со своей стороны, Заказчик предоставляет Подрядчику перечень и контактную информацию (телефон, электронную почту) уполномоченных лиц для осуществления взаимодействия с указанием зон ответственности. О любых изменениях в контактной информации ответственных лиц Стороны должны уведомить друг друга в течение 1 (одного) рабочего дня с момента возникновения таких изменений посредством уведомления на электронную почту ответственных лиц и/или в письменной форме. В результате оказания услуг по настоящему ТЗ не должны быть изменены исходные коды, дистрибутивы и иные компоненты Модуля СЦ вне согласованных с Заказчиком изменений. Любые изменения исходных кодов, дистрибутивов и иных компонентов Модуля СЦ должны производиться только после согласования с Заказчиком уполномоченными лицами по электронной почте или иным заранее согласованным способом. Не должна быть ухудшена надежность и производительность Модуля СЦ. Оказание услуг по Контракту не должно нарушать требования к информационной безопасности, описанной в документации на Модуль СЦ Таблица 6. Категории обращений и заявок Категория Примеры Запрос на обслуживание Подготовка SQL запроса к СУБД для решения прикладной задачи и д.р. – запрос на любое действие, не являющееся запросом информации и несовершенный на основе происшествия, прямо или косвенно влияющего на работу Модуля СЦ Консультация «Где взять / куда обратиться...?», «Как сделать / выполнить…», «Как это работает…?» - запрос, имеющий своей целью получение информационной поддержки Инцидент Разбор ошибок/сбоев и подготовка материалов (корректировочных релизов, инструкций) для Заказчика для устранения ошибок/сбоев, которые приводят к частичному и полному нарушению работоспособности всех или отдельных функций ППО. Подготовка изменения и материалов, необходимых для проведения аварийно-восстановительных работ для возобновления работоспособности Модуля СЦ ЗНИ Подготовка изменений, связанных с изменением, улучшением/оптимизацией Модуля СЦ и выводом новой модифицированной функциональности в штатном режиме. Подготовка изменений, связанных с модификацией существующих и/или реализация новых интеграционных механизмов для получения/обработки данных внешних систем. Подготовка изменений графического интерфейса по требованиям Заказчика. Перечень статусов обращений (заявок) приведен в пункте 3.3. Регламента оказания Услуг. Назначение обращению (заявке) статуса «Закрыто» осуществляется Заказчиком только после получения от инициатора обращения (заявки) подтверждения о его исполнении или нахождения обращения (заявки) в статусе «Выполнено» и отсутствия повторных вопросов/запросов по данному обращению (заявки) в течение 5 рабочих дней. Категории и статусы обращений (заявок) могут быть скорректированы в процессе оказания услуг исключительно по согласованию с Заказчиком 4.3.6. Требования к услугам технической поддержки 4.3.6.1. Требования к организации третьего уровня технической поддержки Основными задачами организации третьего уровня технической поддержки в рамках оказания услуг по технической поддержке Модуля СЦ являются организация эксплуатационной службы Подрядчика, проверка готовности технических и программных средств для обеспечения непрерывного функционирования ППО Модуля СЦ. Подрядчиком должны быть проведены организационно-штатные и подготовительные мероприятия (в т. ч. технические) в рамках организации технической поддержки Модуля СЦ. Подрядчик в течение 5 (пяти) рабочих дней с даты заключения Контракта должен: – определить и направить Заказчику документ «Перечень уполномоченных специалистов», содержащий контактную информацию (ФИО, должность, адрес рабочей электронной почты) лиц, ответственных за оказание услуг со стороны Подрядчика; – обеспечить подключение специалистов Подрядчика к Системе регистрации обращений (заявок) (СРО предоставляется Заказчиком) для оказания услуг; – согласовать с Заказчиком способ доступа Подрядчика к Модулю СЦ. Результат выполнения мероприятий фиксируется в Протоколе проверки результатов организационно-штатных и подготовительных мероприятий (см. Приложение Д к настоящему ТЗ) 4.3.6.4.1. Требования к проведению изменений Основанием для внесения изменений является запрос от Заказчика. Все активности по внесению изменений должны быть согласованы с Заказчиком, а действия Подрядчика при оказании данной услуги должны быть зафиксированы. В рамках данного Технического задания изменениями считаются локальные доработки функционала Модуля СЦ, которые не должны приводить к необходимости выполнения дополнительных аттестационных испытаний или переаттестации АСУ ТК в соответствии с п. 33 приказа от 29.04.2021 № 77 «Об утверждении Порядка организации и проведения работ по аттестации объектов информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну». При необходимости внесения изменений в Модуль СЦ, не связанных с критичным инцидентом, существенно нарушающим работоспособность Модуля СЦ, Заказчик направляет Подрядчику обращение (заявку), в котором излагает суть изменения, которое требуется внести в Модуль СЦ. Исполнитель, в течение 3 (трех) рабочих дней с момента поступления соответствующего обращения (заявки), оценивает техническую возможность реализации запрашиваемого изменения и варианты реализации. По итогу проведения оценки Подрядчик направляет Заказчику заключение о возможности реализации данного изменения с описанием возможных вариантов реализации и согласует с Заказчиком проведение данного изменения При проведении работ по изменению и адаптации Подрядчик должен: – обеспечить выполнение требований безопасной разработки программного обеспечения; – обеспечить предварительное проектирование технических решений и согласование с Заказчиком проекта реализации изменения; – использовать семантическое версионирование (SemVer) в работе, передать Заказчику все артефакты разработки (исходный код и сторонние библиотеки, конфигурации, сборочные и собранные образы и др.); – подготовить полноценное описание функционала, включенного в релиз, с необходимыми схемами и пояснениями к обновлению на стендах Заказчика; – обеспечить тестирование разработанного функционала на стендах Заказчика силами Подрядчика; – решение о переносе измененного ППО на продуктивный стенд принимается Заказчиком по итогу результатов проведенного тестирования; – обеспечить техническое сопровождение процедуры тестирования ППО и переноса измененного ППО на продуктивный стенд Заказчика; – обеспечить экстренное внесение соответствующих изменений в случае выявления некорректной работы продуктивного стенда Заказчика после проведения обновления по итогам разработанного изменения в кратчайшие сроки; – актуализировать при необходимости комплект эксплуатационной документации: o руководство пользователя; o руководство администратора; o иные документы (при необходимости). Результат выполнения изменений должен быть отражен в Отчете по оказанию услуг. Типы и приоритеты изменений могут быть скорректированы в процессе оказания услуг исключительно по согласованию с Заказчиком 4.5.2. Требования к режимам функционирования Модуля СЦ Модуль СЦ должен предусматривать наличие следующих режимов работы: – штатный; – регламентный (профилактический); – аварийный. Основным режимом функционирования является штатный. В штатном режиме все компоненты корректно и полностью выполняют свои функции. Перерывов в работе как Модуля СЦ в целом, так и одного, либо нескольких компонентов не предусмотрено. Режим регламентного (профилактического) обслуживания предназначен для проведения работ по обновлению и техническому обслуживанию компонентов Модуля СЦ, а также резервному копированию данных. При работе в данном режиме допускаются перерывы в работе Модуля СЦ с предварительным информированием пользователей. Состав процедур по регламентному обслуживанию Модуля СЦ и их периодичность определяются Подрядчиком в процессе выполнения работ по созданию Модуля СЦ. В режиме регламентного (профилактического) обслуживания Модуль СЦ может функционировать с частичным ограничением своих функциональных возможностей, либо без ограничения, но со снижением показателей надежности и производительности. Перевод в данный режим работы должен осуществляться сразу после начала выполнения любой операции, отнесенной к этому режиму, с последующим возвратом в штатный режим функционирования сразу после ее завершения. Перевод в указанный режим должен осуществляться при возникновении необходимости проведения работ по обновлению и техническому обслуживанию компонентов Модуля СЦ, а также резервному копированию данных с условием предварительного оповещения пользователей. Аварийный режим функционирования характеризуется отказом одной или нескольких подсистем, вызванных выходом из строя аппаратного и/или программного обеспечения, а также в случае временной неработоспособности каналов связи между серверами. В аварийном режиме осуществляется поиск неисправностей и проведение работ по их устранению. Перевод в аварийный режим должен осуществляться при возникновении сбоев, аварий и прочих незапланированных воздействий, сразу после наступления одной или нескольких аварийных ситуаций, с последующим возвратом в штатный режим функционирования сразу после окончания восстановительных работ. ПО Модуля СЦ должно обладать надежностью, обеспечивающей работу пользователей в произвольном режиме и оперативное восстановление работоспособности при сбоях. В целях обеспечения надежного функционирования ПО должно предусматривать: – сохранение целостности данных при нештатном завершении работы компонентов Модуля СЦ; – сохранение работоспособности программного обеспечения при некорректных действиях пользователя; – резервное копирование базы данных Модуля СЦ. – время восстановления работоспособности Модуля СЦ после отказа не более 4 часов. – отказоустойчивость на уровне 99% при единовременной количестве не менее 200 пользовательских сессий в Модуле СЦ. Указанные характеристики приведены без учета характеристик надежности инфраструктуры и времени передачи информации по каналам связи. При возникновении сбоев в аппаратном обеспечении, включая аварийное отключение электропитания, Модуль СЦ должен автоматически восстанавливать свою работоспособность (не требовать перенастройки) после устранения сбоев и корректного перезапуска аппаратного обеспечения По результатам анализа угроз безопасности информации программного обеспечения и испытаний по выявлению уязвимостей в программном обеспечении Системы должна быть предоставлена отчетная документация по формам, утвержденным в Руководстве, и артефакты сборочной среды, подтверждающие проведение испытаний по выявлению уязвимостей в программном обеспечении Систем. Уязвимости подлежат устранению в сроки, обозначенные Заказчиком. В случае обнаружения уязвимого компонента Подрядчик должен заменить/обновить библиотеки. В случае, если уязвимость не подлежит исправлению на программном уровне, Подрядчик должен разработать меры предотвращения угроз безопасности, в том числе правила безопасности для наложенных средств защиты, рекомендации по безопасной настройке конфигурации для устранения потенциальных уязвимостей и снижения рисков информационной безопасности. Уязвимости, найденные ФСБ России, ФСТЭК России, Минцифры России, Роскомнадзором в ходе исполнения Контракта, а также в течение гарантийного периода, должны быть устранены Подрядчиком за свой счет в сроки, согласованные с Заказчиком 4.5.6. Требования к эргономике и технической эстетике Взаимодействие пользователей с Модулем СЦ должно осуществляться посредством визуального графического интерфейса. Ввод-вывод данных, прием управляющих команд и отображение результатов их исполнения должны выполняться в интерактивном режиме. Интерфейс должен быть рассчитан на преимущественное использование манипулятора типа «мышь», то есть управление Модулем СЦ должно осуществляться с помощью набора экранных меню, кнопок, значков и т. п. элементов. Клавиатурный режим ввода должен использоваться главным образом при заполнении и/или редактировании текстовых и числовых полей экранных форм. Все надписи экранных форм, а также сообщения, выдаваемые пользователю (кроме системных сообщений), должны быть на русском языке. Модуль СЦ должен обеспечивать проверку вводимых пользователем данных и предупреждать о некорректно введённых значениях Экранные формы должны проектироваться с учетом требований унификации: – все экранные формы пользовательского интерфейса должны быть выполнены в едином графическом дизайне, с одинаковым расположением основных элементов управления и навигации; – для обозначения сходных операций должны использоваться сходные графические элементы, кнопки и другие управляющие (навигационные) элементы. Термины, используемые для обозначения типовых операций, а также последовательности действий пользователя при их выполнении должны быть унифицированы; – внешнее поведение сходных элементов интерфейса (реакция на наведение указателя «мыши», переключение фокуса, нажатие кнопки) должно реализовываться одинаково. Структура размещения информации и представление этой структуры в Модуле СЦ должны соответствовать следующим требованиям: – пункты меню в пользовательском веб-интерфейсе должны быть сгруппированы в соответствии с тематикой информации, функциональными задачами и технологией работы; – каждому пункту меню должна соответствовать только одна выполняемая функция; – при совершении пользователями ошибочных действий должны выдаваться сообщения об ошибках. Эскизы визуального оформления компонента «Интерактивная карта» представлены в Приложении А. 4.3.6.2. Требования к услугам информационно-консультационной поддержки работников Заказчика и пользователей Модуля СЦ Услуги информационно-консультационной поддержки сотрудников Заказчика включают: – обработку обращений и заявок, поступивших от сотрудников Заказчика; – консультирование сотрудников Заказчика и пользователей Модуля СЦ; – актуализацию документации, и других материалов по работе с Модулем СЦ при необходимости. – консультирование и разработку рекомендаций по настройке Модуля СЦ (без изменения программного кода), включая изменение настроек функционирования; – консультации по вопросам использования, настройки и возможностям Модуля СЦ; – консультации по проведению превентивных мер для недопущения аварийных ситуаций в Модуле СЦ; – консультации по предварительной диагностике и локализации возникшей неисправности Модуля СЦ; – консультации по вопросам обеспечения информационной безопасности Модуля СЦ и настройки функций, обеспечивающих корректную работу программного обеспечения для совершения юридически значимых действий в Модуле СЦ; – другие вопросы, связанные с работой Модуля СЦ. 4.3.6.2.1. Требования к порядку оказания услуг информационно-консультационной поддержки работников Заказчика и пользователей Модуля СЦ Подрядчик выполняет консультирование сотрудников Заказчика и пользователей Модуля СЦ. Консультация может быть предоставлена по согласованным с представителем Заказчика каналам коммуникации с регистрацией результата консультации в СРО Подрядчиком. Детальный порядок оказания консультационных услуг определен в Регламенте оказания Услуг 4.3.6.3. Требования к услугам по решению инцидентов, связанных с работой ППО Подрядчик устраняет неисправности Модуля СЦ, связанные с работой ППО, выявленные в рамках оказания услуг согласно настоящему Техническому заданию, при этом в зону ответственности Подрядчика не входит устранение неисправностей, выявленных на стороне Заказчика и на стороне третьих лиц (провайдера связи, поставщика электропитания и т.д.). Первичная диагностика выявленной неисправности проводится на 1 и 2 уровнях технической поддержки и не входит в зону ответственности Подрядчика. Если при проведении первичной диагностики и попытке устранить неисправности на 1 и 2 уровнях технической поддержки, данную неисправность устранить не удалось и в процессе диагностики было выявлено, что проблема связана с работоспособностью ППО, обращение (заявка) назначается сотруднику Подрядчика, ответственному за оказание услуг технической поддержки 3 уровня. Инцидентами вне зоны ответственности Подрядчика являются: – работоспособность функциональности, выходящая за рамки текущей реализации функций в Модуле СЦ и/или являющаяся расширением требований Заказчика к функциям Модуля СЦ; – проведение профилактических и плановых работ, согласованных с Заказчиком; – нарушение работоспособности функций Модуля СЦ, вызванное проведением работ на стороне Заказчика 4.3.6.4.2. Требования к изменению настроек функционирования Изменение настроек функционирования может проводиться в рамках допустимых пределов изменения функционирования, заложенных в архитектуру Модуля СЦ. Изменение настроек функционирования включает в себя изменение данных и справочников, изменение форм документов, формируемых Модулем СЦ, изменение и настройку форматов и версий передачи данных в смежные системы. Доработка программного кода Модуля СЦ может допускаться (в случае необходимости) при выполнении работ по адаптации функций Модуля СЦ в части изменения формата передачи данных в смежные информационные системы при условии соблюдения требований пункта 29.3 приказа ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации» 4.3.6.5. Требования к услугам по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности По запросу Заказчика Подрядчик должен провести работу по приведению ППО в соответствие с требованиями по обеспечению информационной безопасности. Критичность уязвимости оценивается в соответствии в соответствии с Методическим документом ФСТЭК России «Методика оценки уровня критичности уязвимостей программных, программно-аппаратных средств» (утвержден ФСТЭК России 30.06.2025), а также с учетом ГОСТ 56545-2015 и международными стандартами (CVSS 3.0 и выше), и задает необходимый срок устранения. В процессе проведения Заказчиком обследования Модуля СЦ и выявления уязвимостей в ППО, связанных с исходным кодом Модуля СЦ и/или используемыми компонентами (библиотеками), Заказчик направляет Подрядчику обращение (заявку) на устранение, с указанием критичности и срочности принятия мер по устранению в СРО. Подрядчик при оказании услуг по обновлению или устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности должен: – провести анализ уязвимостей и связанных с ними исходным кодом и/или используемыми компонентами (библиотеками); – выработать варианты устранения указанных уязвимостей и согласовать с Заказчиком их реализацию; – своевременно внести изменения в исходный код Модуля СЦ и/или используемые компоненты (библиотеки) и подготовить соответствующее обновление; – провести обновление Модуля СЦ в тестовом контуре Заказчика и проинформировать Заказчика о готовности проведения тестирования; – протестировать успешность обновления или устранения уязвимостей в ППО и корректность функционирования Модуля СЦ на тестовом контуре, совместно с Заказчиком; – при невозможности незамедлительного устранения уязвимости приоритетов «Критический» и «Высокий» Подрядчик обязан предоставить исчерпывающий список причин и согласовать план достаточных компенсирующих мер с ответственными сотрудниками Заказчика. Результат внесения изменений отображается в соответствующей записи в СРО и в составе Отчета об оказанных услугах 4.3.6.5.1. Требования к порядку оказания услуг по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности Подрядчик в соответствии с приоритетами обращений и контрольными сроками исполнения (см. Приложение Б к ТЗ) оценивает техническую возможность и сроки устранения уязвимостей, и реализацию обновления Модуля СЦ. По итогу проведения оценки Подрядчик направляет в заявке СРО Заказчику заключение о возможности устранения уязвимостей и/или обновления в ППО и согласует с Заказчиком проведение данных работ Технические меры по обеспечению надежности должны предусматривать: – резервирование критически важных компонентов и данных Системы и отсутствие единой точки отказа; – использование программного резервирования (программной избыточности); – изменение конфигурации используемых средств и применение специализированного ПО, обеспечивающего высокую надёжность. Организационные меры по обеспечению надежности должны быть направлены на минимизацию ошибок пользователей (а также обслуживающего персонала при эксплуатации и проведении работ по обслуживанию), минимизацию времени ремонта или замены вышедших из строя компонентов за счёт: – обеспечения для обслуживающего персонала требуемого уровня квалификации; – регламентации и нормативного обеспечения выполнения работ обслуживающим персоналом; – своевременной диагностики неисправностей. Расчетное значение коэффициента доступности Модуля СЦ должно составлять не менее 0,95. 4.5.3. Требования по диагностированию Модуля СЦ Диагностирование Модуля СЦ должно осуществляться путем анализа записей в системных журналах СУБД, операционных систем серверов, а также с помощью встроенных средств диагностирования общего программного обеспечения Модуля СЦ. Диагностированию подлежат: – сбои и нарушения функционирования технического обеспечения (серверов) Модуля СЦ; – сбои и нарушения функционирования системного программного обеспечения серверов, используемых для работы Модуля СЦ; – сбои и нарушения функционирования прикладного программного обеспечения серверов, используемых для работы Модуля СЦ; – случаи недоступности (отсутствия ответа) или некорректные ответы внешних систем; – сбои и нарушения функционирования СУБД; – сбои при выполнении регламентных операций резервного копирования. При возникновении аварийных ситуаций либо ошибок в программном обеспечении диагностические инструменты должны позволять сохранять набор информации, необходимой для идентификации и устранения проблемы. Модуль СЦ и ее компоненты должны обеспечивать возможность диагностики своей работоспособности с возможностью интеграции с модулем мониторинга АСУ ТК. Набор передаваемых журналов и метрик должен быть определен на этапе технического проектирования 4.5.4. Требования к надежности Должно быть предусмотрено сохранение работоспособности Модуля СЦ при некорректных действиях пользователя и сохранение целостности данных при нештатном завершении работы Модуля СЦ (отказ рабочей станции, потеря сетевого доступа и т.п.). Модуль СЦ должен предоставлять механизмы обеспечения сохранности данных через применение процедур резервного копирования и восстановления, описанных в документации на Систему. Ключевые показатели надежности информационной системы — допустимое время на восстановление работоспособности Модуля СЦ (RTO - recovery time objective) и/или допустимый интервал времени потери изменений в данных при сбоях/отказах (RPO – recovery point objective) должны быть определены Подрядчиком и согласованы с Заказчиком на этапе технического проектирования 4.5.7. Требования по сохранности информации при авариях В случае возникновения аварии или сбоя в процессе выполнения пользовательских задач должно быть обеспечено восстановление баз данных до состояния на момент последней завершенной Модулем СЦ транзакции, и структуры файлового хранилища. Все аварийные ситуации должны обрабатываться программно с выдачей соответствующих сообщений, с корректной обработкой ситуации (завершение транзакций, закрытие файлов и т.п.), без потери обрабатываемой информации. В Модуле СЦ должны быть предусмотрены меры, обеспечивающие целостность данных в случае отказа программного обеспечения или аппаратных средств, исключая случаи физического уничтожения носителя или нарушения функциональности носителя, операционной системы или СУБД по вине их производителя либо обслуживающего персонала. Используемые аппаратные и системные платформы должны обеспечивать сохранность и целостность информации в Модуле СЦ при полном или частичном отключении электропитания, аварии сетей телекоммуникации, полном или частичном отказе технических средств Модуля СЦ. Технические решения должны обеспечивать сохранность информации в случае возникновения следующих событий (аварий, отказов и т.п.): – отказ аппаратного обеспечения на сервере; – отключение питания на сервере; – отказ аппаратного обеспечения на рабочей станции; – отключение питания на рабочей станции администратора; – отказ линий связи, в том числе при осуществлении обмена данными 4.5.8. Требования к защите от влияния внешних воздействий Требования к защите от влияния внешних воздействий не предъявляются 4.5.9. Требования к патентной чистоте и патентоспособности 4.5.9.1. Исключительные права на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, базы данных, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, принадлежат Российской Федерации в лице Заказчика. Право собственности на результаты работ, отчетные документы и материалы, полученные в ходе выполнения работ по Контракту, принадлежат Российской Федерации в лице Заказчика и считаются переданными с момента подписания Сторонами Акта сдачи-приемки выполненных работ. Разработанное программное обеспечение поставляется вместе с исходными кодами. 4.5.9.2. Все проектные и технические решения должны отвечать требованиям четвертой части Гражданского кодекса Российской Федерации. Результаты Работ должны быть свободными от возможности предъявления любых прав и притязаний третьих лиц, основанных на промышленной, интеллектуальной или другой собственности. 4.5.9.3 Результаты выполненных Работ не должны повлечь необходимость осуществления Заказчиком закупок программного обеспечения (как исключительных, так и неисключительных прав) для обеспечения функциональности Системы в соответствии с Техническим заданием. При выполнении работ Подрядчик должен использовать только объекты интеллектуальной собственности, права на которые приобретены (получены) и используются без нарушений прав на интеллектуальную собственность третьих лиц или предоставлены Заказчиком При проведении работ по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности необходимо выполнить следующее: – Заказчику сформировать заявку на устранение (обновление) в СРО с полным списком обнаруженных уязвимостей и планируемыми работами; – согласовать в рабочем порядке время начала и завершения работ, перечень работ, выполняемых в рамках обновления или устранения уязвимостей в ППО с Заказчиком; – оповестить Заказчика о начале проведения работ на тестовом контуре; – провести работы по обновлению или устранению уязвимостей в ППО на тестовом контуре Модуля СЦ в установленные сроки; – протестировать выполнение работ в тестовом контуре и проинформировать Заказчика о готовности переноса ППО на продуктивный контур; – силами Заказчика обновить продуктивный контур Модуля СЦ, в соответствии с планом устранения и выполненными работами; – совместно с Заказчиком проверить корректность функционирования Модуля СЦ и устранения уязвимостей в продуктивном контуре Модуля СЦ по результатам обновления; – при необходимости актуализировать документацию (описание архитектуры, анкеты постановки на мониторинг и иные документы). Любые изменения в части обновления или устранения уязвимостей в ППО на промышленном контуре Модуля СЦ должны применяться только в случае успешного проведения аналогичных работ на тестовом контуре. Детальный порядок оказания услуги по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности определен в Регламенте оказания Услуг 4.4. Требования к видам обеспечения 4.4.1. Требования к лингвистическому обеспечению Документация на Модуль СЦ должна разрабатываться на русском языке. Взаимодействие пользователей с Модулем СЦ посредством графического интерфейса должно происходить на русском языке за исключением сообщений, зависящих от настроек системного программного обеспечения, установленного на рабочих местах пользователей. При разработке программных решений Модуля СЦ должно быть предусмотрено использование языков программирования высокого уровня, приведенных в Таблице 7. Таблица 7. Языки и средства разработки, специального программного обеспечения Модуля СЦ Категория Наименование Назначение Языки программирования Kotlin Разработка серверной логики и сервисов (backend) JavaScript / TypeScript Разработка клиентской части (frontend) Python Разработка скриптов интеграции, обработки данных и автоматизации Фреймворки и библиотеки Vue.JS Разработка пользовательских интерфейсов (веб-интерфейсы компонентов визуализации и отчетности) React Разработка пользовательских интерфейсов (при необходимости создания сложных интерактивных компонентов) Решения по лингвистическому обеспечению, включая перечень используемых языков программирования, должны быть согласованы с Заказчиком на этапе технического проектирования 4.4.2. Требования к математическому обеспечению Требования к математическому обеспечению не предъявляются. 4.4.3. Требования к метрологическому обеспечению Требования к метрологическому обеспечению не предъявляются. 4.4.4. Требования к организационному обеспечению Требования к организационному обеспечению не предъявляются. 4.4.5. Требования к методическому обеспечению Задачи методического обеспечения Модуля СЦ должны быть обеспечены за счет использования технологических и методических документов касающихся вопросов функционирования транспортного комплекса и разработки и эксплуатации ПО. 4.4.6. Требования к информационному обеспечению Состав, структура и способы организации информационного обеспечения в Модуле СЦ должны быть определены на этапе технического проектирования. Факты информационного обмена с внешними системами должны фиксироваться в соответствующем журнале 4.5.5. Требования к информационной безопасности Работы по защите информации/информационной безопасности, не включенные в состав настоящего раздела, требуемые в соответствии с требованиями постановления Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации», а также нормативно правовых актов в области защиты персональных данных и обеспечения безопасности объектов критической информационной инфраструктуры, будут проведены в рамках исполнения отдельного контракта, заключенного по результатам отдельной закупочной процедуры (не является частью данного ТЗ), включающего: – определение актуальных угроз безопасности информации и актуализация модели угроз безопасности информации (при необходимости); – выполнение требований о согласовании технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России в установленном порядке; – выполнение требований по устранению Подрядчиком замечаний и недостатков, в случае их выявления при согласовании Заказчиком технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России; – выполнение требований к классу защищенности ГИС, уровню защищенности персональных данных и категории значимости объекта КИИ РФ, установленных для Головного центра обработки данных ФГБУ «СИЦ Минтранса России» (далее – ГЦОД); – определение перечня объектов защиты информационной системы; – описание (актуализированных) требований к системе защиты информации, а также к мерам защиты информации информационной системы в зависимости от установленных классов защищенности, уровня защищенности персональных данных и категории значимости объектов КИИ РФ (приказы ФСТЭК России № 21, 117, 239); – выполнение требований к мерам по защите ГИС от атак, направленных на отказ в обслуживании, в соответствии с пунктами 30, 34, 59, 63 Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений, утвержденных приказом ФСТЭК России от 11.04.2025 № 117; – описание (актуализированных) требований по защите информации, подлежащих реализации в информационно телекоммуникационной инфраструктуре ГЦОД; – выполнение требований о применении сертифицированных средств защиты информации, включая их классы защиты и уровни доверия; – выполнение требований о запрете использования с 01.01.2025 органами (организациями) средств защиты информации странами происхождения, которых являются иностранные государства в соответствии с пунктом 6 Указа Президента Российской Федерации от 01.05.2022 № 250; – выполнение требований по обеспечению непрерывного взаимодействия с ГосСОПКА в установленном порядке; 4.5.9.4. Подрядчик подтверждает, что обладает всеми правами на передачу Заказчику исключительных прав в соответствии с требованиями настоящего раздела Технического задания. В случае, если к Заказчику по вине Подрядчика будут предъявлены претензии в этой части, иски третьих лиц, связанные с нарушением их прав, Подрядчик принимает на себя такие претензии и иски и возмещает Заказчику все расходы и весь ущерб, понесенный в связи с ними. 4.5.9.5. Подрядчик обязан согласовать с Заказчиком необходимость использования при выполнении работ охраняемых результатов интеллектуальной деятельности, права на которые принадлежат Подрядчику или третьим лицам. 4.5.9.6. В случае, если при выполнении Работ используется готовое программное обеспечение (платформа, подсистема, СУБД и т.д.), которое становится частью (компонентом) Системы, Заказчику передаются полные исключительные права, или неисключительные права (путем заключения лицензионного/сублицензионного договора/соглашения) на такое программное обеспечение со следующими возможностями: – права передаются бессрочно (на весь срок действия исключительных прав); – территория действия Российская Федерация; – должно быть обеспечено право Российской Федерации (в лице Заказчика) передавать, дорабатывать, распространять, развивать результаты работ, созданные в процессе исполнения Контракта, а также перерабатывать такое программное обеспечение. Лицензионное (сублицензионное) соглашение (договор), Акт передачи прав, подписанные Подрядчиком, согласие правообладателя, оформленное в соответствии с положениями Гражданского кодекса Российской Федерации (в случае, если Подрядчик не является правообладателем такого программного обеспечения), инструкция по инсталляции, руководство администратора, руководство пользователя передаются Заказчику в сроки, установленные Техническим заданием для соответствующего функционала Системы Лицензионное (сублицензионное) соглашение (договор) не может возлагать на Заказчика какие-либо обязанности (в т.ч. в части конфиденциальности, предоставления отчетности), не предусмотренные Контрактом. 4.5.9.7. Передача Заказчику исключительных прав, или простых (неисключительных) прав не может повлечь увеличение стоимости Контракта и/или изменение иных существенных условий Контракта. 4.5.9.8. Функциональность Модуля СЦ передается в объеме и в сроки, установленные Техническим заданием. 4.5.9.9. Нарушение условий настоящего раздела Технического задания, в т.ч. отсутствие соответствующего лицензионного (сублицензионного) соглашения (или договора), либо предоставление лицензионного (сублицензионного) соглашения (или договора), не соответствующего требованиям действующего законодательства Российской Федерации или требованиям Контракта, является нарушением существенных условий Контракта. 4.5.9.10. В случае, если в соответствии с пунктом 4.5.9.6 Заказчику передается исключительное право, такая передача осуществляется в порядке, установленном Гражданским кодексом Российской Федерации. 4.5.9.11. В случае, если при выполнении Работ положения пунктов 4.5.9.5-4.5.9.6 не применялись, Подрядчик в составе отчетной документации предоставляет об этом декларацию в свободной форме. Декларация должна содержать сведения о полном соответствии результата Работ требованиям Контракта, а также о неприменении при выполнении работ готового программного обеспечения (платформ, подсистем, СУБД и т.д.), которое стало частью (компонентом) Системы – выполнение требований по обеспечению в автоматизированном режиме с Национальной системой противодействия DDoS-атакам (НСПА) Центра мониторинга и управления сетью связи общего пользования ФГУП «ГРЧЦ» в рамках реализации мер по защите ГИС от атак, направленных на отказ в обслуживании; – детализированные требования к составу и содержанию работ по аттестации, а также к их результатам в соответствии с пунктами 13, 15 и 16 требований приказа ФСТЭК России от 29.04.2021 № 77 «Об утверждении Порядка организации и проведения работ по аттестации объектов информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну» 4.5.5.1. Требования к безопасности исходного кода Процесс разработки исходного кода должен соответствовать требованиям законодательства, нормативным правовым актам Российской Федерации, приказу ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по безопасности значимых объектов критической информационной инфраструктуры Российской Федерации», а также учитывать отраслевые практики безопасной разработки. Подрядчик должен предоставить Заказчику Руководство по безопасной разработке программного обеспечения (далее – Руководство), применяемое при разработке исходного кода Модуля СЦ. Руководство должно содержать: · описание процесса безопасной разработки и ролевой модели, отражающей зоны ответственности сотрудников Подрядчика; · описание процессов моделирования, оценки и формирования мер предотвращения угроз, применяемых Подрядчиком; · описание методик, применяемых Подрядчиком при разработке исходного кода (правила написания кода); · описание методик, периодичности проведения и инструментария статического, динамического, композитного и фаззинг тестирования исходного кода, включающего критерии отбора релизных версий ПО, применяемые Подрядчиком в процессе разработки; · описание механизмов безопасности в процессе сборки и доставки (безопасность образов, безопасность секретов, безопасность окружения и сборочной среды), применяемые Подрядчиком; · утвержденные шаблоны отчетной документации (в том числе акты), в соответствии с которыми Заказчик принимает результаты проверок (артефакты сборочного процесса), проведенных Подрядчиком; · описание процедур отслеживания и исправления обнаруженных ошибок и уязвимостей программного обеспечения; · описание способов и сроков доведения Подрядчиком до Заказчика информации об уязвимостях программного обеспечения, о компенсирующих мерах по защите информации или ограничениях по применению программного обеспечения, способов получения пользователями программного обеспечения его обновлений, проверки их целостности и подлинности Подрядчик должен обеспечить реализацию и проведение внутренних проверок мер по разработке безопасного ПО, приведенных в Руководстве. Подрядчик должен провести анализ угроз безопасности информации программного обеспечения в соответствии с ГОСТ 58412-2019 «Защита информации. Разработка безопасного программного обеспечения. Угрозы безопасности информации при разработке программного обеспечения». Подрядчик должен провести испытания по выявлению уязвимостей в программном обеспечении Системы: · проведение статического анализа исходного кода программы; · проведение динамического анализа исходного кода программы; · проведение композитного анализа исходного кода и образов программы; · проведение фаззинг-тестирования программы, направленного на выявление в ней уязвимостей. Испытания по выявлению уязвимостей в программном обеспечении Системы должны быть проведены в рамках: · предварительных испытаний; · опытной эксплуатации; · приемочных испытаний 4.5.9.12. Передача Заказчику комплекта документов, материалов и сведений, предусмотренных нормативными правовыми актами Российской Федерации в сфере информационных технологий, защиты информации, правовой защиты интересов государства в области интеллектуальной собственности, включая документы, подтверждающие отказ авторов (разработчиков) от исключительных прав на передаваемые объекты интеллектуальной собственности в пользу Подрядчика, с проектами заявок на государственную регистрацию в установленном порядке прав Заказчика на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, базы данных, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, осуществляется Подрядчиком в составе отчетной документации, предусмотренной условиями Контракта. 4.5.9.13. По результатам выполнения работ по развитию системы должны быть подготовлены материалы для регистрации доработанной версии Системы (объекта учета) в НФАП в соответствии с требованиями постановления Правительства Российской Федерации от 30 января 2013?г. №?62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин» (с изменениями и дополнениями) в части обязательности размещения результатов работ в национальном фонде алгоритмов и программ для электронных вычислительных машин 4.5.10. Требования по стандартизации и унификации К Модулю СЦ предъявляются следующие требования в части стандартизации и унификации: – работы по развитию Модуля СЦ должны производиться в соответствии с действующими стандартами и нормами Российской Федерации; – при создании и модернизации элементов Модуля СЦ следует руководствоваться действующими в Российской Федерации национальными стандартами и другими нормативно-техническими документами; – используемые оборудование и материалы, подлежащие обязательной сертификации, должны иметь соответствующие сертификаты; – ПО Модуля СЦ должно проектироваться и разрабатываться с учётом обеспечения требований унификации; – применяемые при создании Модуля СЦ технические (форматы данных, протоколы передачи и прочие) и организационные (регламенты, требования, инструкции) решения должны быть доступны и документированы в виде, достаточном для независимой (без обращения к Подрядчику) реализации третьими сторонами; – термины, обозначения и наименования, используемые в ПО, должны быть стандартизованы и унифицированы, выполнены на русском языке; – взаимодействие элементов и их внешнее поведение должно быть реализовано одинаково и производиться по единым правилам 4.5.11. Требования к показателям назначения 4.5.11.1. Требования к показателям назначения мероприятий по развитию Модуля СЦ В рамках выполнения работ по развитию Модуля СЦ, предусмотренных ТЗ, показатель назначения «Количество пользователей» должен соответствовать значениям, приведенным в данном разделе. Пояснения по показателям, связанным с количеством пользователей, приведены в Таблице 8. Таблица 8. Определения показателей, связанных с количеством пользователей в Модуле СЦ № Показатель Определение Расчетное количество пользователей Количество пользователей, работу которых должен обеспечить Модуль СЦ к моменту сдачи работ по Контракту с учетом достижения всех показателей назначения Расчетное количество одновременно работающих пользователей Количество одновременно работающих пользователей, работу которых должен обеспечивать Модуль СЦ к моменту сдачи работ по Контракту с учетом достижения всех показателей назначения Значения показателей количества пользователей, достижение которых необходимо обеспечить, представлено в Таблице 9 Таблица 9. Значения показателей количества пользователей № Показатель Значение 1. Расчетное количество пользователей 1 000 2. Расчетное среднее количество одновременно работающих пользователей 200 Развитие Модуля СЦ должно быть направлено на достижение следующего эффекта (показателя), подставленного в мероприятии 103.002 «Информационно-аналитическая система регулирования на транспорте (АСУ ТК)» ВПЦТ Минтранса России: Выполнение работ по развитию Модуля СЦ предусмотрено мероприятием по развитию АСУ ТК, приведенном в ВПЦТ Минтранса России на 2026-2028 гг: № 103.002 «АСУ ТК» в составе ИТ расхода 103.26.000005 «Развитие предусматривает реализацию ОКР и эффектов, приведенных в Таблице 10. Таблица 10. ОКР и эффекты, приведенные в ВПЦТ Минтранса России на 2026 г. № ОКР Дата ОКР Эффекты 1 Обеспечено информационное взаимодействие с Минобороны России о происшествиях на транспортных объектах 25.12.2026 Сокращено время сбора и передачи сведений для Минобороны России о ЧС и НС на транспорте с 120 до 10 минут 2 Обеспечена автоматизация формирования отчетов о нештатных ситуациях на транспорте, в том числе по данным внешних систем 25.12.2026 Сокращено время на подготовку отчетов о нештатных ситуациях на транспорте с 20 до 5 минут Реализация остальных ОКР не является предметом данного ТЗ и проводится в рамках отдельного технического задания. 4.5.11.2. Требования к показателям назначения мероприятий по эксплуатации Модуля СЦ. Работы по эксплуатации Модуля СЦ не должны обеспечивать режимы функционирования Модуля СЦ, приведенные в разделе 4.5.2 данного ТЗ 5. СОСТАВ И СОДЕРЖАНИЕ РАБОТ ПО РАЗВИТИЮ И ТЕХНИЧЕСКОЙ ПОДДЕРЖКЕ МОДУЛЯ СЦ (КАЛЕНДАРНЫЙ ПЛАН) 1 Техническое проектирование Сопроводительным письмом предоставляются Заказчику: · Технический проект, включая следующие документы: – Ведомость технического проекта; – Ведомость машинных носителей информации – Пояснительная записка; – Описание информационного обеспечения системы; – Описание автоматизируемых функций; – Схема функциональной структуры; – Описание организации информационной базы; – Описание программного обеспечения; · Макеты экранных форм компонента «Интерактивная карта»; · Руководство по безопасной разработке программного обеспечения; · Документ о приемке Начало: с даты заключения контракта Окончание: не позднее 31.07.2026 Значение характеристики не может изменяться участником закупки 2 Услуги по технической поддержке Модуля СЦ (с даты заключения контракта по 10.09.2026) По окончании оказания Услуг сопроводительным письмом предоставляются Заказчику: – Отчет об оказанных Услугах по технической поддержке; – Актуальные на дату окончания оказания Услуг по данному этапу исходные коды прикладного ПО на электронном носителе (в случае внесения изменений); – Инструкция по сборке и развертыванию (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство пользователя (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство администратора (в случае внесения изменений); – Документ о приемке Начало: с даты заключения контракта Окончание: не позднее 10.09.2026 3 Разработка программного обеспечения (1 очередь, пп. 4.2.1, 4.2.6 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ; – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 1 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 1 очереди; – Руководство по резервному копированию; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 16.09.2026 4 Разработка программного обеспечения (2 очередь, пп. 4.2.3, 4.2.4 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ. – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 2 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 2 очереди; – Руководство по резервному копированию; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 25.09.2026 5 Разработка программного обеспечения (3 очередь, пп. 4.2.2, 4.2.5 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ; – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 3 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 3 очереди; – Руководство по резервному копированию; – Описание ролевой модели; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 09.10.2026 6 Опытная эксплуатация (1 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акт о завершении опытной эксплуатации 1 очереди; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке 17.09.2026 Окончание: не позднее 26.10.2026 7 Опытная эксплуатация (2 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акт о завершении опытной эксплуатации 2 очереди; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке 26.09.2026 Окончание: не позднее 26.10.2026 8 Опытная эксплуатация (3 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Акт о завершении опытной эксплуатации 3 очереди; – Документ о приемке Начало: с 10.10.2026 Окончание: не позднее 26.10.2026 9 Приемочные испытания Сопроводительным письмом предоставляются Заказчику: – Программа и методика приёмочных испытаний; – Протокол приемочных испытаний; – Исходные коды и дистрибутивы на электронном носителе (при условии внесения изменений, с учетом доработок по результатам опытной эксплуатации и проведенных испытаний); – Комплект рабочей документации на Модуль СЦ (при условии внесения изменений, с учетом доработок по результатам опытной эксплуатации и проведенных испытаний); – Акт приемки Системы в эксплуатацию; – Акт приемки-передачи исключительных прав на объект; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке; – Документы в соответствии с разделом 4.5.9 ТЗ; – Обеспечение гарантийных обязательств Начало: с 27.10.2026 Окончание: не позднее 10.11.2026 10 Услуги по технической поддержке Модуля СЦ (с 11.09.2026 по 15.12.2026) По окончании оказания Услуг сопроводительным письмом предоставляются Заказчику: – Отчет об оказанных Услугах по технической поддержке; – Актуальные на дату окончания оказания Услуг по данному этапу исходные коды прикладного ПО на электронном носителе (в случае внесения изменений); – Инструкция по сборке и развертыванию (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство пользователя (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство администратора (в случае внесения изменений); – Документ о приемке Начало: с 11.09.2026 Окончание: не позднее 15.12.2026 Работы по развитию Системы (за исключением этапов проведения опытной эксплуатации и услуг по технической поддержке) могут быть выполнены досрочно. При досрочном выполнении работ (этапов работ) Подрядчик в письменной форме уведомляет Заказчика о готовности представить для приемки результаты проведения работ в соответствии с требованиями Контракта. Подрядчик также вправе досрочно приступать к работам в рамках очередного этапа при наличии технической, организационной готовности - при условии получения соответствующего согласования Заказчиком. Сдача-приемка результатов выполненных работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная, техническая документация, а также результаты Работ по каждому этапу предоставляется Заказчику в порядке, предусмотренном Контрактом и настоящим Техническим заданием, до размещения Подрядчиком в Единой информационной системе в сфере закупок документа о приемке. Документ о приемке размещается в ЕИС по каждому этапу в соответствии с условиями Контракта. Согласование документов осуществляется в электронном виде посредством переписки с адресов электронной почты Заказчика и Подрядчика, указанных в контракте. Сдача-приемка результатов выполненных работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная техническая документация, а также результаты работ предоставляются Заказчику в порядке, предусмотренном Контрактом и ТЗ, до размещения Подрядчиком в ЕИС документа о приемке. Документ о приемке размещается в ЕИС по каждому этапу в соответствии с условиями Контракта. Этапы выполнения работ по развитию Модуля СЦ приведены в Таблице 11. Таблица 11. Этапы выполнения работ по развитию Модуля СЦ. № этапа Наименование этапа Результат (отчетная документация) Срок исполнения этапа 6. ПОРЯДОК РАЗРАБОТКИ МОДУЛЯ СЦ Проектирование Модуля СЦ должно включать разработку следующих документов: – Ведомость технического проекта; – Ведомость машинных носителей информации – Пояснительная записка; – Описание информационного обеспечения системы; – Описание автоматизируемых функций; – Схема функциональной структуры; – Описание организации информационной базы; – Руководство по безопасной разработке программного обеспечения; – Описание программного обеспечения; – Макеты экранных форм компонента «Интерактивная карта». Структура документов должна соответствовать ГОСТ Р 59795-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов». Разработка Модуля СЦ должна включать в себя: – разработку программного обеспечения в части новых функций Модуля СЦ; – сборка исходного кода, развертывание и настройку доработанного программного обеспечения Модуля СЦ на вычислительных мощностях Заказчика (тестовый контур); – Комплект рабочей документации на Модуль СЦ; – разработку документа «Программа и методика предварительных испытаний»; – разработку документа «Программа и методика приемочных испытаний»; – разработку документа «Программа опытной эксплуатации». Структура документов должна соответствовать ГОСТ Р 59795-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов». В ходе выполнения работ формируется правоустанавливающая, отчетная, рабочая и техническая документация в соответствии с Контрактом и Календарным планом, приведенном в разделе 5. Значение характеристики не может изменяться участником закупки 6.1. Сведения о гарантийном обслуживании Модуля СЦ Под гарантией понимается устранение Подрядчиком своими силами и за свой счет допущенных по его вине недостатков, выявленных после приемки выполненных Работ, как в работе самой Модуля СЦ, так и недостатков в отчетной документации. Если в период гарантийного срока обнаружатся недостатки, то Подрядчик обязан устранить их за свой счет, в сроки, установленные Заказчиком. Гарантийный срок в этом случае продлевается на период устранения недостатков. Срок гарантии: 1 год с даты приемки Заказчиком результатов исполнения Этапа № 9 контракта. Подрядчиком должны быть внесены соответствующие исправления в техническую и рабочую документацию (указанную в пунктах 5 и 6 настоящего ТЗ), связанные с устранением замечаний к работе Модуля СЦ или в случае выявления Заказчиком недостатков в такой документации в период гарантийного срока. Внесение изменений в документацию технического и рабочего проектирования осуществляется в соответствии с ГОСТ 2.503-2023 и ГОСТ Р 2.504-2021. 7. ПОРЯДОК КОНТРОЛЯ И ПРИЕМКИ РЕЗУЛЬТАТОВ ВЫПОЛНЕНИЯ РАБОТ ПО РАЗВИТИЮ МОДУЛЯ СЦ Испытания должны быть организованы и проведены в соответствии с ГОСТ Р 59792-2021 «Информационная технология. Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем». Должны быть проведены следующие виды испытаний: – предварительные испытания; – опытная эксплуатация; – приемочные испытания. Указанные виды испытаний проводятся в отношении не функциональных требований и функциональных возможностей, разрабатываемых в соответствии с настоящим ТЗ. Отдельные виды испытаний проводятся поэтапно в сроки, установленные Календарным планом. Предварительные испытания, опытная эксплуатация, приемочные испытания проводятся комиссией, создаваемой организационно-распорядительным документом Заказчика, который должен определять состав комиссии, порядок ее работы. Методы предварительных испытаний и порядок их проведения должны быть определены в документе «Программа и методика предварительных испытаний», который должен быть утвержден Заказчиком до начала предварительных испытаний. По результатам предварительных испытаний оформляется Протокол предварительных испытания и Акт о приемке в опытную эксплуатацию. Порядок проведения и методы испытаний во время опытной эксплуатации должны быть определены в документе «Программа опытной эксплуатации», который должен быть утвержден Заказчиком до начала опытной эксплуатации. Ход и результаты опытной эксплуатации отражаются в документе «Журнал опытной эксплуатации», и учитываются в ходе приемочных испытаний. По результатам опытной эксплуатации подписывается Акт о завершении опытной эксплуатации Значение характеристики не может изменяться участником закупки До момента подключения внешних ИС, Подрядчиком могут быть использованы эмуляторы ИС для прохождения предварительных испытаний, опытной эксплуатации и приемочных испытаний. В рамках опытной эксплуатации должны быть проведены мероприятия по нагрузочному тестированию Модуля СЦ. Документ «Программа и методика приемочных испытаний» должен быть разработан с учетом недостатков, выявленных в ходе опытной эксплуатации, утвержден Заказчиком до начала приемочных испытаний, при этом проверки Модуля СЦ в части не устраненных недостатков, выявленных в процессе опытной эксплуатации, должны быть вынесены в отдельный раздел «Программы и методики приемочных испытаний». В процессе приемочных испытаний должно быть проверено устранение недостатков, полученных в ходе опытной эксплуатации. После завершения устранения всех замечаний, препятствующих приемке Системы в эксплуатацию, перечисленных в Протоколе приемочных испытаний, Подрядчик должен письменно уведомить Заказчика о том, что все замечания устранены, после чего приемочные испытания по решению Заказчика могут быть проведены повторно. Процедура приемочных испытаний проводится до подписания Протокола приемочных испытаний, не содержащего замечаний, препятствующих приемке Системы в эксплуатацию. Приемочные испытания Системы считаются завершенными успешно, если Протокол приемочных испытаний не содержит замечаний, препятствующих приемке Системы в эксплуатацию 8. ТРЕБОВАНИЯ К СОСТАВУ И СОДЕРЖАНИЮ РАБОТ ПО ПОДГОТОВКЕ МОДУЛЯ СЦ К ВВОДУ В ЭКСПЛУАТАЦИЮ По результатам проведения приемочных испытаний оформляется Протокол приемочных испытаний и Акт приемки в эксплуатацию. В случае, если взаимодействие с внешними системами не может быть проверено на средах постоянной эксплуатации взаимодействующих систем (по причине неготовности со стороны внешней системы или иным причинам), функции взаимодействия, разработанные в соответствии с требованиями ТЗ, должны быть проверены на тестовых данных с использованием программ-имитаторов взаимодействия. По результатам выполнения этапа приемочных испытаний должны быть подготовлены материалы для регистрации доработанной версии Модуля СЦ (объекта учета) в НФАП в соответствии с требованиями постановления Правительства Российской Федерации от 30 января 2013?г. №?62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин» (с изменениями и дополнениями) в части обязательности размещения результатов работ в национальном фонде алгоритмов и программ для электронных вычислительных машин. Сдача-приемка результатов выполнения Работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная, техническая документация, а также программное обеспечение предоставляется Заказчику в порядке, предусмотренном Контрактом и ТЗ до размещения Подрядчиком в Единой информационной системе в сфере закупок документа о приемке. Результаты проведения опытной эксплуатации, предварительных и приемочных испытаний должны быть зафиксированы в соответствующих протоколах и актах. Выявленные отклонения от настоящего ТЗ, оформляются как недостатки Модуля СЦ Значение характеристики не может изменяться участником закупки Протоколы предварительных и приемочных испытаний должны содержать вывод о соответствии Модуля СЦ предъявляемым требованиям, а также сроки устранения замечаний и реализации рекомендаций, сформулированных комиссией в ходе предварительных и приемочных испытаний. Условием для передачи Модуля СЦ в промышленную эксплуатацию является устранение всех замечаний. Документация на Модуль СЦ и ее части (техническая и рабочая) должна содержать исчерпывающее описание принятых проектных решений в объеме, достаточном для ее дальнейшего развития и эксплуатации. Техническая и рабочая документация должна содержать описание разработанных результатов работ, в том числе программ для ЭВМ, прикладных программных интерфейсов, алгоритмов и протоколов информационного взаимодействия, технических требований, спецификаций и форматов обмена данными для взаимодействия с другими информационными системами, в объеме, достаточном для их установки, настройки, эксплуатации и развития в дальнейшем без привлечения Подрядчика. Исходные коды передаются в виде и составе, позволяющем провести: – сборку (компиляцию) Модуля СЦ в контролируемой Заказчиком среде; – установку полученной Модуля СЦ на специально подготовленную контролируемую Заказчиком инфраструктуру; – проверку функциональных возможностей Модуля СЦ; – оформление Модуля СЦ в качестве объекта национального фонда алгоритмов и программ для электронных вычислительных машин 8.1. Требования, предъявляемые в соответствии с Приказом Минцифры России от 17.12.2020 № 715 «Об утверждении типовых условий контрактов на выполнение работ по созданию и (или) развитию (модернизации) государственных (муниципальных) и (или) иных информационных систем» Передача исходных кодов, разработанных в ходе выполнения работ, программ для электронных вычислительных машин (далее – программа для ЭВМ) должна сопровождаться передачей всех необходимых для сборки и запуска программы для ЭВМ библиотек зависимостей, программных сценариев (скриптов) для проведения установки (развертывания) программы для ЭВМ. Подрядчик в процессе сдачи-приемки работ по Контракту должен провести демонстрацию процесса и установки (развертывания) разработанных программ для ЭВМ. Документация на Модуль СЦ должна содержать описание принятых проектных решений в объеме, достаточном для ее дальнейшего развития и эксплуатации 9. ТРЕБОВАНИЯ К ДОКУМЕНТИРОВАНИЮ 9.1. Общие требования Документация на Модуль СЦ должна быть разработана в составе, указанном в разделах 5-8 данного ТЗ, и должна удовлетворять требованиям комплекса стандартов и руководящих документов на автоматизированные системы: – ГОСТ Р 2.105-2019 в части оформления текстовых документов; – ГОСТ 34.201-2020 в части наименования и обозначения документов. Документация на Модуль СЦ должны оформляться на листах формата А4. Допускается для размещения рисунков и таблиц использование листов формата А3 с подшивкой по короткой стороне листа. Документы объемом более 25 (двадцати пяти) листов должны содержать информационную часть, состоящую из аннотации и содержания. Исходные коды должны быть представлены в 1 (одном) экземпляре на электронном носителе, отчетные материалы должны быть представлены в 2 (двух) экземплярах на бумажном носителе (по одному экземпляру для Заказчика и Подрядчика) и в 1 (одном) экземпляре на электронном носителе в формате документов DOCX и PDF. При разработке документов на Модуль СЦ допускается отклонение от требований комплекса стандартов, описанных выше. Документам на Модуль СЦ должны в обязательном порядке присваиваться уникальные децимальные номера в соответствии с порядком, установленном в ГОСТ 34.201-2020. Документ «Программа и методика предварительных испытаний» должен включать приложения с формой протокола предварительных испытаний и формой акта приемки в опытную эксплуатацию. Документ «Программа опытной эксплуатации» должен включать приложение с формой журнала опытной эксплуатации. Документ «Программа и методика приемочных испытаний» должен включать приложения с формой протокола приемочных испытаний и формой акта приемки в эксплуатацию Значение характеристики не может изменяться участником закупки 10. ИСТОЧНИКИ РАЗРАБОТКИ 10.1. Список литературы Специальная литература для разработки ТЗ не использовалась. 10.2. Нормативно-методические документы Список используемых нормативно-методических документов представлен в разделе 1.6 технического задания. ? Приложение А Эскизы визуального оформления компонента «Интерактивная карта» Значение характеристики не может изменяться участником закупки Приложение Б Параметры оказания услуг Б.1. Базовые параметры оказания Услуг Базовые параметры оказания Услуг приведены ниже: – режимы оказания Услуг (таблица Б.1.1); – сроки предоставления отчетности (таблица Б.1.2). Таблица Б.1.1 - Режимы оказания Услуг № п/п Параметр Значение Значение характеристики не может изменяться участником закупки 1 Режим работы Системы Круглосуточно (24х7) 2 Режим доступности информационно-консультационной поддержки пользователей Системы 2.1 Прием и регистрация обращений (заявок) в СРО Регистрация обращений (заявок) производится круглосуточно в режиме 24х7, без праздников и выходных дней. Обработка заявок первой линией поддержки осуществляется в рабочие дни с 9 до 18 часов 2.2 Консультирование сотрудников Заказчика и пользователей Системы в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 3 Режим доступности по решению инцидентов, связанных с работой ППО: 3.1 - приоритет «Критический» Круглосуточно (24х7) 3.2 - приоритет «Высокий» Круглосуточно (24х7) 3.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 3.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4 Режим доступности услуг по адаптации, конфигурации и коррекционному сопровождению Системы 4.1 - приоритет «Критический» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.2 - приоритет «Высокий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 5 Режим доступности по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности 5.1 - приоритет «Критический» Круглосуточно (24х7) 5.2 - приоритет «Высокий» Круглосуточно (24х7) 5.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 5.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) Таблица Б.1.2. Сроки предоставления отчетности, с момента получения запроса № п/п Параметр Значение 1 Предоставление отчета об оказанных услугах за произвольный период 10 рабочих дней 2 Предоставление подробной информации по инциденту с приоритетом «Критический» 16 рабочих часов 3 Предоставление актуализированной документации 10 рабочих дней Б.2. Приоритеты и регламентные сроки решения обращений (заявок) В зависимости от уровня сбоя в работе Системы обращению (заявке) присваивается один из следующих приоритетов, а также в зависимости от приоритета обращения (заявки) устанавливаются следующие контрольные сроки решения в соответствии с таблицей ниже (Таблица Б.2.1). Таблица Б.2.1 – Приоритеты и регламентные сроки решения обращений (заявок) № п/п Приоритет Максимальное время реагирования Время решения (срок выполнения) Описание приоритета По информационно-консультационной поддержке сотрудников Заказчика и пользователей Системы 1 - не более 1 часа не более 10 часов - По решению инцидентов, связанных с работой ППО: 1 Критический не более 30 минут не более 4 часов - полная недоступность ППО; - недоступность ключевых функций - ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО; - невозможность информационного обмена с ППО для ИС более 4 часов 2 Высокий не более 1 часа не более 8 часов - ошибки/сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; - снижение быстродействия СПО (время отклика ППО на операции превышает 30 секунд); - недоступность управления правами и ролями пользователей 3 Средний не более 4 часов не более 24 часов - невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым -недоступность функции формирования отчетов 4 Низкий не более 8 часов не более 40 часов - отклонение в работе ППО, не влияющее на корректную работу функций; - другие сбои и ошибки, затрагивающие основные функции ППО По адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) 1 Критический не более 40 минут не более 8 часов - изменения, необходимые при проведении аварийно-восстановительных работ для возобновления работоспособности Системы; - изменения, связанные с критичными ошибками, блокирующими возможность оказания государственных услуг и/или чтение и внесение данных в Систему 2 Высокий не более 1 часа не более 40 часов - изменения, относящиеся к обеспечению работоспособности основной функциональности Системы, устраняют выявленные дефекты в работе Системы, оказывающие существенное влияние на работу пользователей в Системе; - изменения, затрагивающие три и более подсистемы/модуля Системы для адаптации 3 Средний не более 4 часов не более 72 часов - изменения, связанные с развитием/улучшением/оптимизацией Системы и выводом новой функциональности в штатном режиме для одного-двух модулей/подсистем; - изменения, связанные с развитием интеграционных механизмов Системы, например обновление существующих и/или реализация новых видов сведений СМЭВ, обновление существующих и/или реализация новых API, адаптация и/или изменение механизмов импорта и экспорта данных Системы и т.д. 4 Низкий не более 8 часов не более 160 часов - изменения, связанные с ошибками/корректировкой/изменением в отображении информации в пользовательском графическом интерфейсе Системы (графика, текст, органы управления, элементы интерфейса) По устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности 1 Критический не более 30 минут не более 24 часов - критические уязвимости, влияющие на возможную полную недоступность ППО, ключевых функций Системы, ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО без возможности восстановления работоспособности Системы. - Критический уровень CVSS > 8.0 2 Высокий не более 1 часа не более 84 часов - критические уязвимости, влияющие на ошибки и сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО. - Высокий уровень CVSS 5.0 - 8.0 3 Средний не более 4 часов не более 120 часов - уязвимости, влияющие на невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым - Средний уровень CVSS 2.0 - 4.9 4 Низкий не более 8 часов не более 160 часов - уязвимости, влияющие на отклонение в работе ППО, не влияющее на корректную работу функций; - другие сбои и ошибки, затрагивающие основные функции ППО - Низкий уровень CVSS < 2.0 Взаимодействие Заказчика и Подрядчика в части регистрации и контроля времени реагирования и решения обращения (заявки) осуществляется через СРО. Заказчик предоставляет Подрядчику доступ к СРО после заключения Контракта. Поступившие от разных пользователей заявки по поводу однотипных инцидентов или имеющие общую причину должны объединяться в одну заявку. Срок выполнения включает время диагностики инцидента, в ходе которого определяется причина инцидента (проблемы) и способ его устранения. Подрядчик должен обеспечить функционирование Модуля СЦ в соответствии с требованиями и параметрами, указанными в настоящем ТЗ и Регламенте оказании услуг. Основные параметры быстродействия типовых операций в Модуле СЦ указаны в таблице ниже (таблица Б.2.2). Таблица Б.2.2 - Параметры быстродействия Модуля СЦ № п/п Наименование параметра Значение (секунд) 1 Среднее время получения сообщения из очереди сообщений 10 2 Среднее время получения ответа от Системы 5 3 Среднее время открытия карточки реестра 5 Приложение В Регламент оказания услуг 4.3. Форма обращения (заявки) на оказание услуг по адаптационному конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) При подаче обращения (заявки) типа «ЗНИ» в СРО указывается (Таблица 7): Таблица 7 – Описание атрибутов формы обращения (заявки) на оказание услуг по адаптационному, конфигурационному и коррекционному сопровождению Системы Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 10) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 9) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 10) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 10) Категория обращения (заявки): запрос на изменение Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 7) Приоритет изменения Время, очередность решения обращения (заявки), ресурсы, привлекаемые для решения обращения (заявки), порядок/процедура действий при решении обращения (заявки) – поле СРО «Приоритет» (см. рисунок 7) Тип изменения Справочник, классифицирующий типовые запросы характерные для Системы – поле СРО «Предмет обращения» (см. рисунок 7) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 7) Текст запроса на оказание услуги по адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 7) Значение характеристики не может изменяться участником закупки На рисунке 7 приведена форма обращения (заявки) типа «ЗНИ» в СРО. Рисунок 7 - Форма обращения (заявки) типа «ЗНИ» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуг по адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей), заполненную в свободной форме 4.4. Форма обращения (заявки) на оказание услуги по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности При подаче обращения (заявки) типа «Инцидент» в СРО указывается (Таблица 8): Таблица 8 – Описание атрибутов формы обращения (заявки) на оказание услуг по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 8) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 8) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 8) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 8) Категория обращения (заявки): инцидент Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 8) Приоритет Время, очередность решения обращения (заявки), ресурсы, привлекаемые для решения обращения (заявки), порядок/процедура действий при решении обращения (заявки) – поле СРО «Приоритет» (см. рисунок 8) Тип изменения Справочник, классифицирующий типовые запросы характерные для Системы – поле СРО «Предмет обращения» (см. рисунок 8) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 8) Текст запроса на оказание услуги по обновлению или удалению уязвимых компонентов (библиотек) ППО в соответствии с требованиями к обеспечению информационной безопасности Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 8) На рисунке 8 приведена форма обращения (заявки) типа «Инцидент» в СРО. Рисунок 8 - Форма обращения (заявки) типа «Инцидент» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуги по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности, заполненную в свободной форме Приложение 1 к Регламенту Матрица ответственных за взаимодействия в рамках выполнения работ по техническому сопровождению Системы Таблица 1 – Ответственные за взаимодействия в рамках выполнения работ по техническому сопровождению Системы со стороны Исполнителя ФИО Должность Адрес электронной почты Телефон — — — Общий контакт Приложение 2 к Регламенту Приоритеты и регламентные сроки решения обращений (заявок) Приоритеты и регламентные сроки решения обращений (заявок) приведены в таблице 1. Таблица 1 – Приоритеты и регламентные сроки решения обращений (заявок) № п/п Приоритет Максимальное время реагирования Время решения (срок выполнения) Описание приоритета По информационно-консультационной поддержке сотрудников Заказчика и пользователей Системы 1 – не более 1 часа не более 10 часов – По решению инцидентов, связанных с работой ППО 1 Критический не более 30 минут не более 4 часов – полная недоступность ППО; – недоступность ключевых функций; – ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО; – невозможность информационного обмена с ППО для ИС более 4 часов 2 Высокий не более 1 часа не более 8 часов – ошибки/сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; – снижение быстродействия СПО (время отклика ППО на операции превышает 30 секунд); – невозможность управления правами и ролями пользователей 3 Средний не более 4 часов не более 24 часов – невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым недоступность функции формирования отчетов 4 Низкий не более 8 часов не более 40 часов – отклонение в работе ППО, не влияющее на корректную работу функций; – другие сбои и ошибки, затрагивающие основные функции ППО По адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) 1 Критический не более 40 минут не более 8 часов – изменения необходимые при проведении аварийно-восстановительных работ для возобновления работоспособности Системы; – изменения, связанные с критичными ошибками, блокирующими возможность оказания государственных услуг и/или чтение и внесение данных в Систему 2 Высокий не более 1 часа не более 40 часов – изменения относящиеся к обеспечению работоспособности основной функциональности Системы, устраняют выявленные дефекты в работе Системы, оказывающие существенное влияние на процесс оказания государственных услуг и работу пользователей в Системе; – изменения, затрагивающие три и более подсистемы/модуля Системы для адаптации 3 Средний не более 4 часов не более 72 часов – изменения, связанные с развитием/улучшением/оптимизацией Системы и выводом новой функциональности в штатном режиме для одного-двух модулей/подсистем; – изменения, связанные с развитием интеграционных механизмов Системы, например, обновление существующих и/или реализация новых видов сведений СМЭВ, обновление существующих и/или реализация новых API, адаптация и/или изменение механизмов импорта и экспорта данных Системы и т.д. 4 Низкий не более 8 часов не более 160 часов – изменения, связанные с ошибками/ корректировкой/изменение в отображении информации в пользовательском графическом интерфейсе Системы (графика, текст, органы управления, элементы интерфейса) По устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности 1 Критический не более 30 минут не более 24 часов – критические уязвимости, влияющие на возможную полную недоступность ППО, ключевых функций Системы, ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО без возможности восстановления работоспособности Системы; – Критический уровень CVSS > 8.0 2 Высокий не более 1 часа не более 84 часов – критические уязвимости, влияющие на ошибки и сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; – Высокий уровень CVSS 5.0 - 8.0 3 Средний не более 4 часов не более 120 часов – уязвимости, влияющие на невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым; – Средний уровень CVSS 2.0 - 4.9 4 Низкий не более 8 часов не более 160 часов – уязвимости, влияющие на отклонение в работе ППО, не влияющее на корректную работу функций; – другие сбои и ошибки, затрагивающие основные функции ППО; – Низкий уровень CVSS < 2.0 Приложение Г Форма Отчета об оказанных услугах Отчет об оказанных услугах за этап «наименование этапа» в период с «__» _________ по «__» _________. № п/п Наименование услуги Общее количество Номер ОРС Краткое Описание Время реагирования по ТЗ Время реагирования фактическое Время решения по ТЗ Время решения фактическое Результат соблюдения времени реагирования Результат соблюдения времени решения Примечание 1 Услуги по информационно-консультационной поддержке работников Заказчика 2 546782 Консультация по работе Модуля СЦ 1 2 10 часов 11 часов Нет Нет 567123 Консультация по схеме БД 1 1 10 часов 1 час Да Да 2 … … Заказчик Подрядчик /Должность/ /Должность/ ____________________ /Ф.И.О/ ___________________ /Ф.И.О/ М.П. М.П. «_____»_______________________202_г. «_____»_______________________202_г Приложение 1 к Отчету об оказанных услугах Журнал обращений (заявок) на оказание услуги по информационно-консультационной поддержке пользователей Системы (шаблон) Наименование Исполнителя в этапе «наименование этапа» в период с ________________ по _______________ оказал(о) Услугу по поддержке пользователей Системы в объеме, указанном в Таблице 1 Таблица 1 - Журнал обращений (заявок) пользователей Системы № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. ИТОГО зарегистрировано: Всего обращений (заявок): ________ ИТОГО решено: Всего обращений (заявок): ________ Приложение 2 к Отчету об оказанных услугах Журнал обращений (заявок) по решению инцидентов, связанных с работой ППО (шаблон) Наименование Исполнителя в этапе «наименование этапа» в период с ________________ по _______________ оказал(о) Услугу по решению инцидентов в объеме, указанном в Таблице 1. Таблица 1 - Журнал по решению инцидентов № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. ИТОГО зарегистрировано: Всего инцидентов: ________ ИТОГО решено: Всего инцидентов: ________ Приложение 3 к Отчету об оказанных услугах Журнал обращений (заявок) выполнения адаптационного, конфигурационного и коррекционного сопровождения Системы (шаблон) Журнал выполнения адаптации, конфигурации и коррекции Системы сформирован за этап «наименование этапа» в период с «__» _________ по «__» ____________ и представлен в таблице ниже (Таблица 1). Таблица 1 - Журнал выполнения адаптации, конфигурации и коррекции сопровождения Системы № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. Количество выполненных заявок за этап: ________ Приложение 4 к Отчету об оказанных услугах Журнал обращений (заявок) по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности (шаблон) Журнал обращений (заявок) по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности сформирован за этап «наименование этапа» в период с «__» _________ по «__» ____________ и представлен в таблице ниже (Таблица 1). Таблица 1 - Журнал выполнения заявок по устранению уязвимостей в ППО № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. Количество выполненных заявок за этап: ________ Приложение Д Форма Протокола проверки результатов организационно-штатных и подготовительных мероприятий (шаблон) Протокол проверки результатов организационно-штатных и подготовительных мероприятий Настоящий Протокол содержит результаты проверки организационно-штатных и подготовительных мероприятий, проведенных Исполнителем (Таблица Д.1). Таблица Д.1. Протокол проверки результатов № Мероприятия Подготовительного этапа Результат проверки 1. Определить и направить Заказчику документ «Ответственные за взаимодействия в рамках выполнения работ по техническому сопровождению Системы со стороны Исполнителя». Документ содержит контактную информацию (ФИО, должность, адрес электронной рабочей почты, номер телефона) не менее чем о 2 лицах, ответственных за оказание услуг со стороны Подрядчика Выполнено/Не выполнено 2. Обеспечить подключение специалистов Подрядчика к Системе Выполнено/Не выполнено 3. Обеспечить подключение специалистов Подрядчика к СРО Выполнено/Не выполнено Заказчик Подрядчик /Должность/ /Должность/ ____________________ /Ф.И.О/ ___________________ /Ф.И.О/ М.П. М.П. «_____»_______________________202_г. «_____»_______________________202_г 4.2. Форма обращения (заявки) на оказание услуги по решению инцидентов, связанных с работой ППО При подаче обращения (заявки) типа «Инцидент» в СРО указывается (Таблица 6): Таблица 6 – Описание атрибутов формы обращения (заявки) на оказание услуги по решению инцидентов, связанных с работой ППО Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 6) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 6) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 6,) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 6) Категория обращения (заявки): инцидент Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 6) Приоритет изменения Время - одно из значений: Низкий, Средний, Высокий или Критический. Определяет, очередность решения обращения (заявки), ресурсы, привлекаемые для решения обращения (заявки), порядок/процедура действий при решении обращения (заявки) – поле СРО «Приоритет» (см. рисунок 6,) Тип изменения Справочник, классифицирующий типовые запросы характерные для Системы – поле СРО «Предмет обращения» (см. рисунок 6) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 6) Полное описание инцидента, включая скриншоты и описание шагов, приведших к неисправности Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 6) Однократность/неоднократность Круг пользователей или компьютеров, затронутых данным инцидентом Действия, предпринятые для самостоятельного решения инцидента (при наличии) Версии используемого программного обеспечения на клиентской рабочей станции, где воспроизводится ошибка (операционная система, прикладное программное обеспечение) Дополнительная информация На рисунке 6 приведена форма обращения (заявки) типа «Инцидент» в СРО. Рисунок 6 - Форма обращения (заявки) типа «Инцидент» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуги по решению инцидентов, связанных с работой ППО, заполненную в свободной форме Уровень технической поддержки Организационно-структурная часть технической поддержки, имеющая определённые организационно-нормативными документами зоны ответственности, обязанности, а также временные нормативы, в течение которых эти обязательства должны выполняться либо эскалироваться на следующий уровень технической поддержки Услуги Услуги по технической поддержке Информационно-аналитической системы регулирования на транспорте АСУ ТК ФИО Фамилия, имя, отчество Эскалация Процедура повышения внимания к обращению (заявке) путем повышения его приоритета и/или передачи на следующий уровень технической поддержки, а также привлечение ролей, которые могут принимать решения без передачи на следующий уровень технической поддержки API Англ. Application Programming Interface — программный интерфейс приложения, интерфейс прикладного программирования — описание способов (набор классов, процедур, функций, структур или констант), которыми одна компьютерная программа может взаимодействовать с другой программой CVSS Англ. Common Vulnerability Scoring System - открытый стандарт, используемый для расчета количественных оценок уязвимости в безопасности компьютерной системы, обычно с целью понять приоритет ее исправления. В современном инструментарии информационной безопасности используется версия 3.0 и выше с дополнительными метриками к базовым оценкам ID Англ. Identifier – идентификатор, уникальный признак объекта, позволяющий отличать его от других объектов, то есть, идентифицировать SLA Англ. Service Level Agreement - утвержденные условия по обработке обращения (заявки) с установленными метриками времени, которые определяют пороговые значения для эскалации в зависимости от статуса обращения (заявки) (например, время реакции – время от регистрации до осуществления первичной обработки, время решения – время от регистрации обращения (заявки) до его решения и т.д.) SQL Англ. Structured Query Language — «язык структурированных запросов», — декларативный язык программирования, применяемый для создания, модификации и управления данными в реляционной базе данных, управляемой соответствующей СУБД 1 Общие сведения 1.1 Полное наименование Услуг Оказание услуг по технической поддержке Модуля СЦ АСУ ТК в 2026 году. 1.2 Предмет Регламента оказания услуг Требования Технического задания 2 Общие положения 2.1 Цель и задачи оказания услуг Целью технической поддержки Системы является обеспечение ее стабильного и безопасного функционирования и эксплуатации, предупреждение, выявление и устранение сбоев в работе Системы и минимизация их неблагоприятного влияния. Для достижения поставленной цели требуется решение следующих задач: 1. Обеспечение информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы. 2. Поддержание параметров функционирования ППО Системы, удовлетворяющих требованиям производственных процессов, включая их непрерывность. 3. Обеспечение бесперебойного функционирования ППО и своевременное устранение сбоев и аварийных ситуаций в Системе. 4. Своевременное устранение уязвимостей при выявлении таковых, в соответствии с требованиями к обеспечению информационной безопасности. 5. Адаптация, конфигурирование, коррекция программного обеспечения в соответствии с изменениями нормативно-правовой базы и запросами уполномоченных сотрудников органов государственной власти, включая выполнение процедур тестирования и участие в обновлениях ППО на стендах Заказчика. 6. Обеспечение сохранения работоспособности ППО в изменяемой среде эксплуатации. 7. Ведение документации по настоящему контракту и инициирование актуализации документации на Систему по результатам обработки запросов Заказчика и внесения соответствующих изменений в ППО 2.2 Общее описание процесса оказания сопровождения (технической поддержки) Системы Процесс оказания технической поддержки Системы включает: 1. Поступление обращений (заявок) от пользователей и их регистрацию. 2. Сопровождение обращений (заявок) в соответствии с их классификацией и приоритизацией, в том числе, с их последующей эскалацией. 3. Определение ролей и регламент их взаимодействия при осуществлении деятельности по процессу. 4. Решение обращений (заявок) в установленные настоящим Регламентом сроки. 5. Взаимодействие между 1-м, 2-м и 3-м уровнями технической поддержки, в том числе, с формированием заданий для сопровождения Системы. 6. Контроль качества выполняемых Исполнителем работ, состоящий из проверки сценария, приводящего к ошибке, зафиксированной в Инциденте, и/или к ошибке воспроизведения, а также тестирование внесенных изменений в рамках ЗНИ. 7. Обеспечение мониторинга и проведение анализа процесса обработки поступающих в техническую поддержку обращений (заявок). Техническая поддержка реализуется путем проведения ответственными сотрудниками соответствующей информационно-консультационной деятельности в соответствии с определенными ролями, а также выполнения Исполнителем конкретных действий по своевременному выявлению причин сбоев и аварийных ситуаций и их устранению, а также по адаптации, конфигурированию, корректировке Системы, включая выполнение процедур тестирования и участия в обновлениях Системы. Все роли подразделяются на уровни поддержки, взаимодействующие между собой в соответствии с блок-схемой процесса технической поддержки. Общая схема процесса рассмотрения обращений (заявок) в соответствии с видами технической поддержки представлена на рисунке 1. . Рисунок 1 - Общая схема процесса рассмотрения обращений (заявок) в соответствии с видами технической поддержки 2.3 Каналы связи Должна быть предусмотрена омниканальность в части приема обращений (заявок). Получение обращений (заявок) технической поддержкой происходит по следующим каналам связи: – СРО; – электронная почта; – телефонная линия. Исполнитель обеспечивает прием обращений (заявок) от Заказчика и предоставляет информацию в рамках оказания услуг по техническому сопровождению Системы, руководствуясь матрицей взаимодействия, приведенной в Приложении 1 к настоящему Регламенту 3 Порядок оказания Услуг 3.1 Типы обращений (заявок) Обращения и заявки Заказчика классифицируются в соответствии с приоритетами и регламентными сроками, указанными в Приложении 2 к настоящему Регламенту. Регистрация обращений и заявок предусматривает создание новой записи в СРО с присвоением поступившему обращению или заявке (новой записи) уникального идентификатора. Запись в СРО должна содержать вопрос или проблему, которую требуется решить или оказать консультацию. Если обращение или заявка автоматически зарегистрированы в СРО при отправке представителем Заказчика, Исполнитель проверяет корректность указанного типа обращения (заявки) и может обратиться к Заказчику с просьбой корректировки, предоставив обоснования в соответствии с настоящей классификацией (Таблица 1) Таблица 1 - Типы обращений (заявок) Тип обращения (заявки) Описание Запрос на обслуживание Подготовка SQL запроса к СУБД для решения прикладной задачи и д р. – запрос на любое действие, не являющееся запросом информации и несовершенный на основе происшествия, прямо или косвенно влияющего на работу Системы Консультация (входит в тип обращения (заявки) «Запрос на обслуживание») «Где взять / куда обратиться...?», «Как сделать / выполнить…», «Как это работает…?» - запрос, имеющий своей целью получение информационной поддержки Инцидент Разбор ошибок/сбоев и подготовка материалов (корректировочных релизов, инструкций) для Заказчика для устранения ошибок/сбоев, которые приводят к частичному и полному нарушению работоспособности всех или отдельных функций ППО. Подготовка изменения и материалов, необходимых для проведения аварийно-восстановительных работ для возобновления работоспособности Системы. ЗНИ Подготовка изменений, связанных с изменением, улучшением/оптимизацией Системы и выводом новой модифицированной функциональности в штатном режиме. Подготовка изменений, связанных с модификацией существующих и/или реализация новых интеграционных механизмов для получения/обработки данных внешних систем. Подготовка изменений графического интерфейса по требованиям Заказчика 3.2 Участники технической поддержки, осуществляющие сопровождение обращений (заявок) Техническая поддержка Системы должна быть организована на трех уровнях: 1. Первый и второй уровни технической поддержки организуется Заказчиком. 2. Третий уровень технической поддержки организуется Исполнителем. Зона ответственности каждого уровня технической поддержки указана в Таблице 2. Таблица 2 - Зона ответственности каждого уровня технической поддержки Участники технической поддержки Описание Первый уровень технической поддержки (далее – 1-й уровень) Группа ответственных сотрудников 1-го уровня Заказчика, осуществляющая прием и первичную обработку обращений (заявок) (описание предмета обращения, первичная классификация и приоритизация, определение назначения, маршрутизация обращений (заявок) по назначению), руководствуется в своей работе настоящим Регламентом и БЗ, наполняемой 2-м уровнем поддержки, самостоятельно решает часть обращений (заявок), связанных с недостаточной квалификацией пользователей или настройками в рамках своей компетенции. В случае невозможности решения обращений (заявок) на 1-ом уровне ответственный сотрудник передает ее на 2-й уровень Второй уровень технической поддержки (далее – 2-й уровень) Группа ответственных сотрудников 2-го уровня Заказчика по установленным компетенциям (информационная безопасность, сопровождение и эксплуатация информационно-аналитических систем, развитие информационно-аналитических систем, техническая поддержка информационно-аналитических систем) отвечает за поддержание работоспособности Системы, обработку обращений (заявок) и их решение в регламентные сроки в соответствии с установленными приоритетами. Осуществляет информационно-консультационную поддержку пользователей Системы в рамках своей компетенции. Оказывает экспертную помощь ответственным сотрудникам 1-го уровня в части формирования БЗ, содержащей ответы на часто задаваемые вопросы пользователей, с целью передачи знаний, навыков и инструментария на 1-й уровень для ускорения решения обращений (заявок). В случае невозможности решения обращения (заявки) на 2-ом уровне ответственный сотрудник передает его на 3-й уровень. При выявлении необходимости изменений в ППО Системы инициирует формирование обращения (заявки) и направляет его на группу ответственных сотрудников 3-го уровня по соответствующему классификатору (ЗНО, ЗНИ, и т.д.) Третий уровень технической поддержки (далее – 3-й уровень) Группа ответственных сотрудников Исполнителя, отвечающая за устранение сбоев и аварий, проведение информационно-консультационной поддержки пользователей Системы, проведение адаптации и конфигурирования Системы в объемах действующих контрактов на оказание технической поддержки 3.3 Перечень и описание статусов обращений (заявок) В Таблице 3 приведен перечень статусов обращений (заявок), действующий в СРО, и их описание. Таблица 3 - Перечень статусов обращений (заявок) и их описание Статус Описание Зарегистрирован Обращение (заявка) принято и зарегистрировано Направлен в группу Присваивается при назначении ответственными сотрудниками 1-го уровня группе ответственных сотрудников 2-го уровня по тематике обращения (заявки) после заполнения всей необходимой информации и полей обращения (заявки), а также при его передаче между группами 2-го уровня Передан в группу Присваивается при передаче обращения (заявки) ответственными сотрудниками 2-го уровня на группу ответственных сотрудников 3-го уровня Назначен Присваивается при назначении обращения (заявки) на ответственного сотрудника для его решения в рамках компетенции В работе Присваивается при приеме обращения (заявки) в работу ответственным сотрудником для его решения Решен Присваивается ответственным сотрудником, выполнившим работы по обращению (заявке) Закрыт Присваивается автоматически при решении запроса по обращению (заявке), а также отсутствии дополнительных запросов пользователя в соответствии с действующим SLA, или при подтверждении решения обращения (заявки) со стороны пользователя Запрос доп. информации Присваивается при необходимости запроса дополнительной информации и/или уточнения предмета обращения по обращению (заявке) у пользователя Ответ предоставлен Присваивается после ответа пользователем на запрос дополнительной информации Отклонен Присваивается, если обращение (заявка) не актуальна (по информации от пользователя), отсутствует техническая возможность решения обращения (заявки), предмет обращения не входит в компетенции технической поддержки, или существует влияние доработки на другие компоненты, что нарушает общий порядок работы Системы Согласование Присваивается при необходимости согласования направления обращения (заявки) ответственным сотрудником Заказчика на 3-й уровень Анализ Присваивается при проведении анализа на предмет возможности внесения изменений, связанных с развитием/улучшением/оптимизацией Системы и выводом новой функциональности и оценке ресурсоемкости Тестирование Присваивается Исполнителем при завершении разработки и проведенном предварительном тестировании для последующего осуществления приемочного тестирования Специалистом 2-го уровня Релиз Присваивается ответственным сотрудником Заказчика при принятии решения о возможности вывода доработки в продуктивную среду Утверждение заказчиком Присваивается при согласовании группой профильных специалистов на 2-м уровне поддержки с пользователем технического задания для внесения изменений, связанных с развитием/улучшением/оптимизацией Системы и выводом новой функциональности Доработка Присваивается в случае несогласования Заказчиком работ, проведенных Исполнителем в рамках контрактных обязательств, по внесению изменений, связанных с развитием/улучшением/оптимизацией Системы и выводом новой функциональности в штатном режиме, и необходимости последующего направления Исполнителю для ее доработки Отложен Присваивается в случае невозможности выполнения запроса, изложенного в обращении (заявке), в связи с необходимостью запроса дополнительной информации у третьих сторон 3.4 Порядок регистрации и сопровождения Заявок Порядок регистрации и сопровождения обращений (заявок) в рамках оказываемых услуг по технической поддержке Системы зависит от типа обращения (заявки): 1. Услуга по решению инцидентов, связанных с работой ППО – тип обращения (заявки) «Инцидент». 2. Услуга по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности – тип обращения (заявки) «Инцидент». 3. Услуга информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы – тип обращения (заявки) «Запрос на обслуживание» (в том числе, консультационный запрос). 4. Услуга адаптационного, конфигурационного и коррекционного сопровождения Системы (в рамках действующих программных модулей и функциональностей) – тип обращения (заявки) «Запрос на изменение». В случае недоступности СРО взаимодействие и информирование Исполнителем о ходе оказания услуги по обращению (заявке), изменению статусов обращений (заявок) осуществляется по согласованию с Заказчиком в соответствии с матрицей взаимодействия, представленной в Приложении 1 к настоящему Регламенту. 3.4.1 Инцидент На рисунке 2 представлена функциональная схема регистрации и сопровождения обращений (заявок) типа «Инцидент». Рисунок 2 - Функциональная схема регистрации и сопровождения обращений (заявок) типа «Инцидент» 3.4.2 Запрос на обслуживание На рисунке 3 представлена функциональная схема регистрации и сопровождения обращения (заявки) типа «ЗНО». Рисунок 3 - Функциональная схема регистрации и сопровождения обращения (заявки) типа «ЗНО» 3.4.3 Запрос на изменение На рисунке 4 представлена функциональная схема регистрации и сопровождения обращений (заявок) типа «ЗНИ». Рисунок 4 - Функциональная схема регистрации и сопровождения обращений (заявок) типа «ЗНИ» 3.5 Порядок классификации и приоритизации обращений (заявок) Классификация является начальной стадией процесса оказания технической поддержки, необходимой для идентификации обращения (заявки) и определения соответствующих действий для его обработки. Для проведения первичной классификации необходимо получить от пользователя и зафиксировать в описании обращения (заявки) подробные сведения о сути запроса, в том числе, для Инцидентов зафиксировать сценарий воспроизведения обнаруженной ошибки. Для проведения вторичной классификации необходимо провести анализ и диагностику для определения корневой причины и затронутой Инцидентом функциональной области (инфраструктура, сеть, ППО). В процессе классификации осуществляется первичная диагностика и оценка проблемы, описанной пользователем Системы в обращении (заявке), в части функционирования и/или удобства использования Системы. Корректная классификация позволяет увеличить скорость обработки обращения (заявки) и решения описанной в обращении (заявке) проблемы при минимальном привлечении ресурсов, в частности, за счет использования известных решений для типовых обращений (заявок), которые должны описываться в БЗ СРО. Классификация позволяет произвести первоначальное назначение обращения (заявки) на ответственного сотрудника и выставить приоритет с учетом приоритизации. Приоритизация применяется для определения критичности описанной в обращении (заявке) проблемы для функционирования ППО Системы. Приоритет рассмотрения обращения (заявки) определяется в процессе ее классификации на основании ряда параметров, вводимых при заполнении обращения (заявки). Приоритизация используется для того, чтобы при одновременном наличии нескольких обращений (заявок) в первую очередь рассматривалась обращения (заявки) с наивысшим приоритетом и не позднее установленных для данного приоритета сроков Термины и сокращения В настоящем регламенте используются следующие термины и сокращения на русском и английском языках: Термины/сокращения Полное наименование/описание БЗ (База знаний) База данных Системы регистрации обращений (заявок), созданная для сбора, хранения и поиска способов решения известных проблем в рамках Системы Жизненный цикл обращения (заявки) Совокупность статусов, по которым проходит обращение (заявка), и правила перехода обращения (заявки) из одного статуса в другой Заказчик ФГБУ «СИЦ Минтранса России» – Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» ЗНИ Запрос на изменение – тип заявки, предполагающий внесение изменений в прикладное программное обеспечение Системы ЗНО Запрос на обслуживание – тип заявки, предполагающий работы по предоставлению консультации, предоставление доступа к Системе или стандартизированные типовые изменения конфигураций Системы Инцидент Тип заявки, классифицируемый как нештатное событие в работе компонентов функциональных задач Системы, которое привело или может привести к нарушению или снижению качества функционирования Системы ИС Информационная система Исполнитель Организация, которая определяется по результатам конкурсных процедур Классификация Анализ и заполнение классификационных полей справочными значениями, определяющими последовательность действий и этапов жизненного цикла заявки, а также порядок рассмотрения заявок Консультация Разъяснения по алгоритму работы, требуемых настроек прикладного программного обеспечения и технологии обработки данных при работе с Системой, предоставление информации Маршрутизация Определение процесса движения обращения (заявки) в Системе управления заявками между уровнями технической поддержки и организационными структурами на уровнях поддержки путем назначения обращения (заявки) в соответствии с его классификацией и выставленным приоритетом Обращение (заявка) Устное или письменное обращение пользователя АСУ ТК с вопросом, касающимся работоспособности АСУ ТК, по одному из определённых каналов связи: электронная почта, Система регистрации обращений (заявок) Пользователь Инициатор обращения (заявки) или пользователь Системы ППО Прикладное программное обеспечение Предмет обращения Справочник, классифицирующий типовые запросы в Системе регистрации обращений (заявок), характерные для Системы, выбранное значение определяет маршрутизацию обращения (заявки) (группу ответственных сотрудников) Приоритизация Значение, определяющее время, очередность решения обращений (заявок), ресурсы, привлекаемые для решения обращений (заявок), . Приоритет устанавливается в соответствии с масштабом выявленной проблемы, которая привела или может привести к нарушению или снижению качества функционирования Системы Релиз Выпуск версии прикладного программного обеспечения Системы, от разработки до тестирования и планового обновления Системы на продуктивной среде для установки изменений, связанных с развитием/улучшением/оптимизацией Системы Система, АСУ ТК, Информационно-аналитическая система регулирования на транспорте Информационно-аналитическая система, предназначенная для автоматизации и информационно-аналитического обеспечения процессов управления развитием транспортного комплекса Российской Федерации, обеспечения публичности деятельности органов государственного управления транспортным комплексом, а также обеспечения процессов оказания государственных услуг в электронном виде в сфере транспорта СМЭВ Система межведомственного электронного взаимодействия СПО Системное программное обеспечение СРО Система регистрации обращений (заявок) Статус обращения (заявки) Текущее состояние обращения (заявки) в жизненном цикле процесса оказания технической поддержки Системы СУБД Система управления базами данных Изменение приоритета уже зарегистрированного обращения (заявки) используется в случае появления новых обстоятельств, которые ведут к изменению влияния и/или срочности существующего обращения (заявки). При регистрации обращения (заявки) необходимо провести его приоритизацию. В процессе управления обращениями (заявками) каждому обращению (заявке) присваивается приоритет, принимающий одно из значений: Низкий, Средний, Высокий или Критический. В соответствии с приоритетом определяется время, очередность устранения, , ресурсы, привлекаемые для работ по обращению (заявке), а также может определяться порядок/процедура действий при работе с обращением (заявкой). Заказчиком в зависимости от уровня сбоя в работе Системы обращению (заявке) присваивается приоритет с указанием максимального времени реакции и решения в соответствии с требованиями, указанными в Приложении 2 к настоящему Регламенту 4 Формы обращений (заявок) на оказание услуг по технической поддержке Системы, заполняемые в СРО 4.1. Форма обращения (заявки) на оказание услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы При подаче обращения (заявки) типа «ЗНО» в СРО указывается (Таблица 5): Таблица 5 – Описание атрибутов формы обращения (заявки) на оказание услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 5) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 5) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 5) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 5) Категория обращения: информационно-консультационная поддержка Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 5) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 5) Текст запроса на оказание услуги по информационно-консультационной поддержке сотрудников Заказчика Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 5) На рисунке 5 приведена форма обращения (заявки) типа «ЗНО» в СРО. Рисунок 5 - Форма обращения (заявки) типа «ЗНО» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы, заполненную в свободной форме. - Наименование характеристики - Значение характеристики - Единица измерения характеристики - Инструкция по заполнению характеристик в заявке - ОПРЕДЕЛЕНИЯ, ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ - Автоматизированная система (АС) Система, состоящая из комплекса средств автоматизации, реализующего информационную технологию выполнения установленных функций, и персонала, обеспечивающего его функционирование (ГОСТ Р 59853-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения») АРМ Автоматизированное рабочее место АСУ ТК, Система Информационно-аналитическая система регулирования на транспорте АТС Автоматическая телефонная станция БД База данных ГИС Государственная информационная система ГОСТ Государственный стандарт ГЦОД СИЦ Минтранса России, ГЦОД Головной центр обработки данных ФГБУ «СИЦ Минтранса России» Дашборд Интерактивная аналитическая панель, графический интерфейс. ЕИС Единая информационная система в сфере закупок ЕСИА Единая система идентификации и аутентификации Заказчик Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» КИИ Критическая информационная инфраструктура Кластер Кла?стер (англ. cluster) – объединение нескольких однородных элементов, которое может рассматриваться как самостоятельная единица, обладающая определёнными свойствами Компонент Часть АС, выделенная по определенному признаку или совокупности признаков и рассматриваемая как единое целое (ГОСТ Р 59853-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения») Контракт Контракт на выполнение работ по развитию и оказанию услуг по технической поддержке Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК в 2026 году, заключаемый по результатам проведения конкурентной процедуры закупки в соответствии с требованиями Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» - - Значение характеристики не может изменяться участником закупки - Модуль iМинтранс Модуль сбора данных и представления показателей деятельности Министерства транспорта Российской Федерации iМинтранс АСУ ТК Модуль СЦ Модуль сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК НС Нештатная ситуация НСИ Нормативно-справочная информация ОТИ Объект транспортной инфраструктуры П-ГИС Геоинформационная подсистема П-ИВ Подсистема информационного взаимодействия П-НСИ Подсистема ведения нормативно-справочной информации и метаданных ПО Программное обеспечение Подрядчик, Исполнитель Организация, с которой будет заключен контракт на выполнение работ по развитию Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК П-СД Подсистема сбора данных Работы Работы по развитию Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК СЗИ Средство защиты информации СМЭВ Система межведомственного электронного взаимодействия СУБД Система управления базами данных ТЗ Техническое задание (настоящий документ) ТС Транспортное средство ТК Транспортный комплекс Учреждение Учреждения в области информационной безопасности - ФГБУ «СИЦ Минтранса России» Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации», Заказчик Федеральный закон № 44-ФЗ Федеральный закон от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» ФЗ Функциональная задача ФЗ «Реестр объектов» Функциональная задача «Формирование и ведение единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации» ФСБ России Федеральная служба безопасности Российской Федерации ФСТЭК России Федеральная служба по техническому и экспортному контролю ЧС Чрезвычайная ситуация ЭВМ Электронно-вычислительная машина API От англ. Application Programming Interface – интерфейс прикладного программирования – совокупность инструментов и функций в виде интерфейса для взаимодействия с программой CSS От англ. Cascading Style Sheets — каскадные таблицы стилей FPS От англ. frame per second - количество кадров в секунду HTML От англ. HyperText Markup Language - стандартный язык разметки документов, создающий основу и структуру всех веб-страниц JSON От англ. JavaScript Object Notation – текстовый формат обмена данными, основанный на JavaScript WebAssembly (Wasm) Открытый стандарт, представляющий собой низкоуровневый бинарный формат инструкций, который позволяет выполнять код, написанный на языках C++, Rust или Go, в браузерах с производительностью, близкой к нативной - 1. ОБЩИЕ СВЕДЕНИЯ - 1.6. Перечень документов, требования которых должны быть учтены при выполнении работ – Федеральный закон Российской Федерации от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации»; – Федеральный закон Российской Федерации от 27.07.2006 № 152-ФЗ «О персональных данных»; – Федеральный закон Российской Федерации от 06.04.2011 № 63-ФЗ «Об электронной подписи»; – Федеральный закон Российской Федерации от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации»; – Указ Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации»; – Указ Президента Российской Федерации от 01.05.2022 № 250 «О дополнительных мерах по обеспечению информационной безопасности Российской Федерации»; – Указ Президента Российской Федерации от 31.03.2010 № 403 «О создании комплексной системы обеспечения безопасности населения на транспорте»; – постановление Правительства Российской Федерации от 30.07.2004 № 395 «Об утверждении Положения о Министерстве транспорта Российской Федерации»; – постановление Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации»; – постановление Правительства Российской Федерации от 16.11.2015 № 1236 «Об установлении запрета на допуск программного обеспечения, происходящего из иностранных государств, для целей осуществления закупок для обеспечения государственных и муниципальных нужд»; – постановление Правительства Российской Федерации от 23.12.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 Федерального закона «Об электронной подписи»; - – постановление Правительства Российской Федерации от 08.06.2011 № 451 «Об инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг и исполнения государственных и муниципальных функций в электронной форме»; – постановление Правительства Российской Федерации от 30.01.2013 № 62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин»; – приказ ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации»; – приказ ФСТЭК России от 11.04.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений»; – приказ ФСБ России от 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.7. Сроки начала и окончания работ Начало работ: с даты заключения Контракта. Окончание работ: не позднее 15.12.2026. Работы выполняются в соответствии с этапами. Сроки выполнения этапов работ по развитию и технической поддержке Модуля СЦ определяются Календарным планом. Календарный план, приведен в разделе 5 настоящего ТЗ - 1.8. Общие сведения об источниках и порядке финансирования работ Источником финансирования являются средства субсидии федерального бюджета Российской Федерации, предоставленной в соответствии с абзацем вторым пункта 1 статьи 78.1 Бюджетного кодекса Российской Федерации (код цели 08-01) - 1.9. Порядок оформления и предъявления результатов работ Подрядчик должен передать Заказчику результаты работ в порядке, определенном Контрактом в сроки, установленные п. 5 настоящего ТЗ, в соответствии с Календарным планом - 1.10. Место выполнения Работ Работы выполняются удаленно на комплексе технических средств Заказчика. Адрес размещения комплекса технических средств Заказчика: Московская обл., Богородский район, пос. Горбуша, Радиоцентр. Техническая возможность удаленного подключения обеспечивается Заказчиком (в части предоставления параметров доступа). Оплата телематических и иных услуг, технических и программных средств, необходимых Подрядчику для удаленного подключения и для выполнения требований по информационной безопасности, осуществляется Подрядчиком самостоятельно за свой счет - 1.1. Наименование Системы Полное наименование системы: Информационно-аналитическая система регулирования на транспорте. Условное обозначение системы: АСУ ТК. Полное наименование модуля: Модуль сбора, ведения и анализа информации о нештатных ситуациях на транспорте. Условное обозначение модуля: Модуль СЦ. Модуль СЦ создан в рамках контракта от 05.08.2024 № ОК/24_04 на выполнение работ по развитию АСУ ТК в части создания модуля «Сбора, ведения и анализа информации о нештатных ситуациях на транспорте». Развитие Модуля СЦ осуществлено в рамках контракта от 19.05.2025 № ОК/25_09 на выполнение работ по развитию Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК - 1.2. Шифр темы или номер контракта Присваивается Заказчиком по результатам организации закупочных процедур. 1.2.1. Предмет контракта Выполнение работ по развитию Модуля СЦ. Код по ОКПД2: 62.01.11.000 – услуги по проектированию и разработке информационных технологий для прикладных задач и тестированию программного обеспечения. Оказание услуг по технической поддержке Модуля СЦ. Код по ОКПД2: 62.02.30.000 – услуги по технической поддержке информационных технологий. Выполнение работ по развитию Модуля СЦ предусмотрено с учетом ключевых результатов (ОКР) Ведомственной программы цифровой трансформации Минтранса России на 2026-2028 (далее - ВПЦТ Минтранса России) в составе мероприятия № 103.002 «АСУ ТК» ИТ расхода 103.26.000005 «Развитие Информационно-аналитической системы регулирования на транспорте (АСУ ТК)»: · «Обеспечено информационное взаимодействие с Минобороны о происшествиях на транспортных объектах»; · «Обеспечена автоматизация формирования отчетов о нештатных ситуациях на транспорте, в том числе по данным внешних систем». Выполнение работ по технической поддержке АСУ ТК предусмотрено ВПЦТ Минтранса России в составе мероприятия № 103.002 «АСУ ТК» ИТ расхода 103.26.000021 «Эксплуатация Информационно-аналитической системы регулирования на транспорте (АСУ ТК)» - 1.3. Заказчик Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» (ФГБУ «СИЦ Минтранса России»). Адрес: 107078, Москва, Садовая-Спасская ул., д.18, стр. 1. Оператором Системы является Заказчик - Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» (ФГБУ «СИЦ Минтранса России) - 1.4. Подрядчик Определяется по результатам проведения конкурентной процедуры закупки в соответствии с требованиями Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (далее – Федеральный закон № 44-ФЗ) - 1.5. Основания для выполнения работ Работы осуществляются на основании следующих документов: – постановление Правительства Российской Федерации от 30.12.2003 № 794 «О единой государственной системе предупреждения и ликвидации чрезвычайных ситуаций»; – постановление Правительства Российской Федерации от 08.11.2013 № 1007 «О силах и средствах единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций»; – распоряжение Правительства Российской Федерации от 27.11.2021 № 3363-р «О Транспортной стратегии Российской Федерации до 2030 года с прогнозом на период до 2035 года»; – Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 26.08.2025 №ЕФ-3; – Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 27.11.2025 №ЕФ-23; - – Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 19.02.2026 №ЕФ-1; – План мероприятий по профилактике случаев непроизводственного травматизма граждан на железнодорожном транспорте, являющийся приложением к постановлению коллегии Министерства транспорта Российской Федерации от 11.03.2026 № 2 - 2. ЦЕЛИ И НАЗНАЧЕНИЕ ВЫПОЛНЕНИЯ РАБОТ - 2.1. Назначение АСУ ТК АСУ ТК предназначена для автоматизации и информационно-аналитического обеспечения процессов управления развитием транспортного комплекса Российской Федерации, обеспечения публичности деятельности органов государственного управления транспортным комплексом. Основными целями АСУ ТК являются: – повышение эффективности процессов управления функционированием и развитием транспортного комплекса на основе создания единой информационной среды и комплекса информационно-аналитических услуг на уровне органов государственного управления ТК; – повышение уровня безопасности ТК на базе получения полной, достоверной и оперативной информации о происходящих изменениях, своевременного выявления негативных тенденций и для принятия соответствующих мер по их устранению и ликвидации последствий - - Значение характеристики не может изменяться участником закупки - Основными задачами АСУ ТК являются: – автоматизация процессов прогнозирования развития транспортного комплекса и поддержки принятия управленческих решений; – автоматизация процессов мониторинга безопасности и устойчивости транспортного комплекса, управления в чрезвычайных и нештатных ситуациях; – автоматизация процессов управления программами и проектами развития и модернизации транспортного комплекса; – автоматизация процессов мониторинга состояния транспортного комплекса, в том числе с использованием набора ключевых показателей эффективности деятельности транспортного комплекса; – информационно-технологическая поддержка взаимодействия субъектов транспортного комплекса Российской Федерации, органов государственного управления и контроля, международных организаций на основе создания единой технологической среды взаимодействия и управления движением данных (и связанных с ними документов) в транспортном комплексе; – использование в процессах управления транспортным комплексом РФ современных технологий электронного документооборота и электронного обмена данными; – организация межведомственного электронного взаимодействия подразделений Министерства транспорта Российской Федерации, подведомственных агентств и службы с другими организациями - 2.2. Назначение и цели развития и технической поддержки Модуля СЦ Назначение Модуля СЦ: – оперативный мониторинг нештатных и чрезвычайных ситуаций на транспорте ; – оповещение заинтересованных лиц и структур о нештатных и чрезвычайных ситуациях; – сбор, обработка и хранение данных о нештатных и чрезвычайных ситуациях. Целями развития Модуля СЦ являются: – расширение состава данных об оперативной обстановке на транспорте; – оптимизация процесса сбора данных об оперативной обстановке на транспорте; – повышение информированности пользователей за счет визуализация данных Модуля СЦ; – автоматизация процесса формирования отчетов о ЧС и нештатной ситуации на транспорте; – обеспечение информационного взаимодействия с заинтересованными организациями по вопросам ведения. - Целями оказания услуг по технической поддержке являются: – обеспечение информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы; – поддержание параметров функционирования ППО Системы, удовлетворяющих требованиям производственных процессов, включая их непрерывность; – обеспечение бесперебойного функционирования ППО и своевременное устранение сбоев и аварийных ситуаций в Системе; – своевременное устранение уязвимостей при выявлении таковых, в соответствии с требованиями к обеспечению информационной безопасности; – адаптация, конфигурирование, коррекция программного обеспечения в соответствии с изменениями нормативно-правовой базы и запросами уполномоченных сотрудников органов государственной власти, включая выполнение процедур тестирования и участие в обновлениях ППО на стендах Заказчика; – обеспечение сохранения работоспособности ППО в изменяемой среде эксплуатации; – ведение документации по настоящему ТЗ, инициирование и актуализация документации на Систему по результатам обработки запросов Заказчика и внесении соответствующих изменений в ППО. Модуль СЦ применяется в деятельности Министерства транспорта Российской Федерации, подведомственных агентств и службы и другими организациями в соответствии с соглашениями об информационном обмене - 3. ХАРАКТЕРИСТИКА ОБЪЕКТА АВТОМАТИЗАЦИИ - 3 Информирование – ведение справочника способов оповещения (веб-интерфейс, мессенджер); – формирование сценария выполнения оповещения (настройка условий, способа, параметров оповещения); – выполнение оповещений пользователей 4 Отчетность – формирование отчета и справки о событиях; – фильтрация событий для выгрузки в справку о событиях или в отчет о событиях 5 Администрирование – ведение ролей пользователей; – ведение учетных данных пользователей; – ведение справочника организаций; – ведение справочника групп системы мгновенного обмена сообщениями; – выполнение исходящего звонка на контактный телефонный номер организации; – формирование матрицы эскалации событий Архитектура Модуля СЦ представлена на рисунке 1. Рисунок 1. Архитектура Модуля СЦ - - Значение характеристики не может изменяться участником закупки - 3.3. Состав используемого ПО Модуля СЦ Программная архитектура Модуля СЦ разработана как трехуровневая клиент-серверная архитектура. Архитектура включает в себя следующие уровни: • уровень представления – презентационный уровень, обеспечивающий взаимодействие с пользователя с клиентскими приложениями с использованием веб-браузера («тонкий» клиент); • уровень приложений – реализован в виде сервисов, обеспечивает обработку запросов, поступающих от клиентских приложений, формирование ответов на запрос в доступном пользователю виде (формирование пользовательских интерфейсов); • уровень хранения данных – реализуется как сервер БД и обеспечивает хранение и целостность хранимых данных, создание резервных копий, ведение журнала транзакций, восстановление данных после сбоев. Программная архитектура Модуля СЦ включает в себя сервисы и интерфейсы, указанные в Таблице 3. Таблица 3. Программная архитектура Модуля СЦ Программный сервис/интерфейс Технологии реализации Уровень представления Интерфейс пользователя и администратора (front-end) Javascript Уровень приложений Сервис (GateWay) Kotlin Сервис геокодирования (geocoding-service) Kotlin Сервис уведомлений (notifiсation-service) Kotlin Сервис работы с файлами (file-service) Kotlin Сервис отчетности (report-service) Kotlin Сервис управления событиями (event-service) Kotlin Сервис информирования через мессенджер (messenger-notifier) Python Сервис внешних интеграций (integration-service) Сбор информации из внешних систем и сервисов Брокер сообщений Kafka Уровень хранения данных Файловое хранилище MinIO S3 СУБД Postgres Pro Enterprise - 3.4. Информационное взаимодействие программных сервисов и интерфейсов Модуля СЦ Объект автоматизации функционирует в распределенной информационной среде. Обмен данными осуществляется по защищенным каналам связи (в том числе ведомственным сетям передачи данных). Источники информации включают: · внешние автоматизированные системы (органов государственной власти); · внутренние базы данных (реестры объектов транспортной инфраструктуры, паспорта регионов и пр.); · оперативная информация от персонала, поступающая через автоматизированные рабочие места (АРМ) и мобильные устройства. 3.4.1. Взаимодействие Модуля СЦ со смежными подсистемами АСУ ТК Модуль СЦ входит в состав АСУ ТК и взаимодействует со следующими ее функциональными задачами и подсистемами: · Функциональной задачей «Формирование и ведение единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации» (ФЗ «Реестр объектов»); · Геоинформационной подсистемой АСУ ТК (П-ГИС); · Подсистемой ведения нормативно-справочной информации и метаданных (П-НСИ); · Подсистемой сбора данных и централизованное хранилище данных (П-СД); · Подсистемой информационного взаимодействия (П-ИВ). 3.4.2. Взаимодействие с внешними информационными системами Список внешних информационных систем, с которыми осуществляется взаимодействие Модуля СЦ: · ЕСИА; · мессенджер; · Яндекс Геокодер; · Информационная система «Централизованная система сбора информации систем-112»; · ПВК «Поиск-Море», АИС РПТ; · облачная АТС - 3.1. Описание объекта автоматизации АСУ ТК Объектом автоматизации являются процессы основной и обеспечивающей деятельности, направленные на управление транспортным комплексом, в том числе, процессы информационного взаимодействия с другими организациями и субъектами транспортного комплекса. АСУ ТК относится к государственным информационным системам, а также к информационным системам персональных данных и значимым объектам критической информационной инфраструктуры Российской Федерации. АСУ ТК соответствует требованиям, предъявляемым к: – ГИС второго класса защищенности в соответствии с приказом ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах»; – ИС персональных данных при обеспечении третьего уровня защищенности персональных данных в соответствии с требованиями постановления Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»; – значимым объектам КИИ Российской Федерации второй категории значимости с постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении Правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений». Модуль СЦ является подсистемой АСУ ТК. Перечень платформенных решений и функциональных задач АСУ ТК представлен в Таблице 1 - Таблица 1 – Перечень платформенных решений и функциональных задач АСУ ТК № Наименование подсистемы/ функциональной задачи/ модуля Назначение 1 Подсистема сбора данных и централизованного хранилища данных Подсистема обеспечивает выполнение сбора данных в АСУ ТК, и в т. ч., в рамках функциональных задач «Формирование и ведение межрегионального транспортного баланса пассажирских перевозок в дальнем (межрегиональном) сообщении» и «Формирование и ведение транспортного паспорта региона» 2 Подсистема информационного взаимодействия Подсистема информационного предназначена для обеспечения информационного взаимодействия подсистем АСУ ТК, а также, взаимодействия АСУ ТК с АС федеральных органов исполнительной власти 3 Подсистема ведения нормативно-справочной информации и метаданных Подсистема предназначена для автоматизации функций формирования и актуализации справочников, классификаторов, реестров и регистров, необходимых для обеспечения информационной поддержки пользователей НСИ и интеграции подсистем АСУ ТК в части применения НСИ 4 Модуль СМЭВ Модуль взаимодействия со СМЭВ представляет собой набор сервисов взаимодействия: сервис синхронного взаимодействия и сервис отправки, осуществляющих дополнительную обработку сообщений, отправляемых в СМЭВ и принимаемых из СМЭВ 5 Геоинформационная подсистема Программное обеспечение геоинформационной подсистемы предназначено для обеспечения смежных подсистем АСУ ТК возможностью работы с картографической информацией, в том числе, отображения на электронных картах объектов транспортной инфраструктуры и получения информации о местоположении, характеристиках контролируемых транспортных объектов 6 Подсистема информационного портала АСУ ТК Подсистема информационного портала предназначена для отображения и входа в функциональные задачи АСУ ТК 7 Подсистема технического портала АСУ ТК Подсистема технического портала АСУ ТК предназначена для управления заявками пользователей и технологического документооборота заявок - 8 Подсистема проектного архива АСУ ТК Подсистема проектного архива АСУ ТК предназначена для автоматизации деловых процессов должностных лиц Министерства транспорта Российской Федерации, подведомственных агентств и службы, в том числе, и процессов информационного взаимодействия внутреннего и внешнего характера 9 ФЗ «Реестр объектов» Функциональная задача предназначена для формирования и ведения единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации 10 ФЗ «СТП» Функциональная задача предназначена для организации информационно-аналитической поддержки процессов территориального планирования Российской Федерации в области федерального транспорта 11 ФЗ «МРТБ ПП» Функциональная задача предназначена для формирования и ведения межрегионального транспортного баланса пассажирских перевозок в дальнем (межрегиональном) сообщении 12 ФЗ «МДД» Функциональная задача предназначена для осуществления мониторинга дорожного движения 13 ФЗ «ТПР» Функциональная задача предназначена для формирования и ведения транспортного паспорта региона 14 ФЗ «Данные по грузообороту» Функциональная задача предназначена для обеспечения подсистем и пользователей АСУ ТК данными по грузообороту между Российской Федерацией и зарубежными странами 15 ФЗ «МЖТ» Функциональная задача предназначена для осуществления мониторинга железнодорожного транспорта 16 ФЗ «МГМП» Функциональная задача предназначена для осуществления мониторинга грузопотоков в морских портах с целью формирования единой цифровой среды мониторинга и планирования перевозок в/из портов Дальнего Востока - 17 Модуль ГЭТ Модуль предназначен для получения, хранения данных инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по отдельно взятому предприятию-перевозчику. Формирования отчетов об инвентаризации с детальными данными по каждому разделу инвентаризации с маршрутизацией в муниципалитет / регион / Минтранс. Содержит агрегированные данные инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по всем перевозчикам, относящихся к данному муниципалитету. Формирует сводный отчет по муниципалитету по каждому разделу инвентаризации с маршрутизацией в регион / Минтранс. Формирует агрегированные данные инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по всем перевозчикам, относящиеся к данному региону и по всем муниципалитетам, относящимся к данному региону. Аналитические и статистические данные о состоянии ГЭТ региона. Содержит данные о видах транспорта, цифровых транспортных сервисах и платежных инструментах Региона. Формирует сводный отчет по каждому разделу инвентаризации с маршрутизацией в Минтранс. Формирует агрегированную статистику и аналитику по всем регионам страны в разрезе транспортных средств, маршрутов, пассажиропотоков, инфраструктуры ГЭТ. Данные о рейтинге регионов и перевозчиков на основании выбранных параметров, документооборот с участниками Системы: получение подписанных печатных форм, их утверждение, возврат на доработку. 18 Модуль iМинтранс Модуль создан для отчета по ключевым показателям транспортного комплекса России (Отраслевые и статистические показатели, исполнение бюджета, исполнение поручений, аналитика СМИ, происшествия по видам транспорта). 19 Модуль СЦ Модуль СЦ предназначен для оперативного мониторинга нештатных ситуаций транспортной отрасли, оповещения заинтересованных лиц и структур и предоставления данных о нештатных ситуациях - 3.5. Требования к эксплуатации Применяемое в Системе программное обеспечение, программно-аппаратные и аппаратные комплексы должны соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации» - АСУ ТК осуществляет идентификацию и авторизацию посредством Единой системы идентификации и аутентификации (ЕСИА). Информационный обмен с внешними информационными системами осуществляется посредством СМЭВ 3 и СМЭВ 4. АСУ ТК развернута на вычислительных мощностях ГЦОД СИЦ Минтранса России - 3.2. Описание и текущее состояние объекта автоматизации Модуля СЦ Объектом автоматизации является процесс организации мониторинга информации о НС и ЧС на транспорте. Предметом деятельности Учреждения являются следующие функции: – информационное обеспечение в области транспортной безопасности, защиты населения и территорий от чрезвычайных ситуаций природного и техногенного характера в транспортном комплексе; – подготовка справочных материалов при угрозе возникновения и возникновении чрезвычайных ситуаций и иных происшествий в транспортном комплексе; – взаимодействие и обмен оперативной информацией с органами управления Единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций; – организация оперативного мониторинга обстановки на объектах транспорта при угрозе и возникновении чрезвычайных ситуаций и иных происшествий. Перечень компонентов Модуля СЦ и выполняемые ими функции представлены в Таблице 2 - Таблица 2. Перечень компонентов Модуля СЦ и их функции № п/п Компонент Выполняемые функции 1 Регистрация событий – ведение карточки события; – удаление комментария; – динамическое отображение существующих событий в заданном радиусе и за заданный период; – возможность автоматической проверки вводимых данных в части количества пострадавших; – отображение карточки ОТИ, ТС в соответствии с ФЗ Реестр объектов; – сохранение и отображение версии карточки события; – привязка события к координатам по картографической основе; – указание признака выполнения действия по отработке события; – перевод статуса события; – закрытие карточки события; – публикация информации о событии в канале мессенджера; – возможность перехода из карточки события на картографическую основу для просмотра местоположения события 2 Визуализация – отображение событий на картографической основе в виде пиктограмм; – масштабирование карты; – отображение краткой карточки события при выборе события на картографической основе; – отображение списка событий; – отображение карточки события; – отображение журнала действий пользователя; – отображение дополнительной информации (текстовая информация и приложенные файлы); – отображение справки о событиях и отчета о событиях; – отображение фильтров и количества отфильтрованных объектов; – отображение результатов поиска; – отображение статистики по событиям на экране; – возможность создания события с картографической основы; – отображения картографических слоев в зависимости от примененных фильтров; – возможность настройки шага картографической сети; – возможность настройки географической точки центра карты; – отображение количества непрочитанных сообщений; – возможность перехода к детальной карточке события из краткой карточки события при выборе события на картографической основе - 4. ТРЕБОВАНИЯ К МОДУЛЮ СЦ - 4.1. Требования к структуре Модуля СЦ В процессе работ по развитию Системы должны сохраниться основные требования к построению архитектуры Системы в соответствии с принципами трехуровневой архитектуры: 1. уровень хранения данных или уровень базы данных (сервер СУБД); 2. уровень сервера приложений (сервер аналитической обработки); 3. презентационный уровень, обеспечивающий взаимодействие с клиентскими приложениями. В состав Системы должны входить следующие основные компоненты: 4. сервер баз данных; 5. сервер приложений; 6. веб-сервер. Сервер баз данных должен обеспечивать хранение и целостность хранимых данных, создание резервных копий, ведение журнала транзакций, восстановление данных после сбоев. Сервер приложений должен обеспечивать обработку запросов, поступающих от клиентских приложений (через веб-сервер), формирование ответов на запрос в доступном пользователю виде (формирование пользовательских интерфейсов). Веб-сервер должен обеспечивать взаимодействие с оператором и внешними системами по HTTP / HTTPS протоколу в режиме «запрос-ответ» (получения запросов от пользователя и передачи ответа в виде соответствующей информации, обработанной серверами приложений). Взаимодействие Системы с пользователем должно отвечать требованиям модели «тонкого клиента» (т.е. представлять на стороне клиента (пользователя) лишь графический пользовательский интерфейс). Все составляющие Системы должны использовать единую методологию и отвечать единым принципам взаимодействия, надежности и управления. Перечень компонентов Модуля СЦ представлен в Таблице 4. Таблица 4. Перечень компонентов Модуля СЦ, в отношении которых выполняются работы по развитию № п.п. Наименование компонента Модуля СЦ Раздел ТЗ 1 Компонент регистрации событий 4.2.1. 2 Компонент отчетности 4.2.2 3 Компонент визуализации 4.2.3 4 «Интерактивная карта» (компонент создается) 4.2.4 5 Компонент администрирования 4.2.5 - - Значение характеристики не может изменяться участником закупки - 4.2. Требования к дорабатываемым функциям модуля СЦ 4.2.1. Развитие компонента регистрации событий (1 очередь) Должны быть выполнены следующие доработки: – обеспечение логирования действий пользователя, связанных с карточкой события; – доработка объектной модели в части создания новых типов сущностей (карточек) с учетом реализуемых интеграций с информационными ресурсами (силы и средства предупреждения и ликвидации ЧС и нештатных ситуаций на транспорте, ТС, ограничения воздушного пространства, неблагоприятные и опасные природные явления); – реализация механизма установления связи между сущностями в Модуле СЦ автоматизированным и ручным способами (события, природные явления, силы и средства предупреждения и ликвидации ЧС и нештатных ситуаций на транспорте, ограничения воздушного пространства, ОТИ, ТС и др.); – отображение в карточке установленных связей между сущностями. - Оказание услуг в рамках данного технического задания осуществляется Подрядчиком по обращению (заявке) Заказчика, направляемой посредством СРО Заказчика. Регистрация обращений, поступивших непосредственно в Модуль СЦ регистрации обращений Заказчика, производится сотрудниками Заказчика, которые обеспечивают первый уровень технической поддержки Модуля СЦ. В случае назначения приоритета «Критический» или «Высокий», информация о назначении также дублируется оповещением ответственных представителей Подрядчика посредством звонка на предоставленные номера телефонов. Обращение (заявка) должна содержать следующую информацию: – контакты пользователя/организации; – приоритет обращения, соответствующий Приложению 2 к Регламенту; – время обнаружения; – наименование компонента АСУ ТК - Модуль СЦ; Информация может быть расширена по согласованию с Заказчиком. Обращения (заявки) сотрудников Заказчика должны приниматься Подрядчиком через веб-интерфейс СРО. В процессе обработки обращений (заявок) Подрядчик должен обеспечить выполнение следующих процедур: – прием обращений(заявок) от сотрудников Заказчика; – оказание информационно-консультационной поддержки в соответствии с требованиями настоящего Технического задания; – информирование сотрудников Заказчика о статусе обработки и результатах обработки обращений(заявок). Подрядчик осуществляет обязательную регистрацию и учет всех обращений и заявок, поступивших к Подрядчику от представителей Заказчика в рамках оказания настоящих услуг - Примечание: в случае приостановки работы по обращению или заявке (обращение или заявка находится в статусе «Приостановлено»), указываются причины, по которым работы по обращению или заявке приостановлены с указанием перечня действий/информации, запрошенных у инициатора обращения, а также даты, формы и адресата такого запроса. В случае отклонения обращения или заявки (заполняется в случае, если обращению или заявке присваивается статус «Отклонено»), указываются подробно причины такого отклонения, а также фиксируется дата и время перехода в статус «Отклонено». В случае, если обращение или заявка отклонены (отменены) самим Инициатором, то указывается дата и способ, которым от инициатора получено соответствующее уведомление. В случае невыполнения Подрядчиком регламентного времени реагирования или решения обращения (заявки) Заказчик вправе отозвать обращение и направить его Подрядчику повторно. При этом каждое отозванное обращение учитывается в Отчёте об оказанных услугах, как обращение с превышением времени реагирования или решения, но оплате не подлежит. В случае, если обращение (заявка) связано с некачественным выполнением Подрядчиком другой задачи, такое обращение решается в регламентное время, установленное Техническим заданием, при этом оплате такие обращения не подлежат, о чем указывается в Отчете об оказанных услугах в графе «Примечание» - Работы по устранению неисправности приостанавливаются (по согласованию с Заказчиком) в следующих случаях: – если Подрядчиком в результате диагностики выявлено, что неисправность находится в зоне ответственности Заказчика. Подрядчик информирует Заказчика о выявленной неисправности в зоне его ответственности по согласованным каналам связи; – требуется действие со стороны Заказчика – до момента выполнения данного действия Заказчика. Заказчик информируется о необходимых действиях по согласованным каналам связи; – отсутствие возможности связаться со специалистами Заказчика, участие которых необходимо для устранения неисправности; – требуется доставить оборудование на объект – до момента доставки и установки оборудования. В случаях, представленных выше, время приостановки работ не входит в учет продолжительности устранения неисправности. Учет времени устранения неисправности Подрядчиком считается с момента назначения Инцидента специалисту Подрядчика, ответственному за оказание услуг технической поддержки 3 уровня. Подтверждение необходимости приостановления работ находится в зоне ответственности Подрядчика. Приостановление сроков выполнения задач в соответствии с настоящим пунктом подтверждается Заказчиком по мотивированному обращению Подрядчика в СРО, основанному на данных диагностики или на иных фактических обстоятельствах - В случае непринятия Подрядчиком необходимых мер по информированию Заказчика (отсутствие надлежащего обращения от Подрядчика или отсутствие уведомления о необходимости осуществления каких-либо действий Заказчиком) не может являться основанием для приостановления работ по устранению неисправности. В отдельных случаях Подрядчику может потребоваться выполнение технологических работ для устранения причин неисправности или недопущения повторения их в будущем. Для обеспечения устранения неисправности Модуля СЦ Заказчиком проводится классификация в соответствии с приоритетами по степени срочности их устранения. Продолжительность устранения неисправности, а также периодичность информирования Подрядчиком Заказчика о ходе устранения неисправности, определены в Регламенте оказания услуг. При подаче обращения (заявки) наивысшего приоритета через СРО Заказчик должен дополнительно проинформировать службу поддержки Подрядчика о созданном обращении (заявки) по телефону уполномоченного сотрудника Подрядчика. При этом временем подачи обращения (заявки) считается время подачи обращения (заявки) через СРО - 4.2.2. Развитие компонента отчетности (3 очередь) Должна быть обеспечена автоматизация процессов формирования отчетов о ЧС и нештатных ситуациях на транспорте, в т.ч. на основе данных из внешних систем. Включает следующие доработки: – разработка шаблонов отчетов в различных форматах (табличный, текстовый); – реализация выбора фотоматериалов для включения в справку; – форматирование содержимого справок с учетом правил русского языка в отношении окончаний слов (в зависимости от падежа, склонения, числа и рода); – автоматизированное формирование выводов к содержимому справки на основе настраиваемых критериев; – создание интерфейса выбора параметров (фильтрации) для формирования отчетов: o состав полей для включения в отчёт; o настройка диапазонов значений характеристик и дат; o порядок отображения полей; o настройка заголовка. – реализация способа подготовки отчётов в асинхронном режиме (очереди); – реализация интерфейса компонента формирования отчетности для отображения очереди формирования отчетов и статусов их подготовки; – экспорт отчётов в форматы xlsx, csv и справок в форматы pdf, docx. Необходимо разработать не менее 10 шаблонов отчетов и/или справок. Перечень, структура и содержание шаблонов должны быть согласованы с Заказчиком на этапе технического проектирования. - 4.2.3. Развитие компонента визуализации (2 очередь) В рамках развития компонента визуализации должны быть выполнены следующие доработки, обеспечивающие: – вывод перечней (списков) сил и средств предупреждения и ликвидации ЧС и нештатных ситуаций на транспорте с отображением мест их постоянного размещения (дислокации) на карте, включая: o отображение зон ответственности на карте; o возможность их фильтрации (по видам транспорта, регионам и пр.); o реализацию инструмента расчета расстояния (с использованием сети автомобильных и железных дорог) между местом события и местами дислокации сил и средств, а также вывода маршрутов на карте; – отображение зон (полигонов) с установленными ограничениями движения в воздушном пространстве на карте; – отображение термических точек; – реализация возможности отображения данных из паспорта региона, отображаемого в модуле iМинтранс (модуль АСУ ТК); – отображение краткой карточки сущностей и ОТИ (краткой информации и/или динамических характеристик объекта) при выборе объекта на карте с возможностью перехода в полную карточку сущности и ОТИ; – отображение данных от Росгидромета, предусматривающих: o отображение неблагоприятных и опасных природных явлений на карте (с заданным периодом обновления данных); o управление отображением явлений на карте, включая настройку состава отображаемых объектов, поиск, фильтрацию, с использованием соответствующей панели управления; o выведение краткой карточки явления при выборе объекта, с возможностью перехода в полную карточку объекта - – отображение на карте связанных сущностей и ОТИ; – реализация функции выбора темного и светлого стилей отображения элементов интерфейса, карточек сущностей, картографической основы и объектов, отображаемых на карте; – реализация механизма для выбора картографической основы в одном из распространенных форматов WMTS, TMS, MVT и др. Должна быть предусмотрена возможность настройки перечня картографических основ и параметров доступа к ним; – настройка базового набора дашбордов, содержащих преднастроенные виджеты о количестве событий в разрезе видов транспорта с возможностью перехода к исходным данным (карточкам событий, ОТИ и т.д.), с фильтрацией по параметрам. Параметры фильтрации должны быть определены на этапе технического проектирования. Должно быть обеспечено автоматическое и принудительное обновление данных, отображаемых на дашбордах - 4.2.4.1. Требования к технической реализации компонента «Интерактивная карта» При реализации компонента «Интерактивная карта» должны учитываться требования, указанные ниже. 4.2.4.1.1. Требования к отображению элементов Повторяющихся элементы карты (ТС, ОТИ, события и пр.) должны отрисовываться с использованием аппаратного создания экземпляров объектов на пользовательском устройстве (WebGL/WebGPU)). Отрисовка каждого объекта отдельным запросом не допускается, должна обеспечиваться возможность одновременного отображения не менее 5 000 объектов без снижения производительности (30 кадров в секунду на тестовой конфигурации). 4.2.4.1.2. Уровни детализации объектов Для управления отображением сложных объектов должно быть создано не менее 3-х уровней детализации, отображаемых при изменении масштаба с возможностью автоматического переключения между уровнями. Все отображаемые объекты должны масштабироваться с учетом разрешения экрана пользователя с сохранением качества детализации. 4.2.4.1.3. Полигональная оптимизация и текстурирование При реализации компонента «Интерактивная карта» должна обеспечиваться технология рельефного тестурирования объектов. Не должны использоваться высокополигональные трехмерные модели. Все повторяющиеся элементы должны генерироваться единоразово и повторно использоваться при последующих отображениях. 4.2.4.1.4. Управление памятью Требуется реализовать потоковую загрузку на устройство пользователя элементов карты и текстур. Загрузка данных целиком при старте приложения не допускается. Необходимо реализовать механизм очистки памяти от элементов, которые находятся вне области видимости камеры в течение заданного времени. 4.2.4.1.5. Требования к взаимодействию пользователя с интерфейсом компонента «Интерактивная карта» Программная реализация механизмов управление камерой (масштабирование и навигация) должна быть выполнена с поддержкой технологии WebAssembly (WASM). Элементы управления должны являться неотъемлемой частью интерактивной карты. - 4.2.5. Развитие компонента администрирования (3 очередь) Должна быть выполнена доработка ролевой модели. Ролевая модель должна обеспечивать управление доступом к отдельным объектам Модуля СЦ и их элементам (атрибутам) с разграничением по видам транспорта, регионам и пр., в частности: – определение набора конкретных действий, доступных пользователям (выполняемых над объектом доступа, например, удаление записи, редактирование записи, формирование отчета и др.); – реализация возможности объединения пользователей в группы; – определение прав доступа для групп пользователей; – реализация интерфейса визуальной настройки прав доступа пользователей к объектам Модуля СЦ - 4.3.1.3. Требования к регламенту оказания услуг Подрядчик должен руководствоваться Регламентом оказания услуг по технической поддержке Модуля СЦ. Регламент оказания услуг содержит следующую информацию: – порядок оказания услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Модуля СЦ; – порядок оказания услуги по решению инцидентов, связанных с работой ППО; – порядок оказания услуги адаптационного, конфигурационного и коррекционного сопровождения Модуля СЦ (в рамках действующих программных модулей и функциональностей); – порядок оказания услуги по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности. – Регламент содержит следующие формы заявок на оказание услуг: – форма заявки на оказание услуги по информационно-консультационной поддержке сотрудников Заказчика; – форма заявки на оказание услуги по решению инцидентов, связанных с работой ППО; – форма заявки на оказание услуг адаптационного, конфигурационного и коррекционного сопровождения Модуля СЦ (в рамках действующих программных модулей и функциональностей) (приоритет заявки определяется Заказчиком); – форма заявки на оказание услуги по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности - 4.3.2. Требования к режиму обеспечения функционирования Модуля СЦ Режим оказания услуг определен в Приложении Б к настоящему ТЗ. По согласованию с Заказчиком, в целях недопущения остановки функционирования Модуля СЦ в период интенсивной работы пользователей в Модуле СЦ, отдельные услуги могут оказываться по специальному графику (в нерабочее время Подрядчика) в соответствии с заявками Заказчика - 4.3.3. Требования к качеству оказываемых услуг Качество оказываемых услуг поддерживается Подрядчиком в соответствии с определяемыми данным ТЗ условиями и правилами и контролируется Заказчиком на постоянной основе, в том числе по соблюдению сроков исполнения и подтверждениям исполнения от инициаторов обращений и другим параметрам. По результатам выполнения работ по устранению инцидента должна быть устранена корневая причина инцидента с окончательным решением, устраняющим причину возникновения проблемы и исключающим вероятность повторного возникновения проблемы (инцидента). Время устранения корневых причин проблемы (инцидента) не должно составлять более 40 рабочих часов - 4.4.7. Требования к программному обеспечению Общесистемное ПО, используемое в составе Модуля СЦ, должно быть зарегистрировано в Едином реестре российских программ для электронных вычислительных машин и баз данных и соответствовать рекомендованным показателям эффективности и соответствующим им значениям индикаторов эффективности перехода подведомственных организаций на использование российского ПО, заданных Приказом Минцифры России от 18.01.2023 № 21 «Об утверждении методических рекомендаций по переходу на использование российского программного обеспечения, в том числе на значимых объектах критической информационной инфраструктуры Российской Федерации, и о реализации мер, направленных на ускоренный переход органов государственной власти и организаций на использование российского программного обеспечения в Российской Федерации». Применяемое в системе программное обеспечение должно соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации, постановления Правительства Российской Федерации от 23 декабря 2024 г. № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц» - Прикладное программное обеспечение должно отвечать следующим требованиям: – совместимость программных продуктов в части используемых технических средств, системного программного обеспечения и общесистемной инфраструктуры в пределах требований к техническому обеспечению, а также их информационная совместимость в пределах требований к информационному обмену; – обеспечение трехуровневой архитектуры с разделением на уровень хранения данных (сервер БД), уровень бизнес-логики (сервер приложений) и уровень представления ( - 4.4.7.1. Требования к инструментам разработки и процессу контроля версий программного обеспечения 4.4.7.1.1. Система контроля версий Для управления исходным кодом должна использоваться система контроля версий кода, развернутая в инфраструктуре Заказчика. 4.4.7.1.2. Правила именования веток Имя ветки должно соответствовать следующему формату: / / Категории веток: ? feature/ — разработка новой функциональности, а также рефакторинг или удаление существующей; ? fix/ — исправление ошибок; ? hotfix/ — срочные исправления, применяемые в обход стандартного процесса разработки; ? test/ — для проведения экспериментов, не влияющих на основную разработку. Идентификатор задачи: после категории указывается ссылка на задачу (issue) в системе контроля версий кода. Описание: добавляется краткое описание решаемой задачи в формате kebab-case (слова разделяются дефисами, например, add-user-auth). Примеры именования веток: ? feature/#123/add-payment-integration; ? fix/#45/correct-calculation-logic; ? hotfix/#67/urgent-database-connection-patch. 4.4.7.1.3. Правила именования коммитов Сообщение коммита должно соответствовать соглашению Conventional Commits и состоять из категории и описания: : ? fix — исправление ошибки. Примеры сообщений коммитов: ? feat: добавление формы регистрации пользователя; ? fix: исправление ошибки валидации email-адреса; ? refactor: оптимизация алгоритма сортировки данных; ? chore: обновление версий в файле dependencies. 4.4.7.1.4. Модель ветвления В процессе разработки используются следующие основные ветви: ? main / master — стабильная ветка, содержит только код, прошедший полное тестирование и развернутый в продуктивных контурах; ? dev — ветка для интеграции завершенных задач, предназначенная для сборки и тестирования в тестовых средах. Попадание кода в main осуществляется только через Merge Request (MR) из dev - 4.2.4. Создание компонента «Интерактивная карта» (2 очередь) В составе создаваемого компонента должны отображаться данные, доступные в компоненте визуализации. Требования к интерфейсу интерактивной карты: – интерактивная карта должна быть представлена в виде объемной карты с учетом макетов, представленных в Приложении А к ТЗ; – интерфейс должен корректно отображаться на экранах мониторов (разрешение Full HD 1920?1080), телевизоров (разрешение 4К 3840?2160), жидкокристаллических панелей для видеостены, используемой Заказчиком, с параметрами каждой панели: диагональ 55 дюймов, разрешение 1920x1080; – интерфейс должен корректно отображаться на планшетных устройствах с диагональю экрана 10-12 дюймов, конкретные требования должны быть уточнены на этапе технического проектирования; – должна быть обеспечена кластеризация и генерализация отображения объектов на карте при изменении масштаба; – должно быть обеспечено отображение основных характеристик объектов при выборе их на карте; – должно быть обеспечено управление отображением слоев на карте; – должна быть обеспечена настройка цветовой индикации отображаемых объектов транспортной инфраструктуры; – должно быть обеспечено отображение легенды карты, содержащей отображаемые объекты на карте; – должна быть обеспечена возможность одновременного отображения не менее 5 000 ОТИ и ТС на карте. - На интерактивной карте должны быть отображены подвижные объекты совместно с объектами транспортной инфраструктуры (ОТИ), включая следующие возможности: § отображение местоположения транспортных средств (воздушный, водный и автомобильный транспорт) на карте в режиме реального времени (с заданным периодом обновления данных); § отображение маршрутов движения всех ТС за выбранный период времени, в том числе с использованием эффектов анимации; § отображение маршрутов движения ТС, связанных с карточкой события: ТС, являющихся участниками события, и ТС, находящиеся в заданном радиусе от события; § управление отображением сущностей и ОТИ на карте, включая настройку состава отображаемых объектов, поиск, фильтрацию, с использованием соответствующей панели управления и наглядным представлением результатов; § автоматическое изменение вида отображения объектов (цветовая индикация) по заданным условиям (например, при достижении критических значений параметров, характеризующих функционирование объекта); Должна обеспечиваться производительность обновления изображения на экране в 30 кадров в секунду на тестовой конфигурации пользовательского устройства (модель Бештау AIO2402/B560, входящая в Реестр российской промышленной продукции под номером 10394100 или аналог) при одновременном отображении не менее 5 000 объектов и 200 уникальных моделей объектов. Макеты интерфейсов Модуля СЦ должны быть предварительно согласованы с Заказчиком и разработаны с учетом требований ГОСТ Р ИСО 9241-161-2016 «Элементы графического пользовательского интерфейса» - 4.2.6. Взаимосвязи с внешними автоматизированными системами (1 очередь) Способы взаимодействия с внешними информационными системами должны быть определены на этапе технического проектирования. Должны быть выполнены следующие доработки: – интеграции с информационными ресурсами в целях получения данных о движении подвижных ТС (воздушные суда, суда водного транспорта); – интеграция с информационным ресурсом в целях получения данных о событиях на железнодорожном транспорте. Реализация интеграций должна включать проектирование и реализацию интеграционных механизмов обмена данными с учетом доступных вариантов реализации, обеспечение защищенных способов взаимодействия, настройку отображения отдельных данных на карте (настройка слоев). Взаимодействия, имеющие каналы связи, выходящие за пределы контролируемой зоны взаимодействующих систем, считаются защищенными, если для их защиты используются программные и/или программно-аппаратные шифровальные (криптографические) средства, сертифицированные ФСБ России (далее – СКЗИ). Выбор СКЗИ, схемы подключения и требуемого класса криптостойкости должен производиться в соответствии с Техническими условиями на подключение к информационным ресурсам ФГБУ «СИЦ Минтранса России» и инструкциями по подключению пользователей к ресурсам инфраструктуры Головного центра обработки данных, утвержденных приказом директора ФБГУ «СИЦ Минтранса России» от 24.05.2024 № 21-ОД - 4.3. Требования к оказанию услуг по технической поддержке Модуля СЦ 4.3.1. Общие требования к оказанию Услуг Техническая поддержка Модуля СЦ должна осуществляться с учетом требований постановления Правительства Российской Федерации от 06.07.2015 N 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации». Подрядчик обязан выполнять требования законодательства в сфере защиты информации, требования по защите информации, информационной безопасности, указанные в локальных нормативных актах ФГБУ «СИЦ Минтранса России», регламентирующих условия информационного взаимодействия, защиты информации и подключения к информационным ресурсам ФГБУ «СИЦ Минтранса России», участвующих в информационном взаимодействии в рамках оказания услуг по технической поддержке АСУ ТК в 2026 году - 4.3.1.1. Требования к составу и содержанию услуг третьего уровня технической поддержки Оказание услуг по технической поддержке Системы осуществляется в рамках этапов в соответствии с календарным планом. Подрядчик в течение 5 рабочих дней с даты заключения Контракта должен предоставить со своей стороны, а Заказчик со своей стороны Матрицу ответственных за взаимодействия в соответствии с Приложением 1 к Регламенту оказания услуг по третьему уровню технической поддержки Модуля СЦ (далее – Регламент, Приложение В). Подрядчик в течение 10 рабочих дней с даты заключения Контракта должен провести мероприятия по организации третьего уровня технической поддержки в соответствии с Регламентом. Услуги по третьему уровню технической поддержки Модуля СЦ должны включать: – организацию Подрядчиком третьего уровня технической поддержки; – информационно-консультационную поддержку работников Заказчика; – решение инцидентов, связанных с работой ППО; – адаптационное, конфигурационное и коррекционное сопровождение Модуля СЦ (в рамках действующих программных модулей и функциональности); – устранение уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности - 4.3.4. Требования к документированию результатов оказываемых услуг Для обеспечения контроля оказываемых услуг по поддержке Модуля СЦ со стороны Заказчика, по окончании каждого отчетного периода по контракту в соответствии с календарным планом, Подрядчик обязан предоставить Заказчику Отчет об оказанных услугах. Отчет должен содержать детальную информацию об оказанных услугах с указанием даты выполненных мероприятий и приложением обосновывающих документов (заявок, запросов, требований) или ссылкой на такие документы, если они содержатся в Модуле СЦ. Информация о выполненных мероприятиях по заявкам должна быть сформирована на основании соответствующих записей СРО по каждому этапу исполнения Контракта. В случае оказания услуги адаптационного, конфигурационного и коррекционного сопровождения Модуля СЦ, должны быть предоставлены документы, подтверждающие выполнение требований п. 29.3 приказа ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации». Фактическое время реагирования и время решения по всем обращениям, поступившим в СРО, формируется в СРО по итогам отчетного периода в разделе «Отчеты». Фактическое время реагирования и время решения по обращениям учитывает суммарное время, затраченное на реагирование и, соответственно, на работу по обращению с момента назначения обращения специалисту Подрядчика или группе исполнителей, ответственным за оказание услуг технической поддержки 3 уровня от начала до завершения работ Подрядчиком. При этом принимается суммарное время нахождения заявки в соответствующих статусах заявки СРО на стороне Подрядчика - 4.3.5. Требования к классификации обращений и заявок Обращения и заявки Заказчика классифицируются в соответствии с приоритетами и регламентными сроками, указанными в Приложении 2 к Регламенту. Регистрация обращений и заявок предусматривает создание новой записи в СРО с присвоением поступившему обращению или заявке (новой записи) уникального идентификатора. Запись в СРО должна содержать вопрос или проблему, которую требуется решить или оказать консультацию. Состав обязательной информации, которую должно содержать обращение или заявка, зафиксирован в Регламенте оказания Услуг. Если обращение или заявка автоматически зарегистрированы в СРО при отправке представителем Заказчика, Подрядчик проверяет корректность классификации обращения или заявки и может обратиться к Заказчику с просьбой корректировки, предоставив обоснования в соответствии с настоящей классификацией (Таблица 6) - 4.3.6.3.1. Требования к порядку оказания услуги по решению инцидентов, связанных с работой ППО При поступлении от Заказчика обращения (заявки), являющегося неисправностью в работе Модуля СЦ (инцидентом), Исполнитель реагирует на инцидент в СРО в срок не более 30 минут с момента поступления. В случае необходимости, для решения инцидента ответственный специалист должен связаться с инициатором обращения (заявки) для уточнения условий воспроизведения проблемы или для получения дополнительных сведений. После получения необходимых сведений от инициатора обращения (заявки) ответственный специалист производит диагностику с целью выявления причины инцидента и возможных путей устранения. В случае, если инцидент невозможно решить без получения дополнительных сведений от инициатора, и не удается связаться с инициатором в течение пяти рабочих дней, обращение (заявка) отклоняется в связи с недостатком данных для его решения, Заказчику направляется уведомление об отклонении обращения (заявки). Время, в течение которого невозможно связаться с инициатором, вычитается из общего времени обработки обращения (заявки). Все попытки связаться с инициатором должны фиксироваться с указанием даты и времени попытки, используемого способа связи (номер телефона, адрес электронной почты) и результата попытки (не удалось дозвониться, абонент недоступен, и т.д.) - Факт и время решения инцидента должны быть зафиксированы и отражены в СРО. В случае, если причиной сбоя в работе Модуля СЦ является выход из строя аппаратного обеспечения или неработоспособность смежной информационной системы, время работы над инцидентом приостанавливается до момента устранения неисправности. В ходе решения инцидентов могут быть выявлены дефекты ППО Модуля СЦ. В случае обнаружения дефектов ППО, Подрядчик информирует об этом Заказчика. Исполнитель может быть привлечен к проверке результата устранения дефекта по инициативе Заказчика. Приоритеты инцидентов приведены в Приложении Б к ТЗ. Детальный порядок оказания услуги по решению инцидентов, связанных с работой ППО Модуля СЦ определен в Регламенте оказания Услуг - 4.3.6.4. Требования к услугам адаптационного, конфигурационного и коррекционного сопровождения и доработки Модуля СЦ (в рамках действующих программных модулей и функциональностей) Услуги адаптационного, конфигурационного и коррекционного сопровождения и доработки Модуля СЦ включают: – управление изменениями и адаптация функций Модуля СЦ; – изменение настроек функционирования Модуля СЦ; – внесение изменений и/или модификаций Модуля СЦ (в рамках действующих программных модулей и функциональностей), направленных на улучшение их работоспособности и функциональных возможностей; – подготовка и передача Заказчику SQL запросов в СУБД для получения агрегированной информации из Модуля СЦ, которую невозможно получить с использованием графического пользовательского интерфейса; – адаптация модулей интеграций со смежными информационными системами - 4.4.7.1.5. Требования к используемым зависимостям (библиотекам) Все внешние зависимости проекта должны быть зафиксированы с указанием точных версий. Для контроля версий зависимостей в репозиторий обязательно должны быть включены следующие файлы: · Для JavaScript: package-lock.json или yarn.lock; · Для Python: requirements.txt (с зафиксированными версиями) или Pipfile.lock; · Для Go: go.mod и go.sum; Загрузка всех зависимостей должна производиться исключительно через внутренний прокси-репозиторий Заказчика, настроенный в соответствующем системе менеджере пакетов. Запрещается: · Использование плавающих версий (например, ^1.2.3, ~4.5.0, latest); · Использование библиотек, содержащих критические уязвимости, в том числе зарегистрированные в реестре CVE (Common Vulnerabilities and Exposures). 4.4.7.1.6. Требования к процессу непрерывной интеграции (CI) Сборка программного обеспечения, включая этапы компиляции, тестирования и анализа кода, должна выполняться исключительно в инфраструктуре непрерывной интеграции Заказчика. 4.4.7.1.7. Требования к хранению артефактов сборки Все артефакты сборки (результирующие пакеты, Docker-образы и т.д.) подлежат обязательному хранению в предназначенной для этого инфраструктуре Заказчика (артефакторий). Запрещается размещение финальных артефактов сборки на сторонних ресурсах - 4.4.8. Требования к техническому обеспечению Количество серверов, подключаемых и настраиваемых сервисов, их параметров, схемы соединений и настройки межсетевого взаимодействия должны быть согласованы с Заказчиком на этапе № 1 Техническое проектирование. Доступ к комплексу технических средств предоставляется Заказчиком по письменному запросу Подрядчика. Применяемые в Системе программно-аппаратные и аппаратные комплексы должны соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации», требованиям Постановления Правительства Российской Федерации от 23 декабря 2024 г. № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц». Модуль СЦ, работающий в составе АСУ ТК, развернут на вычислительных мощностях ГЦОД СИЦ Минтранса России - 4.5. Общие технические требования 4.5.1. Требования к численности и квалификации персонала и пользователей Модуля СЦ Программное обеспечение Модуля СЦ не должно требовать изменения штатной численности персонала Заказчика. Программное обеспечение Модуля СЦ не должно требовать наличия у пользователей дополнительной квалификации в сфере информационных технологий, кроме базовых знаний в обращении с персональным компьютером, базовых навыков работы в интернет-обозревателях и знаний о Модуле СЦ в объеме документов Руководство пользователя, Руководство администратора - 4.3.1.2. Требования к общему порядку оказания услуг Техническая поддержка Модуля СЦ должна быть организована на трех уровнях: – первый и второй уровни технической поддержки организуется Заказчиком; – третий уровень технической поддержки организуется Подрядчиком. Перечень действий на каждом уровне технической поддержки указан в Таблице 5: Таблица 5 – Перечень действий на каждом уровне технической поддержки Уровень технической поддержки Доступные действия Условия передачи задачи на следующий уровень Первый уровень технической поддержки (далее – 1-й уровень) – принимает обращения (заявки) пользователей Модуля СЦ и работников Заказчика; – регистрирует обращения в Модуле СЦ регистрации обращений; – присваивает уникальный идентификационный номер, классифицирует обращения; – самостоятельно решает обращения, которые связаны с недостаточной квалификацией пользователей или настройками в рамках своей компетенции; – взаимодействует с пользователями Модуля СЦ при решении проблемы Передает обращение на второй уровень поддержки в случае невозможности решения на своем уровне Второй уровень технической поддержки (далее – 2-й уровень) – принимает обращения от 1-го уровня; – уточняет классификацию обращения в результате дополнительного анализа; – самостоятельно решает обращения в рамках своей компетенции; – осуществляет техническую и консультационную поддержку Модуля СЦ; – взаимодействует с сотрудниками 1-го и 3-го уровня и пользователями Модуля СЦ; – формирует заявки для 3-го уровня и контролирует исполнение Передает обращение на третий уровень поддержки в случае невозможности решения на своем уровне Третий уровень технической поддержки (далее – 3-й уровень) – принимает обращения от 2-го уровня; – обеспечивает выполнение требований, предъявляемых Контрактом и настоящим Техническим заданием к Услугам, оказываемым Подрядчиком Все поступающие обращения должны быть исполнены Подрядчиком - Для обеспечения взаимодействия с Заказчиком Подрядчик со своей стороны определяет ответственных лиц, уполномоченных в структуре Подрядчика за своевременное и качественное оказание Услуг в рамках настоящего ТЗ, а также контактную информацию ответственных лиц (телефон, электронную почту). Подрядчик должен предоставить Заказчику единый адрес электронной почты для приема обращений (заявок) в течение 3 (трех) рабочих дней после заключения Контракта. Указанный в настоящем пункте адрес электронной почты (способ направления обращений (заявок) применяется в случае сбоя в работе СРО Заказчика. Со своей стороны, Заказчик предоставляет Подрядчику перечень и контактную информацию (телефон, электронную почту) уполномоченных лиц для осуществления взаимодействия с указанием зон ответственности. О любых изменениях в контактной информации ответственных лиц Стороны должны уведомить друг друга в течение 1 (одного) рабочего дня с момента возникновения таких изменений посредством уведомления на электронную почту ответственных лиц и/или в письменной форме. В результате оказания услуг по настоящему ТЗ не должны быть изменены исходные коды, дистрибутивы и иные компоненты Модуля СЦ вне согласованных с Заказчиком изменений. Любые изменения исходных кодов, дистрибутивов и иных компонентов Модуля СЦ должны производиться только после согласования с Заказчиком уполномоченными лицами по электронной почте или иным заранее согласованным способом. Не должна быть ухудшена надежность и производительность Модуля СЦ. Оказание услуг по Контракту не должно нарушать требования к информационной безопасности, описанной в документации на Модуль СЦ - Таблица 6. Категории обращений и заявок Категория Примеры Запрос на обслуживание Подготовка SQL запроса к СУБД для решения прикладной задачи и д.р. – запрос на любое действие, не являющееся запросом информации и несовершенный на основе происшествия, прямо или косвенно влияющего на работу Модуля СЦ Консультация «Где взять / куда обратиться...?», «Как сделать / выполнить…», «Как это работает…?» - запрос, имеющий своей целью получение информационной поддержки Инцидент Разбор ошибок/сбоев и подготовка материалов (корректировочных релизов, инструкций) для Заказчика для устранения ошибок/сбоев, которые приводят к частичному и полному нарушению работоспособности всех или отдельных функций ППО. Подготовка изменения и материалов, необходимых для проведения аварийно-восстановительных работ для возобновления работоспособности Модуля СЦ ЗНИ Подготовка изменений, связанных с изменением, улучшением/оптимизацией Модуля СЦ и выводом новой модифицированной функциональности в штатном режиме. Подготовка изменений, связанных с модификацией существующих и/или реализация новых интеграционных механизмов для получения/обработки данных внешних систем. Подготовка изменений графического интерфейса по требованиям Заказчика. Перечень статусов обращений (заявок) приведен в пункте 3.3. Регламента оказания Услуг. Назначение обращению (заявке) статуса «Закрыто» осуществляется Заказчиком только после получения от инициатора обращения (заявки) подтверждения о его исполнении или нахождения обращения (заявки) в статусе «Выполнено» и отсутствия повторных вопросов/запросов по данному обращению (заявки) в течение 5 рабочих дней. Категории и статусы обращений (заявок) могут быть скорректированы в процессе оказания услуг исключительно по согласованию с Заказчиком - 4.3.6. Требования к услугам технической поддержки 4.3.6.1. Требования к организации третьего уровня технической поддержки Основными задачами организации третьего уровня технической поддержки в рамках оказания услуг по технической поддержке Модуля СЦ являются организация эксплуатационной службы Подрядчика, проверка готовности технических и программных средств для обеспечения непрерывного функционирования ППО Модуля СЦ. Подрядчиком должны быть проведены организационно-штатные и подготовительные мероприятия (в т. ч. технические) в рамках организации технической поддержки Модуля СЦ. Подрядчик в течение 5 (пяти) рабочих дней с даты заключения Контракта должен: – определить и направить Заказчику документ «Перечень уполномоченных специалистов», содержащий контактную информацию (ФИО, должность, адрес рабочей электронной почты) лиц, ответственных за оказание услуг со стороны Подрядчика; – обеспечить подключение специалистов Подрядчика к Системе регистрации обращений (заявок) (СРО предоставляется Заказчиком) для оказания услуг; – согласовать с Заказчиком способ доступа Подрядчика к Модулю СЦ. Результат выполнения мероприятий фиксируется в Протоколе проверки результатов организационно-штатных и подготовительных мероприятий (см. Приложение Д к настоящему ТЗ) - 4.3.6.4.1. Требования к проведению изменений Основанием для внесения изменений является запрос от Заказчика. Все активности по внесению изменений должны быть согласованы с Заказчиком, а действия Подрядчика при оказании данной услуги должны быть зафиксированы. В рамках данного Технического задания изменениями считаются локальные доработки функционала Модуля СЦ, которые не должны приводить к необходимости выполнения дополнительных аттестационных испытаний или переаттестации АСУ ТК в соответствии с п. 33 приказа от 29.04.2021 № 77 «Об утверждении Порядка организации и проведения работ по аттестации объектов информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну». При необходимости внесения изменений в Модуль СЦ, не связанных с критичным инцидентом, существенно нарушающим работоспособность Модуля СЦ, Заказчик направляет Подрядчику обращение (заявку), в котором излагает суть изменения, которое требуется внести в Модуль СЦ. Исполнитель, в течение 3 (трех) рабочих дней с момента поступления соответствующего обращения (заявки), оценивает техническую возможность реализации запрашиваемого изменения и варианты реализации. По итогу проведения оценки Подрядчик направляет Заказчику заключение о возможности реализации данного изменения с описанием возможных вариантов реализации и согласует с Заказчиком проведение данного изменения - При проведении работ по изменению и адаптации Подрядчик должен: – обеспечить выполнение требований безопасной разработки программного обеспечения; – обеспечить предварительное проектирование технических решений и согласование с Заказчиком проекта реализации изменения; – использовать семантическое версионирование (SemVer) в работе, передать Заказчику все артефакты разработки (исходный код и сторонние библиотеки, конфигурации, сборочные и собранные образы и др.); – подготовить полноценное описание функционала, включенного в релиз, с необходимыми схемами и пояснениями к обновлению на стендах Заказчика; – обеспечить тестирование разработанного функционала на стендах Заказчика силами Подрядчика; – решение о переносе измененного ППО на продуктивный стенд принимается Заказчиком по итогу результатов проведенного тестирования; – обеспечить техническое сопровождение процедуры тестирования ППО и переноса измененного ППО на продуктивный стенд Заказчика; – обеспечить экстренное внесение соответствующих изменений в случае выявления некорректной работы продуктивного стенда Заказчика после проведения обновления по итогам разработанного изменения в кратчайшие сроки; – актуализировать при необходимости комплект эксплуатационной документации: o руководство пользователя; o руководство администратора; o иные документы (при необходимости). Результат выполнения изменений должен быть отражен в Отчете по оказанию услуг. Типы и приоритеты изменений могут быть скорректированы в процессе оказания услуг исключительно по согласованию с Заказчиком - 4.5.2. Требования к режимам функционирования Модуля СЦ Модуль СЦ должен предусматривать наличие следующих режимов работы: – штатный; – регламентный (профилактический); – аварийный. Основным режимом функционирования является штатный. В штатном режиме все компоненты корректно и полностью выполняют свои функции. Перерывов в работе как Модуля СЦ в целом, так и одного, либо нескольких компонентов не предусмотрено. Режим регламентного (профилактического) обслуживания предназначен для проведения работ по обновлению и техническому обслуживанию компонентов Модуля СЦ, а также резервному копированию данных. При работе в данном режиме допускаются перерывы в работе Модуля СЦ с предварительным информированием пользователей. Состав процедур по регламентному обслуживанию Модуля СЦ и их периодичность определяются Подрядчиком в процессе выполнения работ по созданию Модуля СЦ. В режиме регламентного (профилактического) обслуживания Модуль СЦ может функционировать с частичным ограничением своих функциональных возможностей, либо без ограничения, но со снижением показателей надежности и производительности. Перевод в данный режим работы должен осуществляться сразу после начала выполнения любой операции, отнесенной к этому режиму, с последующим возвратом в штатный режим функционирования сразу после ее завершения. Перевод в указанный режим должен осуществляться при возникновении необходимости проведения работ по обновлению и техническому обслуживанию компонентов Модуля СЦ, а также резервному копированию данных с условием предварительного оповещения пользователей. Аварийный режим функционирования характеризуется отказом одной или нескольких подсистем, вызванных выходом из строя аппаратного и/или программного обеспечения, а также в случае временной неработоспособности каналов связи между серверами. - В аварийном режиме осуществляется поиск неисправностей и проведение работ по их устранению. Перевод в аварийный режим должен осуществляться при возникновении сбоев, аварий и прочих незапланированных воздействий, сразу после наступления одной или нескольких аварийных ситуаций, с последующим возвратом в штатный режим функционирования сразу после окончания восстановительных работ. ПО Модуля СЦ должно обладать надежностью, обеспечивающей работу пользователей в произвольном режиме и оперативное восстановление работоспособности при сбоях. В целях обеспечения надежного функционирования ПО должно предусматривать: – сохранение целостности данных при нештатном завершении работы компонентов Модуля СЦ; – сохранение работоспособности программного обеспечения при некорректных действиях пользователя; – резервное копирование базы данных Модуля СЦ. – время восстановления работоспособности Модуля СЦ после отказа не более 4 часов. – отказоустойчивость на уровне 99% при единовременной количестве не менее 200 пользовательских сессий в Модуле СЦ. Указанные характеристики приведены без учета характеристик надежности инфраструктуры и времени передачи информации по каналам связи. При возникновении сбоев в аппаратном обеспечении, включая аварийное отключение электропитания, Модуль СЦ должен автоматически восстанавливать свою работоспособность (не требовать перенастройки) после устранения сбоев и корректного перезапуска аппаратного обеспечения - По результатам анализа угроз безопасности информации программного обеспечения и испытаний по выявлению уязвимостей в программном обеспечении Системы должна быть предоставлена отчетная документация по формам, утвержденным в Руководстве, и артефакты сборочной среды, подтверждающие проведение испытаний по выявлению уязвимостей в программном обеспечении Систем. Уязвимости подлежат устранению в сроки, обозначенные Заказчиком. В случае обнаружения уязвимого компонента Подрядчик должен заменить/обновить библиотеки. В случае, если уязвимость не подлежит исправлению на программном уровне, Подрядчик должен разработать меры предотвращения угроз безопасности, в том числе правила безопасности для наложенных средств защиты, рекомендации по безопасной настройке конфигурации для устранения потенциальных уязвимостей и снижения рисков информационной безопасности. Уязвимости, найденные ФСБ России, ФСТЭК России, Минцифры России, Роскомнадзором в ходе исполнения Контракта, а также в течение гарантийного периода, должны быть устранены Подрядчиком за свой счет в сроки, согласованные с Заказчиком - 4.5.6. Требования к эргономике и технической эстетике Взаимодействие пользователей с Модулем СЦ должно осуществляться посредством визуального графического интерфейса. Ввод-вывод данных, прием управляющих команд и отображение результатов их исполнения должны выполняться в интерактивном режиме. Интерфейс должен быть рассчитан на преимущественное использование манипулятора типа «мышь», то есть управление Модулем СЦ должно осуществляться с помощью набора экранных меню, кнопок, значков и т. п. элементов. Клавиатурный режим ввода должен использоваться главным образом при заполнении и/или редактировании текстовых и числовых полей экранных форм. Все надписи экранных форм, а также сообщения, выдаваемые пользователю (кроме системных сообщений), должны быть на русском языке. Модуль СЦ должен обеспечивать проверку вводимых пользователем данных и предупреждать о некорректно введённых значениях - Экранные формы должны проектироваться с учетом требований унификации: – все экранные формы пользовательского интерфейса должны быть выполнены в едином графическом дизайне, с одинаковым расположением основных элементов управления и навигации; – для обозначения сходных операций должны использоваться сходные графические элементы, кнопки и другие управляющие (навигационные) элементы. Термины, используемые для обозначения типовых операций, а также последовательности действий пользователя при их выполнении должны быть унифицированы; – внешнее поведение сходных элементов интерфейса (реакция на наведение указателя «мыши», переключение фокуса, нажатие кнопки) должно реализовываться одинаково. Структура размещения информации и представление этой структуры в Модуле СЦ должны соответствовать следующим требованиям: – пункты меню в пользовательском веб-интерфейсе должны быть сгруппированы в соответствии с тематикой информации, функциональными задачами и технологией работы; – каждому пункту меню должна соответствовать только одна выполняемая функция; – при совершении пользователями ошибочных действий должны выдаваться сообщения об ошибках. Эскизы визуального оформления компонента «Интерактивная карта» представлены в Приложении А. - 4.3.6.2. Требования к услугам информационно-консультационной поддержки работников Заказчика и пользователей Модуля СЦ Услуги информационно-консультационной поддержки сотрудников Заказчика включают: – обработку обращений и заявок, поступивших от сотрудников Заказчика; – консультирование сотрудников Заказчика и пользователей Модуля СЦ; – актуализацию документации, и других материалов по работе с Модулем СЦ при необходимости. – консультирование и разработку рекомендаций по настройке Модуля СЦ (без изменения программного кода), включая изменение настроек функционирования; – консультации по вопросам использования, настройки и возможностям Модуля СЦ; – консультации по проведению превентивных мер для недопущения аварийных ситуаций в Модуле СЦ; – консультации по предварительной диагностике и локализации возникшей неисправности Модуля СЦ; – консультации по вопросам обеспечения информационной безопасности Модуля СЦ и настройки функций, обеспечивающих корректную работу программного обеспечения для совершения юридически значимых действий в Модуле СЦ; – другие вопросы, связанные с работой Модуля СЦ. 4.3.6.2.1. Требования к порядку оказания услуг информационно-консультационной поддержки работников Заказчика и пользователей Модуля СЦ Подрядчик выполняет консультирование сотрудников Заказчика и пользователей Модуля СЦ. Консультация может быть предоставлена по согласованным с представителем Заказчика каналам коммуникации с регистрацией результата консультации в СРО Подрядчиком. Детальный порядок оказания консультационных услуг определен в Регламенте оказания Услуг - 4.3.6.3. Требования к услугам по решению инцидентов, связанных с работой ППО Подрядчик устраняет неисправности Модуля СЦ, связанные с работой ППО, выявленные в рамках оказания услуг согласно настоящему Техническому заданию, при этом в зону ответственности Подрядчика не входит устранение неисправностей, выявленных на стороне Заказчика и на стороне третьих лиц (провайдера связи, поставщика электропитания и т.д.). Первичная диагностика выявленной неисправности проводится на 1 и 2 уровнях технической поддержки и не входит в зону ответственности Подрядчика. Если при проведении первичной диагностики и попытке устранить неисправности на 1 и 2 уровнях технической поддержки, данную неисправность устранить не удалось и в процессе диагностики было выявлено, что проблема связана с работоспособностью ППО, обращение (заявка) назначается сотруднику Подрядчика, ответственному за оказание услуг технической поддержки 3 уровня. Инцидентами вне зоны ответственности Подрядчика являются: – работоспособность функциональности, выходящая за рамки текущей реализации функций в Модуле СЦ и/или являющаяся расширением требований Заказчика к функциям Модуля СЦ; – проведение профилактических и плановых работ, согласованных с Заказчиком; – нарушение работоспособности функций Модуля СЦ, вызванное проведением работ на стороне Заказчика - 4.3.6.4.2. Требования к изменению настроек функционирования Изменение настроек функционирования может проводиться в рамках допустимых пределов изменения функционирования, заложенных в архитектуру Модуля СЦ. Изменение настроек функционирования включает в себя изменение данных и справочников, изменение форм документов, формируемых Модулем СЦ, изменение и настройку форматов и версий передачи данных в смежные системы. Доработка программного кода Модуля СЦ может допускаться (в случае необходимости) при выполнении работ по адаптации функций Модуля СЦ в части изменения формата передачи данных в смежные информационные системы при условии соблюдения требований пункта 29.3 приказа ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации» - 4.3.6.5. Требования к услугам по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности По запросу Заказчика Подрядчик должен провести работу по приведению ППО в соответствие с требованиями по обеспечению информационной безопасности. Критичность уязвимости оценивается в соответствии в соответствии с Методическим документом ФСТЭК России «Методика оценки уровня критичности уязвимостей программных, программно-аппаратных средств» (утвержден ФСТЭК России 30.06.2025), а также с учетом ГОСТ 56545-2015 и международными стандартами (CVSS 3.0 и выше), и задает необходимый срок устранения. В процессе проведения Заказчиком обследования Модуля СЦ и выявления уязвимостей в ППО, связанных с исходным кодом Модуля СЦ и/или используемыми компонентами (библиотеками), Заказчик направляет Подрядчику обращение (заявку) на устранение, с указанием критичности и срочности принятия мер по устранению в СРО. - Подрядчик при оказании услуг по обновлению или устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности должен: – провести анализ уязвимостей и связанных с ними исходным кодом и/или используемыми компонентами (библиотеками); – выработать варианты устранения указанных уязвимостей и согласовать с Заказчиком их реализацию; – своевременно внести изменения в исходный код Модуля СЦ и/или используемые компоненты (библиотеки) и подготовить соответствующее обновление; – провести обновление Модуля СЦ в тестовом контуре Заказчика и проинформировать Заказчика о готовности проведения тестирования; – протестировать успешность обновления или устранения уязвимостей в ППО и корректность функционирования Модуля СЦ на тестовом контуре, совместно с Заказчиком; – при невозможности незамедлительного устранения уязвимости приоритетов «Критический» и «Высокий» Подрядчик обязан предоставить исчерпывающий список причин и согласовать план достаточных компенсирующих мер с ответственными сотрудниками Заказчика. Результат внесения изменений отображается в соответствующей записи в СРО и в составе Отчета об оказанных услугах - 4.3.6.5.1. Требования к порядку оказания услуг по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности Подрядчик в соответствии с приоритетами обращений и контрольными сроками исполнения (см. Приложение Б к ТЗ) оценивает техническую возможность и сроки устранения уязвимостей, и реализацию обновления Модуля СЦ. По итогу проведения оценки Подрядчик направляет в заявке СРО Заказчику заключение о возможности устранения уязвимостей и/или обновления в ППО и согласует с Заказчиком проведение данных работ - Технические меры по обеспечению надежности должны предусматривать: – резервирование критически важных компонентов и данных Системы и отсутствие единой точки отказа; – использование программного резервирования (программной избыточности); – изменение конфигурации используемых средств и применение специализированного ПО, обеспечивающего высокую надёжность. Организационные меры по обеспечению надежности должны быть направлены на минимизацию ошибок пользователей (а также обслуживающего персонала при эксплуатации и проведении работ по обслуживанию), минимизацию времени ремонта или замены вышедших из строя компонентов за счёт: – обеспечения для обслуживающего персонала требуемого уровня квалификации; – регламентации и нормативного обеспечения выполнения работ обслуживающим персоналом; – своевременной диагностики неисправностей. Расчетное значение коэффициента доступности Модуля СЦ должно составлять не менее 0,95. - 4.5.3. Требования по диагностированию Модуля СЦ Диагностирование Модуля СЦ должно осуществляться путем анализа записей в системных журналах СУБД, операционных систем серверов, а также с помощью встроенных средств диагностирования общего программного обеспечения Модуля СЦ. Диагностированию подлежат: – сбои и нарушения функционирования технического обеспечения (серверов) Модуля СЦ; – сбои и нарушения функционирования системного программного обеспечения серверов, используемых для работы Модуля СЦ; – сбои и нарушения функционирования прикладного программного обеспечения серверов, используемых для работы Модуля СЦ; – случаи недоступности (отсутствия ответа) или некорректные ответы внешних систем; – сбои и нарушения функционирования СУБД; – сбои при выполнении регламентных операций резервного копирования. При возникновении аварийных ситуаций либо ошибок в программном обеспечении диагностические инструменты должны позволять сохранять набор информации, необходимой для идентификации и устранения проблемы. Модуль СЦ и ее компоненты должны обеспечивать возможность диагностики своей работоспособности с возможностью интеграции с модулем мониторинга АСУ ТК. Набор передаваемых журналов и метрик должен быть определен на этапе технического проектирования - 4.5.4. Требования к надежности Должно быть предусмотрено сохранение работоспособности Модуля СЦ при некорректных действиях пользователя и сохранение целостности данных при нештатном завершении работы Модуля СЦ (отказ рабочей станции, потеря сетевого доступа и т.п.). Модуль СЦ должен предоставлять механизмы обеспечения сохранности данных через применение процедур резервного копирования и восстановления, описанных в документации на Систему. Ключевые показатели надежности информационной системы — допустимое время на восстановление работоспособности Модуля СЦ (RTO - recovery time objective) и/или допустимый интервал времени потери изменений в данных при сбоях/отказах (RPO – recovery point objective) должны быть определены Подрядчиком и согласованы с Заказчиком на этапе технического проектирования - 4.5.7. Требования по сохранности информации при авариях В случае возникновения аварии или сбоя в процессе выполнения пользовательских задач должно быть обеспечено восстановление баз данных до состояния на момент последней завершенной Модулем СЦ транзакции, и структуры файлового хранилища. Все аварийные ситуации должны обрабатываться программно с выдачей соответствующих сообщений, с корректной обработкой ситуации (завершение транзакций, закрытие файлов и т.п.), без потери обрабатываемой информации. В Модуле СЦ должны быть предусмотрены меры, обеспечивающие целостность данных в случае отказа программного обеспечения или аппаратных средств, исключая случаи физического уничтожения носителя или нарушения функциональности носителя, операционной системы или СУБД по вине их производителя либо обслуживающего персонала. Используемые аппаратные и системные платформы должны обеспечивать сохранность и целостность информации в Модуле СЦ при полном или частичном отключении электропитания, аварии сетей телекоммуникации, полном или частичном отказе технических средств Модуля СЦ. Технические решения должны обеспечивать сохранность информации в случае возникновения следующих событий (аварий, отказов и т.п.): – отказ аппаратного обеспечения на сервере; – отключение питания на сервере; – отказ аппаратного обеспечения на рабочей станции; – отключение питания на рабочей станции администратора; – отказ линий связи, в том числе при осуществлении обмена данными - 4.5.8. Требования к защите от влияния внешних воздействий Требования к защите от влияния внешних воздействий не предъявляются - 4.5.9. Требования к патентной чистоте и патентоспособности 4.5.9.1. Исключительные права на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, базы данных, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, принадлежат Российской Федерации в лице Заказчика. Право собственности на результаты работ, отчетные документы и материалы, полученные в ходе выполнения работ по Контракту, принадлежат Российской Федерации в лице Заказчика и считаются переданными с момента подписания Сторонами Акта сдачи-приемки выполненных работ. Разработанное программное обеспечение поставляется вместе с исходными кодами. 4.5.9.2. Все проектные и технические решения должны отвечать требованиям четвертой части Гражданского кодекса Российской Федерации. Результаты Работ должны быть свободными от возможности предъявления любых прав и притязаний третьих лиц, основанных на промышленной, интеллектуальной или другой собственности. 4.5.9.3 Результаты выполненных Работ не должны повлечь необходимость осуществления Заказчиком закупок программного обеспечения (как исключительных, так и неисключительных прав) для обеспечения функциональности Системы в соответствии с Техническим заданием. При выполнении работ Подрядчик должен использовать только объекты интеллектуальной собственности, права на которые приобретены (получены) и используются без нарушений прав на интеллектуальную собственность третьих лиц или предоставлены Заказчиком - При проведении работ по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности необходимо выполнить следующее: – Заказчику сформировать заявку на устранение (обновление) в СРО с полным списком обнаруженных уязвимостей и планируемыми работами; – согласовать в рабочем порядке время начала и завершения работ, перечень работ, выполняемых в рамках обновления или устранения уязвимостей в ППО с Заказчиком; – оповестить Заказчика о начале проведения работ на тестовом контуре; – провести работы по обновлению или устранению уязвимостей в ППО на тестовом контуре Модуля СЦ в установленные сроки; – протестировать выполнение работ в тестовом контуре и проинформировать Заказчика о готовности переноса ППО на продуктивный контур; – силами Заказчика обновить продуктивный контур Модуля СЦ, в соответствии с планом устранения и выполненными работами; – совместно с Заказчиком проверить корректность функционирования Модуля СЦ и устранения уязвимостей в продуктивном контуре Модуля СЦ по результатам обновления; – при необходимости актуализировать документацию (описание архитектуры, анкеты постановки на мониторинг и иные документы). Любые изменения в части обновления или устранения уязвимостей в ППО на промышленном контуре Модуля СЦ должны применяться только в случае успешного проведения аналогичных работ на тестовом контуре. Детальный порядок оказания услуги по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности определен в Регламенте оказания Услуг - 4.4. Требования к видам обеспечения 4.4.1. Требования к лингвистическому обеспечению Документация на Модуль СЦ должна разрабатываться на русском языке. Взаимодействие пользователей с Модулем СЦ посредством графического интерфейса должно происходить на русском языке за исключением сообщений, зависящих от настроек системного программного обеспечения, установленного на рабочих местах пользователей. При разработке программных решений Модуля СЦ должно быть предусмотрено использование языков программирования высокого уровня, приведенных в Таблице 7. Таблица 7. Языки и средства разработки, специального программного обеспечения Модуля СЦ Категория Наименование Назначение Языки программирования Kotlin Разработка серверной логики и сервисов (backend) JavaScript / TypeScript Разработка клиентской части (frontend) Python Разработка скриптов интеграции, обработки данных и автоматизации Фреймворки и библиотеки Vue.JS Разработка пользовательских интерфейсов (веб-интерфейсы компонентов визуализации и отчетности) React Разработка пользовательских интерфейсов (при необходимости создания сложных интерактивных компонентов) Решения по лингвистическому обеспечению, включая перечень используемых языков программирования, должны быть согласованы с Заказчиком на этапе технического проектирования - 4.4.2. Требования к математическому обеспечению Требования к математическому обеспечению не предъявляются. 4.4.3. Требования к метрологическому обеспечению Требования к метрологическому обеспечению не предъявляются. 4.4.4. Требования к организационному обеспечению Требования к организационному обеспечению не предъявляются. 4.4.5. Требования к методическому обеспечению Задачи методического обеспечения Модуля СЦ должны быть обеспечены за счет использования технологических и методических документов касающихся вопросов функционирования транспортного комплекса и разработки и эксплуатации ПО. 4.4.6. Требования к информационному обеспечению Состав, структура и способы организации информационного обеспечения в Модуле СЦ должны быть определены на этапе технического проектирования. Факты информационного обмена с внешними системами должны фиксироваться в соответствующем журнале - 4.5.5. Требования к информационной безопасности Работы по защите информации/информационной безопасности, не включенные в состав настоящего раздела, требуемые в соответствии с требованиями постановления Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации», а также нормативно правовых актов в области защиты персональных данных и обеспечения безопасности объектов критической информационной инфраструктуры, будут проведены в рамках исполнения отдельного контракта, заключенного по результатам отдельной закупочной процедуры (не является частью данного ТЗ), включающего: – определение актуальных угроз безопасности информации и актуализация модели угроз безопасности информации (при необходимости); – выполнение требований о согласовании технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России в установленном порядке; – выполнение требований по устранению Подрядчиком замечаний и недостатков, в случае их выявления при согласовании Заказчиком технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России; – выполнение требований к классу защищенности ГИС, уровню защищенности персональных данных и категории значимости объекта КИИ РФ, установленных для Головного центра обработки данных ФГБУ «СИЦ Минтранса России» (далее – ГЦОД); - – определение перечня объектов защиты информационной системы; – описание (актуализированных) требований к системе защиты информации, а также к мерам защиты информации информационной системы в зависимости от установленных классов защищенности, уровня защищенности персональных данных и категории значимости объектов КИИ РФ (приказы ФСТЭК России № 21, 117, 239); – выполнение требований к мерам по защите ГИС от атак, направленных на отказ в обслуживании, в соответствии с пунктами 30, 34, 59, 63 Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений, утвержденных приказом ФСТЭК России от 11.04.2025 № 117; – описание (актуализированных) требований по защите информации, подлежащих реализации в информационно телекоммуникационной инфраструктуре ГЦОД; – выполнение требований о применении сертифицированных средств защиты информации, включая их классы защиты и уровни доверия; – выполнение требований о запрете использования с 01.01.2025 органами (организациями) средств защиты информации странами происхождения, которых являются иностранные государства в соответствии с пунктом 6 Указа Президента Российской Федерации от 01.05.2022 № 250; – выполнение требований по обеспечению непрерывного взаимодействия с ГосСОПКА в установленном порядке; - 4.5.9.4. Подрядчик подтверждает, что обладает всеми правами на передачу Заказчику исключительных прав в соответствии с требованиями настоящего раздела Технического задания. В случае, если к Заказчику по вине Подрядчика будут предъявлены претензии в этой части, иски третьих лиц, связанные с нарушением их прав, Подрядчик принимает на себя такие претензии и иски и возмещает Заказчику все расходы и весь ущерб, понесенный в связи с ними. 4.5.9.5. Подрядчик обязан согласовать с Заказчиком необходимость использования при выполнении работ охраняемых результатов интеллектуальной деятельности, права на которые принадлежат Подрядчику или третьим лицам. 4.5.9.6. В случае, если при выполнении Работ используется готовое программное обеспечение (платформа, подсистема, СУБД и т.д.), которое становится частью (компонентом) Системы, Заказчику передаются полные исключительные права, или неисключительные права (путем заключения лицензионного/сублицензионного договора/соглашения) на такое программное обеспечение со следующими возможностями: – права передаются бессрочно (на весь срок действия исключительных прав); – территория действия Российская Федерация; – должно быть обеспечено право Российской Федерации (в лице Заказчика) передавать, дорабатывать, распространять, развивать результаты работ, созданные в процессе исполнения Контракта, а также перерабатывать такое программное обеспечение. Лицензионное (сублицензионное) соглашение (договор), Акт передачи прав, подписанные Подрядчиком, согласие правообладателя, оформленное в соответствии с положениями Гражданского кодекса Российской Федерации (в случае, если Подрядчик не является правообладателем такого программного обеспечения), инструкция по инсталляции, руководство администратора, руководство пользователя передаются Заказчику в сроки, установленные Техническим заданием для соответствующего функционала Системы - Лицензионное (сублицензионное) соглашение (договор) не может возлагать на Заказчика какие-либо обязанности (в т.ч. в части конфиденциальности, предоставления отчетности), не предусмотренные Контрактом. 4.5.9.7. Передача Заказчику исключительных прав, или простых (неисключительных) прав не может повлечь увеличение стоимости Контракта и/или изменение иных существенных условий Контракта. 4.5.9.8. Функциональность Модуля СЦ передается в объеме и в сроки, установленные Техническим заданием. 4.5.9.9. Нарушение условий настоящего раздела Технического задания, в т.ч. отсутствие соответствующего лицензионного (сублицензионного) соглашения (или договора), либо предоставление лицензионного (сублицензионного) соглашения (или договора), не соответствующего требованиям действующего законодательства Российской Федерации или требованиям Контракта, является нарушением существенных условий Контракта. 4.5.9.10. В случае, если в соответствии с пунктом 4.5.9.6 Заказчику передается исключительное право, такая передача осуществляется в порядке, установленном Гражданским кодексом Российской Федерации. 4.5.9.11. В случае, если при выполнении Работ положения пунктов 4.5.9.5-4.5.9.6 не применялись, Подрядчик в составе отчетной документации предоставляет об этом декларацию в свободной форме. Декларация должна содержать сведения о полном соответствии результата Работ требованиям Контракта, а также о неприменении при выполнении работ готового программного обеспечения (платформ, подсистем, СУБД и т.д.), которое стало частью (компонентом) Системы - – выполнение требований по обеспечению в автоматизированном режиме с Национальной системой противодействия DDoS-атакам (НСПА) Центра мониторинга и управления сетью связи общего пользования ФГУП «ГРЧЦ» в рамках реализации мер по защите ГИС от атак, направленных на отказ в обслуживании; – детализированные требования к составу и содержанию работ по аттестации, а также к их результатам в соответствии с пунктами 13, 15 и 16 требований приказа ФСТЭК России от 29.04.2021 № 77 «Об утверждении Порядка организации и проведения работ по аттестации объектов информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну» - 4.5.5.1. Требования к безопасности исходного кода Процесс разработки исходного кода должен соответствовать требованиям законодательства, нормативным правовым актам Российской Федерации, приказу ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по безопасности значимых объектов критической информационной инфраструктуры Российской Федерации», а также учитывать отраслевые практики безопасной разработки. Подрядчик должен предоставить Заказчику Руководство по безопасной разработке программного обеспечения (далее – Руководство), применяемое при разработке исходного кода Модуля СЦ. Руководство должно содержать: · описание процесса безопасной разработки и ролевой модели, отражающей зоны ответственности сотрудников Подрядчика; · описание процессов моделирования, оценки и формирования мер предотвращения угроз, применяемых Подрядчиком; · описание методик, применяемых Подрядчиком при разработке исходного кода (правила написания кода); · описание методик, периодичности проведения и инструментария статического, динамического, композитного и фаззинг тестирования исходного кода, включающего критерии отбора релизных версий ПО, применяемые Подрядчиком в процессе разработки; · описание механизмов безопасности в процессе сборки и доставки (безопасность образов, безопасность секретов, безопасность окружения и сборочной среды), применяемые Подрядчиком; · утвержденные шаблоны отчетной документации (в том числе акты), в соответствии с которыми Заказчик принимает результаты проверок (артефакты сборочного процесса), проведенных Подрядчиком; · описание процедур отслеживания и исправления обнаруженных ошибок и уязвимостей программного обеспечения; · описание способов и сроков доведения Подрядчиком до Заказчика информации об уязвимостях программного обеспечения, о компенсирующих мерах по защите информации или ограничениях по применению программного обеспечения, способов получения пользователями программного обеспечения его обновлений, проверки их целостности и подлинности - Подрядчик должен обеспечить реализацию и проведение внутренних проверок мер по разработке безопасного ПО, приведенных в Руководстве. Подрядчик должен провести анализ угроз безопасности информации программного обеспечения в соответствии с ГОСТ 58412-2019 «Защита информации. Разработка безопасного программного обеспечения. Угрозы безопасности информации при разработке программного обеспечения». Подрядчик должен провести испытания по выявлению уязвимостей в программном обеспечении Системы: · проведение статического анализа исходного кода программы; · проведение динамического анализа исходного кода программы; · проведение композитного анализа исходного кода и образов программы; · проведение фаззинг-тестирования программы, направленного на выявление в ней уязвимостей. Испытания по выявлению уязвимостей в программном обеспечении Системы должны быть проведены в рамках: · предварительных испытаний; · опытной эксплуатации; · приемочных испытаний - 4.5.9.12. Передача Заказчику комплекта документов, материалов и сведений, предусмотренных нормативными правовыми актами Российской Федерации в сфере информационных технологий, защиты информации, правовой защиты интересов государства в области интеллектуальной собственности, включая документы, подтверждающие отказ авторов (разработчиков) от исключительных прав на передаваемые объекты интеллектуальной собственности в пользу Подрядчика, с проектами заявок на государственную регистрацию в установленном порядке прав Заказчика на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, базы данных, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, осуществляется Подрядчиком в составе отчетной документации, предусмотренной условиями Контракта. 4.5.9.13. По результатам выполнения работ по развитию системы должны быть подготовлены материалы для регистрации доработанной версии Системы (объекта учета) в НФАП в соответствии с требованиями постановления Правительства Российской Федерации от 30 января 2013?г. №?62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин» (с изменениями и дополнениями) в части обязательности размещения результатов работ в национальном фонде алгоритмов и программ для электронных вычислительных машин - 4.5.10. Требования по стандартизации и унификации К Модулю СЦ предъявляются следующие требования в части стандартизации и унификации: – работы по развитию Модуля СЦ должны производиться в соответствии с действующими стандартами и нормами Российской Федерации; – при создании и модернизации элементов Модуля СЦ следует руководствоваться действующими в Российской Федерации национальными стандартами и другими нормативно-техническими документами; – используемые оборудование и материалы, подлежащие обязательной сертификации, должны иметь соответствующие сертификаты; – ПО Модуля СЦ должно проектироваться и разрабатываться с учётом обеспечения требований унификации; – применяемые при создании Модуля СЦ технические (форматы данных, протоколы передачи и прочие) и организационные (регламенты, требования, инструкции) решения должны быть доступны и документированы в виде, достаточном для независимой (без обращения к Подрядчику) реализации третьими сторонами; – термины, обозначения и наименования, используемые в ПО, должны быть стандартизованы и унифицированы, выполнены на русском языке; – взаимодействие элементов и их внешнее поведение должно быть реализовано одинаково и производиться по единым правилам - 4.5.11. Требования к показателям назначения 4.5.11.1. Требования к показателям назначения мероприятий по развитию Модуля СЦ В рамках выполнения работ по развитию Модуля СЦ, предусмотренных ТЗ, показатель назначения «Количество пользователей» должен соответствовать значениям, приведенным в данном разделе. Пояснения по показателям, связанным с количеством пользователей, приведены в Таблице 8. Таблица 8. Определения показателей, связанных с количеством пользователей в Модуле СЦ № Показатель Определение Расчетное количество пользователей Количество пользователей, работу которых должен обеспечить Модуль СЦ к моменту сдачи работ по Контракту с учетом достижения всех показателей назначения Расчетное количество одновременно работающих пользователей Количество одновременно работающих пользователей, работу которых должен обеспечивать Модуль СЦ к моменту сдачи работ по Контракту с учетом достижения всех показателей назначения Значения показателей количества пользователей, достижение которых необходимо обеспечить, представлено в Таблице 9 - Таблица 9. Значения показателей количества пользователей № Показатель Значение 1. Расчетное количество пользователей 1 000 2. Расчетное среднее количество одновременно работающих пользователей 200 Развитие Модуля СЦ должно быть направлено на достижение следующего эффекта (показателя), подставленного в мероприятии 103.002 «Информационно-аналитическая система регулирования на транспорте (АСУ ТК)» ВПЦТ Минтранса России: Выполнение работ по развитию Модуля СЦ предусмотрено мероприятием по развитию АСУ ТК, приведенном в ВПЦТ Минтранса России на 2026-2028 гг: № 103.002 «АСУ ТК» в составе ИТ расхода 103.26.000005 «Развитие предусматривает реализацию ОКР и эффектов, приведенных в Таблице 10. Таблица 10. ОКР и эффекты, приведенные в ВПЦТ Минтранса России на 2026 г. № ОКР Дата ОКР Эффекты 1 Обеспечено информационное взаимодействие с Минобороны России о происшествиях на транспортных объектах 25.12.2026 Сокращено время сбора и передачи сведений для Минобороны России о ЧС и НС на транспорте с 120 до 10 минут 2 Обеспечена автоматизация формирования отчетов о нештатных ситуациях на транспорте, в том числе по данным внешних систем 25.12.2026 Сокращено время на подготовку отчетов о нештатных ситуациях на транспорте с 20 до 5 минут Реализация остальных ОКР не является предметом данного ТЗ и проводится в рамках отдельного технического задания. - 4.5.11.2. Требования к показателям назначения мероприятий по эксплуатации Модуля СЦ. Работы по эксплуатации Модуля СЦ не должны обеспечивать режимы функционирования Модуля СЦ, приведенные в разделе 4.5.2 данного ТЗ - 5. СОСТАВ И СОДЕРЖАНИЕ РАБОТ ПО РАЗВИТИЮ И ТЕХНИЧЕСКОЙ ПОДДЕРЖКЕ МОДУЛЯ СЦ (КАЛЕНДАРНЫЙ ПЛАН) - 1 Техническое проектирование Сопроводительным письмом предоставляются Заказчику: · Технический проект, включая следующие документы: – Ведомость технического проекта; – Ведомость машинных носителей информации – Пояснительная записка; – Описание информационного обеспечения системы; – Описание автоматизируемых функций; – Схема функциональной структуры; – Описание организации информационной базы; – Описание программного обеспечения; · Макеты экранных форм компонента «Интерактивная карта»; · Руководство по безопасной разработке программного обеспечения; · Документ о приемке Начало: с даты заключения контракта Окончание: не позднее 31.07.2026 - - Значение характеристики не может изменяться участником закупки - 2 Услуги по технической поддержке Модуля СЦ (с даты заключения контракта по 10.09.2026) По окончании оказания Услуг сопроводительным письмом предоставляются Заказчику: – Отчет об оказанных Услугах по технической поддержке; – Актуальные на дату окончания оказания Услуг по данному этапу исходные коды прикладного ПО на электронном носителе (в случае внесения изменений); – Инструкция по сборке и развертыванию (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство пользователя (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство администратора (в случае внесения изменений); – Документ о приемке Начало: с даты заключения контракта Окончание: не позднее 10.09.2026 - 3 Разработка программного обеспечения (1 очередь, пп. 4.2.1, 4.2.6 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ; – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 1 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 1 очереди; – Руководство по резервному копированию; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 16.09.2026 - 4 Разработка программного обеспечения (2 очередь, пп. 4.2.3, 4.2.4 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ. – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 2 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 2 очереди; – Руководство по резервному копированию; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 25.09.2026 - 5 Разработка программного обеспечения (3 очередь, пп. 4.2.2, 4.2.5 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ; – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 3 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 3 очереди; – Руководство по резервному копированию; – Описание ролевой модели; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 09.10.2026 - 6 Опытная эксплуатация (1 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акт о завершении опытной эксплуатации 1 очереди; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке 17.09.2026 Окончание: не позднее 26.10.2026 - 7 Опытная эксплуатация (2 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акт о завершении опытной эксплуатации 2 очереди; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке 26.09.2026 Окончание: не позднее 26.10.2026 - 8 Опытная эксплуатация (3 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Акт о завершении опытной эксплуатации 3 очереди; – Документ о приемке Начало: с 10.10.2026 Окончание: не позднее 26.10.2026 - 9 Приемочные испытания Сопроводительным письмом предоставляются Заказчику: – Программа и методика приёмочных испытаний; – Протокол приемочных испытаний; – Исходные коды и дистрибутивы на электронном носителе (при условии внесения изменений, с учетом доработок по результатам опытной эксплуатации и проведенных испытаний); – Комплект рабочей документации на Модуль СЦ (при условии внесения изменений, с учетом доработок по результатам опытной эксплуатации и проведенных испытаний); – Акт приемки Системы в эксплуатацию; – Акт приемки-передачи исключительных прав на объект; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке; – Документы в соответствии с разделом 4.5.9 ТЗ; – Обеспечение гарантийных обязательств Начало: с 27.10.2026 Окончание: не позднее 10.11.2026 - 10 Услуги по технической поддержке Модуля СЦ (с 11.09.2026 по 15.12.2026) По окончании оказания Услуг сопроводительным письмом предоставляются Заказчику: – Отчет об оказанных Услугах по технической поддержке; – Актуальные на дату окончания оказания Услуг по данному этапу исходные коды прикладного ПО на электронном носителе (в случае внесения изменений); – Инструкция по сборке и развертыванию (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство пользователя (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство администратора (в случае внесения изменений); – Документ о приемке Начало: с 11.09.2026 Окончание: не позднее 15.12.2026 - Работы по развитию Системы (за исключением этапов проведения опытной эксплуатации и услуг по технической поддержке) могут быть выполнены досрочно. При досрочном выполнении работ (этапов работ) Подрядчик в письменной форме уведомляет Заказчика о готовности представить для приемки результаты проведения работ в соответствии с требованиями Контракта. Подрядчик также вправе досрочно приступать к работам в рамках очередного этапа при наличии технической, организационной готовности - при условии получения соответствующего согласования Заказчиком. Сдача-приемка результатов выполненных работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная, техническая документация, а также результаты Работ по каждому этапу предоставляется Заказчику в порядке, предусмотренном Контрактом и настоящим Техническим заданием, до размещения Подрядчиком в Единой информационной системе в сфере закупок документа о приемке. Документ о приемке размещается в ЕИС по каждому этапу в соответствии с условиями Контракта. Согласование документов осуществляется в электронном виде посредством переписки с адресов электронной почты Заказчика и Подрядчика, указанных в контракте. - Сдача-приемка результатов выполненных работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная техническая документация, а также результаты работ предоставляются Заказчику в порядке, предусмотренном Контрактом и ТЗ, до размещения Подрядчиком в ЕИС документа о приемке. Документ о приемке размещается в ЕИС по каждому этапу в соответствии с условиями Контракта. Этапы выполнения работ по развитию Модуля СЦ приведены в Таблице 11. Таблица 11. Этапы выполнения работ по развитию Модуля СЦ. № этапа Наименование этапа Результат (отчетная документация) Срок исполнения этапа - 6. ПОРЯДОК РАЗРАБОТКИ МОДУЛЯ СЦ - Проектирование Модуля СЦ должно включать разработку следующих документов: – Ведомость технического проекта; – Ведомость машинных носителей информации – Пояснительная записка; – Описание информационного обеспечения системы; – Описание автоматизируемых функций; – Схема функциональной структуры; – Описание организации информационной базы; – Руководство по безопасной разработке программного обеспечения; – Описание программного обеспечения; – Макеты экранных форм компонента «Интерактивная карта». Структура документов должна соответствовать ГОСТ Р 59795-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов». Разработка Модуля СЦ должна включать в себя: – разработку программного обеспечения в части новых функций Модуля СЦ; – сборка исходного кода, развертывание и настройку доработанного программного обеспечения Модуля СЦ на вычислительных мощностях Заказчика (тестовый контур); – Комплект рабочей документации на Модуль СЦ; – разработку документа «Программа и методика предварительных испытаний»; – разработку документа «Программа и методика приемочных испытаний»; – разработку документа «Программа опытной эксплуатации». Структура документов должна соответствовать ГОСТ Р 59795-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов». В ходе выполнения работ формируется правоустанавливающая, отчетная, рабочая и техническая документация в соответствии с Контрактом и Календарным планом, приведенном в разделе 5. - - Значение характеристики не может изменяться участником закупки - 6.1. Сведения о гарантийном обслуживании Модуля СЦ Под гарантией понимается устранение Подрядчиком своими силами и за свой счет допущенных по его вине недостатков, выявленных после приемки выполненных Работ, как в работе самой Модуля СЦ, так и недостатков в отчетной документации. Если в период гарантийного срока обнаружатся недостатки, то Подрядчик обязан устранить их за свой счет, в сроки, установленные Заказчиком. Гарантийный срок в этом случае продлевается на период устранения недостатков. Срок гарантии: 1 год с даты приемки Заказчиком результатов исполнения Этапа № 9 контракта. Подрядчиком должны быть внесены соответствующие исправления в техническую и рабочую документацию (указанную в пунктах 5 и 6 настоящего ТЗ), связанные с устранением замечаний к работе Модуля СЦ или в случае выявления Заказчиком недостатков в такой документации в период гарантийного срока. Внесение изменений в документацию технического и рабочего проектирования осуществляется в соответствии с ГОСТ 2.503-2023 и ГОСТ Р 2.504-2021. - 7. ПОРЯДОК КОНТРОЛЯ И ПРИЕМКИ РЕЗУЛЬТАТОВ ВЫПОЛНЕНИЯ РАБОТ ПО РАЗВИТИЮ МОДУЛЯ СЦ - Испытания должны быть организованы и проведены в соответствии с ГОСТ Р 59792-2021 «Информационная технология. Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем». Должны быть проведены следующие виды испытаний: – предварительные испытания; – опытная эксплуатация; – приемочные испытания. Указанные виды испытаний проводятся в отношении не функциональных требований и функциональных возможностей, разрабатываемых в соответствии с настоящим ТЗ. Отдельные виды испытаний проводятся поэтапно в сроки, установленные Календарным планом. Предварительные испытания, опытная эксплуатация, приемочные испытания проводятся комиссией, создаваемой организационно-распорядительным документом Заказчика, который должен определять состав комиссии, порядок ее работы. Методы предварительных испытаний и порядок их проведения должны быть определены в документе «Программа и методика предварительных испытаний», который должен быть утвержден Заказчиком до начала предварительных испытаний. По результатам предварительных испытаний оформляется Протокол предварительных испытания и Акт о приемке в опытную эксплуатацию. Порядок проведения и методы испытаний во время опытной эксплуатации должны быть определены в документе «Программа опытной эксплуатации», который должен быть утвержден Заказчиком до начала опытной эксплуатации. Ход и результаты опытной эксплуатации отражаются в документе «Журнал опытной эксплуатации», и учитываются в ходе приемочных испытаний. По результатам опытной эксплуатации подписывается Акт о завершении опытной эксплуатации - - Значение характеристики не может изменяться участником закупки - До момента подключения внешних ИС, Подрядчиком могут быть использованы эмуляторы ИС для прохождения предварительных испытаний, опытной эксплуатации и приемочных испытаний. В рамках опытной эксплуатации должны быть проведены мероприятия по нагрузочному тестированию Модуля СЦ. Документ «Программа и методика приемочных испытаний» должен быть разработан с учетом недостатков, выявленных в ходе опытной эксплуатации, утвержден Заказчиком до начала приемочных испытаний, при этом проверки Модуля СЦ в части не устраненных недостатков, выявленных в процессе опытной эксплуатации, должны быть вынесены в отдельный раздел «Программы и методики приемочных испытаний». В процессе приемочных испытаний должно быть проверено устранение недостатков, полученных в ходе опытной эксплуатации. После завершения устранения всех замечаний, препятствующих приемке Системы в эксплуатацию, перечисленных в Протоколе приемочных испытаний, Подрядчик должен письменно уведомить Заказчика о том, что все замечания устранены, после чего приемочные испытания по решению Заказчика могут быть проведены повторно. Процедура приемочных испытаний проводится до подписания Протокола приемочных испытаний, не содержащего замечаний, препятствующих приемке Системы в эксплуатацию. Приемочные испытания Системы считаются завершенными успешно, если Протокол приемочных испытаний не содержит замечаний, препятствующих приемке Системы в эксплуатацию - 8. ТРЕБОВАНИЯ К СОСТАВУ И СОДЕРЖАНИЮ РАБОТ ПО ПОДГОТОВКЕ МОДУЛЯ СЦ К ВВОДУ В ЭКСПЛУАТАЦИЮ - По результатам проведения приемочных испытаний оформляется Протокол приемочных испытаний и Акт приемки в эксплуатацию. В случае, если взаимодействие с внешними системами не может быть проверено на средах постоянной эксплуатации взаимодействующих систем (по причине неготовности со стороны внешней системы или иным причинам), функции взаимодействия, разработанные в соответствии с требованиями ТЗ, должны быть проверены на тестовых данных с использованием программ-имитаторов взаимодействия. По результатам выполнения этапа приемочных испытаний должны быть подготовлены материалы для регистрации доработанной версии Модуля СЦ (объекта учета) в НФАП в соответствии с требованиями постановления Правительства Российской Федерации от 30 января 2013?г. №?62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин» (с изменениями и дополнениями) в части обязательности размещения результатов работ в национальном фонде алгоритмов и программ для электронных вычислительных машин. Сдача-приемка результатов выполнения Работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная, техническая документация, а также программное обеспечение предоставляется Заказчику в порядке, предусмотренном Контрактом и ТЗ до размещения Подрядчиком в Единой информационной системе в сфере закупок документа о приемке. Результаты проведения опытной эксплуатации, предварительных и приемочных испытаний должны быть зафиксированы в соответствующих протоколах и актах. Выявленные отклонения от настоящего ТЗ, оформляются как недостатки Модуля СЦ - - Значение характеристики не может изменяться участником закупки - Протоколы предварительных и приемочных испытаний должны содержать вывод о соответствии Модуля СЦ предъявляемым требованиям, а также сроки устранения замечаний и реализации рекомендаций, сформулированных комиссией в ходе предварительных и приемочных испытаний. Условием для передачи Модуля СЦ в промышленную эксплуатацию является устранение всех замечаний. Документация на Модуль СЦ и ее части (техническая и рабочая) должна содержать исчерпывающее описание принятых проектных решений в объеме, достаточном для ее дальнейшего развития и эксплуатации. Техническая и рабочая документация должна содержать описание разработанных результатов работ, в том числе программ для ЭВМ, прикладных программных интерфейсов, алгоритмов и протоколов информационного взаимодействия, технических требований, спецификаций и форматов обмена данными для взаимодействия с другими информационными системами, в объеме, достаточном для их установки, настройки, эксплуатации и развития в дальнейшем без привлечения Подрядчика. Исходные коды передаются в виде и составе, позволяющем провести: – сборку (компиляцию) Модуля СЦ в контролируемой Заказчиком среде; – установку полученной Модуля СЦ на специально подготовленную контролируемую Заказчиком инфраструктуру; – проверку функциональных возможностей Модуля СЦ; – оформление Модуля СЦ в качестве объекта национального фонда алгоритмов и программ для электронных вычислительных машин - 8.1. Требования, предъявляемые в соответствии с Приказом Минцифры России от 17.12.2020 № 715 «Об утверждении типовых условий контрактов на выполнение работ по созданию и (или) развитию (модернизации) государственных (муниципальных) и (или) иных информационных систем» Передача исходных кодов, разработанных в ходе выполнения работ, программ для электронных вычислительных машин (далее – программа для ЭВМ) должна сопровождаться передачей всех необходимых для сборки и запуска программы для ЭВМ библиотек зависимостей, программных сценариев (скриптов) для проведения установки (развертывания) программы для ЭВМ. Подрядчик в процессе сдачи-приемки работ по Контракту должен провести демонстрацию процесса и установки (развертывания) разработанных программ для ЭВМ. Документация на Модуль СЦ должна содержать описание принятых проектных решений в объеме, достаточном для ее дальнейшего развития и эксплуатации - 9. ТРЕБОВАНИЯ К ДОКУМЕНТИРОВАНИЮ - 9.1. Общие требования Документация на Модуль СЦ должна быть разработана в составе, указанном в разделах 5-8 данного ТЗ, и должна удовлетворять требованиям комплекса стандартов и руководящих документов на автоматизированные системы: – ГОСТ Р 2.105-2019 в части оформления текстовых документов; – ГОСТ 34.201-2020 в части наименования и обозначения документов. Документация на Модуль СЦ должны оформляться на листах формата А4. Допускается для размещения рисунков и таблиц использование листов формата А3 с подшивкой по короткой стороне листа. Документы объемом более 25 (двадцати пяти) листов должны содержать информационную часть, состоящую из аннотации и содержания. Исходные коды должны быть представлены в 1 (одном) экземпляре на электронном носителе, отчетные материалы должны быть представлены в 2 (двух) экземплярах на бумажном носителе (по одному экземпляру для Заказчика и Подрядчика) и в 1 (одном) экземпляре на электронном носителе в формате документов DOCX и PDF. При разработке документов на Модуль СЦ допускается отклонение от требований комплекса стандартов, описанных выше. Документам на Модуль СЦ должны в обязательном порядке присваиваться уникальные децимальные номера в соответствии с порядком, установленном в ГОСТ 34.201-2020. Документ «Программа и методика предварительных испытаний» должен включать приложения с формой протокола предварительных испытаний и формой акта приемки в опытную эксплуатацию. Документ «Программа опытной эксплуатации» должен включать приложение с формой журнала опытной эксплуатации. Документ «Программа и методика приемочных испытаний» должен включать приложения с формой протокола приемочных испытаний и формой акта приемки в эксплуатацию - - Значение характеристики не может изменяться участником закупки - 10. ИСТОЧНИКИ РАЗРАБОТКИ - 10.1. Список литературы Специальная литература для разработки ТЗ не использовалась. 10.2. Нормативно-методические документы Список используемых нормативно-методических документов представлен в разделе 1.6 технического задания. ? Приложение А Эскизы визуального оформления компонента «Интерактивная карта» - - Значение характеристики не может изменяться участником закупки - Приложение Б Параметры оказания услуг - Б.1. Базовые параметры оказания Услуг Базовые параметры оказания Услуг приведены ниже: – режимы оказания Услуг (таблица Б.1.1); – сроки предоставления отчетности (таблица Б.1.2). Таблица Б.1.1 - Режимы оказания Услуг № п/п Параметр Значение - - Значение характеристики не может изменяться участником закупки - 1 Режим работы Системы Круглосуточно (24х7) 2 Режим доступности информационно-консультационной поддержки пользователей Системы 2.1 Прием и регистрация обращений (заявок) в СРО Регистрация обращений (заявок) производится круглосуточно в режиме 24х7, без праздников и выходных дней. Обработка заявок первой линией поддержки осуществляется в рабочие дни с 9 до 18 часов 2.2 Консультирование сотрудников Заказчика и пользователей Системы в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 3 Режим доступности по решению инцидентов, связанных с работой ППО: 3.1 - приоритет «Критический» Круглосуточно (24х7) 3.2 - приоритет «Высокий» Круглосуточно (24х7) 3.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 3.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4 Режим доступности услуг по адаптации, конфигурации и коррекционному сопровождению Системы 4.1 - приоритет «Критический» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.2 - приоритет «Высокий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 5 Режим доступности по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности 5.1 - приоритет «Критический» Круглосуточно (24х7) 5.2 - приоритет «Высокий» Круглосуточно (24х7) 5.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 5.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) - Таблица Б.1.2. Сроки предоставления отчетности, с момента получения запроса № п/п Параметр Значение 1 Предоставление отчета об оказанных услугах за произвольный период 10 рабочих дней 2 Предоставление подробной информации по инциденту с приоритетом «Критический» 16 рабочих часов 3 Предоставление актуализированной документации 10 рабочих дней - Б.2. Приоритеты и регламентные сроки решения обращений (заявок) В зависимости от уровня сбоя в работе Системы обращению (заявке) присваивается один из следующих приоритетов, а также в зависимости от приоритета обращения (заявки) устанавливаются следующие контрольные сроки решения в соответствии с таблицей ниже (Таблица Б.2.1). Таблица Б.2.1 – Приоритеты и регламентные сроки решения обращений (заявок) № п/п Приоритет Максимальное время реагирования Время решения (срок выполнения) Описание приоритета По информационно-консультационной поддержке сотрудников Заказчика и пользователей Системы 1 - не более 1 часа не более 10 часов - По решению инцидентов, связанных с работой ППО: 1 Критический не более 30 минут не более 4 часов - полная недоступность ППО; - недоступность ключевых функций - ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО; - невозможность информационного обмена с ППО для ИС более 4 часов 2 Высокий не более 1 часа не более 8 часов - ошибки/сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; - снижение быстродействия СПО (время отклика ППО на операции превышает 30 секунд); - недоступность управления правами и ролями пользователей 3 Средний не более 4 часов не более 24 часов - невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым -недоступность функции формирования отчетов 4 Низкий не более 8 часов не более 40 часов - отклонение в работе ППО, не влияющее на корректную работу функций; - другие сбои и ошибки, затрагивающие основные функции ППО - По адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) 1 Критический не более 40 минут не более 8 часов - изменения, необходимые при проведении аварийно-восстановительных работ для возобновления работоспособности Системы; - изменения, связанные с критичными ошибками, блокирующими возможность оказания государственных услуг и/или чтение и внесение данных в Систему 2 Высокий не более 1 часа не более 40 часов - изменения, относящиеся к обеспечению работоспособности основной функциональности Системы, устраняют выявленные дефекты в работе Системы, оказывающие существенное влияние на работу пользователей в Системе; - изменения, затрагивающие три и более подсистемы/модуля Системы для адаптации 3 Средний не более 4 часов не более 72 часов - изменения, связанные с развитием/улучшением/оптимизацией Системы и выводом новой функциональности в штатном режиме для одного-двух модулей/подсистем; - изменения, связанные с развитием интеграционных механизмов Системы, например обновление существующих и/или реализация новых видов сведений СМЭВ, обновление существующих и/или реализация новых API, адаптация и/или изменение механизмов импорта и экспорта данных Системы и т.д. 4 Низкий не более 8 часов не более 160 часов - изменения, связанные с ошибками/корректировкой/изменением в отображении информации в пользовательском графическом интерфейсе Системы (графика, текст, органы управления, элементы интерфейса) - По устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности 1 Критический не более 30 минут не более 24 часов - критические уязвимости, влияющие на возможную полную недоступность ППО, ключевых функций Системы, ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО без возможности восстановления работоспособности Системы. - Критический уровень CVSS > 8.0 2 Высокий не более 1 часа не более 84 часов - критические уязвимости, влияющие на ошибки и сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО. - Высокий уровень CVSS 5.0 - 8.0 3 Средний не более 4 часов не более 120 часов - уязвимости, влияющие на невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым - Средний уровень CVSS 2.0 - 4.9 4 Низкий не более 8 часов не более 160 часов - уязвимости, влияющие на отклонение в работе ППО, не влияющее на корректную работу функций; - другие сбои и ошибки, затрагивающие основные функции ППО - Низкий уровень CVSS < 2.0 - Взаимодействие Заказчика и Подрядчика в части регистрации и контроля времени реагирования и решения обращения (заявки) осуществляется через СРО. Заказчик предоставляет Подрядчику доступ к СРО после заключения Контракта. Поступившие от разных пользователей заявки по поводу однотипных инцидентов или имеющие общую причину должны объединяться в одну заявку. Срок выполнения включает время диагностики инцидента, в ходе которого определяется причина инцидента (проблемы) и способ его устранения. Подрядчик должен обеспечить функционирование Модуля СЦ в соответствии с требованиями и параметрами, указанными в настоящем ТЗ и Регламенте оказании услуг. Основные параметры быстродействия типовых операций в Модуле СЦ указаны в таблице ниже (таблица Б.2.2). Таблица Б.2.2 - Параметры быстродействия Модуля СЦ № п/п Наименование параметра Значение (секунд) 1 Среднее время получения сообщения из очереди сообщений 10 2 Среднее время получения ответа от Системы 5 3 Среднее время открытия карточки реестра 5 - Приложение В Регламент оказания услуг - 4.3. Форма обращения (заявки) на оказание услуг по адаптационному конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) При подаче обращения (заявки) типа «ЗНИ» в СРО указывается (Таблица 7): Таблица 7 – Описание атрибутов формы обращения (заявки) на оказание услуг по адаптационному, конфигурационному и коррекционному сопровождению Системы Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 10) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 9) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 10) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 10) Категория обращения (заявки): запрос на изменение Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 7) Приоритет изменения Время, очередность решения обращения (заявки), ресурсы, привлекаемые для решения обращения (заявки), порядок/процедура действий при решении обращения (заявки) – поле СРО «Приоритет» (см. рисунок 7) Тип изменения Справочник, классифицирующий типовые запросы характерные для Системы – поле СРО «Предмет обращения» (см. рисунок 7) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 7) Текст запроса на оказание услуги по адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 7) - - Значение характеристики не может изменяться участником закупки - На рисунке 7 приведена форма обращения (заявки) типа «ЗНИ» в СРО. Рисунок 7 - Форма обращения (заявки) типа «ЗНИ» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуг по адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей), заполненную в свободной форме - 4.4. Форма обращения (заявки) на оказание услуги по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности При подаче обращения (заявки) типа «Инцидент» в СРО указывается (Таблица 8): Таблица 8 – Описание атрибутов формы обращения (заявки) на оказание услуг по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности - Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 8) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 8) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 8) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 8) Категория обращения (заявки): инцидент Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 8) Приоритет Время, очередность решения обращения (заявки), ресурсы, привлекаемые для решения обращения (заявки), порядок/процедура действий при решении обращения (заявки) – поле СРО «Приоритет» (см. рисунок 8) Тип изменения Справочник, классифицирующий типовые запросы характерные для Системы – поле СРО «Предмет обращения» (см. рисунок 8) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 8) Текст запроса на оказание услуги по обновлению или удалению уязвимых компонентов (библиотек) ППО в соответствии с требованиями к обеспечению информационной безопасности Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 8) - На рисунке 8 приведена форма обращения (заявки) типа «Инцидент» в СРО. Рисунок 8 - Форма обращения (заявки) типа «Инцидент» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуги по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности, заполненную в свободной форме - Приложение 1 к Регламенту Матрица ответственных за взаимодействия в рамках выполнения работ по техническому сопровождению Системы Таблица 1 – Ответственные за взаимодействия в рамках выполнения работ по техническому сопровождению Системы со стороны Исполнителя ФИО Должность Адрес электронной почты Телефон — — — Общий контакт - Приложение 2 к Регламенту Приоритеты и регламентные сроки решения обращений (заявок) Приоритеты и регламентные сроки решения обращений (заявок) приведены в таблице 1. Таблица 1 – Приоритеты и регламентные сроки решения обращений (заявок) № п/п Приоритет Максимальное время реагирования Время решения (срок выполнения) Описание приоритета - По информационно-консультационной поддержке сотрудников Заказчика и пользователей Системы 1 – не более 1 часа не более 10 часов – - По решению инцидентов, связанных с работой ППО 1 Критический не более 30 минут не более 4 часов – полная недоступность ППО; – недоступность ключевых функций; – ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО; – невозможность информационного обмена с ППО для ИС более 4 часов 2 Высокий не более 1 часа не более 8 часов – ошибки/сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; – снижение быстродействия СПО (время отклика ППО на операции превышает 30 секунд); – невозможность управления правами и ролями пользователей 3 Средний не более 4 часов не более 24 часов – невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым недоступность функции формирования отчетов 4 Низкий не более 8 часов не более 40 часов – отклонение в работе ППО, не влияющее на корректную работу функций; – другие сбои и ошибки, затрагивающие основные функции ППО - По адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) 1 Критический не более 40 минут не более 8 часов – изменения необходимые при проведении аварийно-восстановительных работ для возобновления работоспособности Системы; – изменения, связанные с критичными ошибками, блокирующими возможность оказания государственных услуг и/или чтение и внесение данных в Систему 2 Высокий не более 1 часа не более 40 часов – изменения относящиеся к обеспечению работоспособности основной функциональности Системы, устраняют выявленные дефекты в работе Системы, оказывающие существенное влияние на процесс оказания государственных услуг и работу пользователей в Системе; – изменения, затрагивающие три и более подсистемы/модуля Системы для адаптации 3 Средний не более 4 часов не более 72 часов – изменения, связанные с развитием/улучшением/оптимизацией Системы и выводом новой функциональности в штатном режиме для одного-двух модулей/подсистем; – изменения, связанные с развитием интеграционных механизмов Системы, например, обновление существующих и/или реализация новых видов сведений СМЭВ, обновление существующих и/или реализация новых API, адаптация и/или изменение механизмов импорта и экспорта данных Системы и т.д. 4 Низкий не более 8 часов не более 160 часов – изменения, связанные с ошибками/ корректировкой/изменение в отображении информации в пользовательском графическом интерфейсе Системы (графика, текст, органы управления, элементы интерфейса) - По устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности 1 Критический не более 30 минут не более 24 часов – критические уязвимости, влияющие на возможную полную недоступность ППО, ключевых функций Системы, ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО без возможности восстановления работоспособности Системы; – Критический уровень CVSS > 8.0 2 Высокий не более 1 часа не более 84 часов – критические уязвимости, влияющие на ошибки и сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; – Высокий уровень CVSS 5.0 - 8.0 3 Средний не более 4 часов не более 120 часов – уязвимости, влияющие на невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым; – Средний уровень CVSS 2.0 - 4.9 4 Низкий не более 8 часов не более 160 часов – уязвимости, влияющие на отклонение в работе ППО, не влияющее на корректную работу функций; – другие сбои и ошибки, затрагивающие основные функции ППО; – Низкий уровень CVSS < 2.0 - Приложение Г Форма Отчета об оказанных услугах Отчет об оказанных услугах за этап «наименование этапа» в период с «__» _________ по «__» _________. № п/п Наименование услуги Общее количество Номер ОРС Краткое Описание Время реагирования по ТЗ Время реагирования фактическое Время решения по ТЗ Время решения фактическое Результат соблюдения времени реагирования Результат соблюдения времени решения Примечание 1 Услуги по информационно-консультационной поддержке работников Заказчика 2 546782 Консультация по работе Модуля СЦ 1 2 10 часов 11 часов Нет Нет 567123 Консультация по схеме БД 1 1 10 часов 1 час Да Да 2 … … Заказчик Подрядчик /Должность/ /Должность/ ____________________ /Ф.И.О/ ___________________ /Ф.И.О/ М.П. М.П. «_____»_______________________202_г. «_____»_______________________202_г - Приложение 1 к Отчету об оказанных услугах Журнал обращений (заявок) на оказание услуги по информационно-консультационной поддержке пользователей Системы (шаблон) Наименование Исполнителя в этапе «наименование этапа» в период с ________________ по _______________ оказал(о) Услугу по поддержке пользователей Системы в объеме, указанном в Таблице 1 Таблица 1 - Журнал обращений (заявок) пользователей Системы № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. ИТОГО зарегистрировано: Всего обращений (заявок): ________ ИТОГО решено: Всего обращений (заявок): ________ - Приложение 2 к Отчету об оказанных услугах Журнал обращений (заявок) по решению инцидентов, связанных с работой ППО (шаблон) Наименование Исполнителя в этапе «наименование этапа» в период с ________________ по _______________ оказал(о) Услугу по решению инцидентов в объеме, указанном в Таблице 1. Таблица 1 - Журнал по решению инцидентов № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. ИТОГО зарегистрировано: Всего инцидентов: ________ ИТОГО решено: Всего инцидентов: ________ - Приложение 3 к Отчету об оказанных услугах Журнал обращений (заявок) выполнения адаптационного, конфигурационного и коррекционного сопровождения Системы (шаблон) Журнал выполнения адаптации, конфигурации и коррекции Системы сформирован за этап «наименование этапа» в период с «__» _________ по «__» ____________ и представлен в таблице ниже (Таблица 1). Таблица 1 - Журнал выполнения адаптации, конфигурации и коррекции сопровождения Системы № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. Количество выполненных заявок за этап: ________ - Приложение 4 к Отчету об оказанных услугах Журнал обращений (заявок) по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности (шаблон) Журнал обращений (заявок) по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности сформирован за этап «наименование этапа» в период с «__» _________ по «__» ____________ и представлен в таблице ниже (Таблица 1). Таблица 1 - Журнал выполнения заявок по устранению уязвимостей в ППО № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. Количество выполненных заявок за этап: ________ - Приложение Д Форма Протокола проверки результатов организационно-штатных и подготовительных мероприятий (шаблон) Протокол проверки результатов организационно-штатных и подготовительных мероприятий Настоящий Протокол содержит результаты проверки организационно-штатных и подготовительных мероприятий, проведенных Исполнителем (Таблица Д.1). Таблица Д.1. Протокол проверки результатов № Мероприятия Подготовительного этапа Результат проверки 1. Определить и направить Заказчику документ «Ответственные за взаимодействия в рамках выполнения работ по техническому сопровождению Системы со стороны Исполнителя». Документ содержит контактную информацию (ФИО, должность, адрес электронной рабочей почты, номер телефона) не менее чем о 2 лицах, ответственных за оказание услуг со стороны Подрядчика Выполнено/Не выполнено 2. Обеспечить подключение специалистов Подрядчика к Системе Выполнено/Не выполнено 3. Обеспечить подключение специалистов Подрядчика к СРО Выполнено/Не выполнено Заказчик Подрядчик /Должность/ /Должность/ ____________________ /Ф.И.О/ ___________________ /Ф.И.О/ М.П. М.П. «_____»_______________________202_г. «_____»_______________________202_г - 4.2. Форма обращения (заявки) на оказание услуги по решению инцидентов, связанных с работой ППО При подаче обращения (заявки) типа «Инцидент» в СРО указывается (Таблица 6): Таблица 6 – Описание атрибутов формы обращения (заявки) на оказание услуги по решению инцидентов, связанных с работой ППО Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 6) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 6) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 6,) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 6) Категория обращения (заявки): инцидент Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 6) Приоритет изменения Время - одно из значений: Низкий, Средний, Высокий или Критический. Определяет, очередность решения обращения (заявки), ресурсы, привлекаемые для решения обращения (заявки), порядок/процедура действий при решении обращения (заявки) – поле СРО «Приоритет» (см. рисунок 6,) - Тип изменения Справочник, классифицирующий типовые запросы характерные для Системы – поле СРО «Предмет обращения» (см. рисунок 6) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 6) Полное описание инцидента, включая скриншоты и описание шагов, приведших к неисправности Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 6) Однократность/неоднократность Круг пользователей или компьютеров, затронутых данным инцидентом Действия, предпринятые для самостоятельного решения инцидента (при наличии) Версии используемого программного обеспечения на клиентской рабочей станции, где воспроизводится ошибка (операционная система, прикладное программное обеспечение) Дополнительная информация - На рисунке 6 приведена форма обращения (заявки) типа «Инцидент» в СРО. Рисунок 6 - Форма обращения (заявки) типа «Инцидент» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуги по решению инцидентов, связанных с работой ППО, заполненную в свободной форме - Уровень технической поддержки Организационно-структурная часть технической поддержки, имеющая определённые организационно-нормативными документами зоны ответственности, обязанности, а также временные нормативы, в течение которых эти обязательства должны выполняться либо эскалироваться на следующий уровень технической поддержки Услуги Услуги по технической поддержке Информационно-аналитической системы регулирования на транспорте АСУ ТК ФИО Фамилия, имя, отчество Эскалация Процедура повышения внимания к обращению (заявке) путем повышения его приоритета и/или передачи на следующий уровень технической поддержки, а также привлечение ролей, которые могут принимать решения без передачи на следующий уровень технической поддержки API Англ. Application Programming Interface — программный интерфейс приложения, интерфейс прикладного программирования — описание способов (набор классов, процедур, функций, структур или констант), которыми одна компьютерная программа может взаимодействовать с другой программой - CVSS Англ. Common Vulnerability Scoring System - открытый стандарт, используемый для расчета количественных оценок уязвимости в безопасности компьютерной системы, обычно с целью понять приоритет ее исправления. В современном инструментарии информационной безопасности используется версия 3.0 и выше с дополнительными метриками к базовым оценкам ID Англ. Identifier – идентификатор, уникальный признак объекта, позволяющий отличать его от других объектов, то есть, идентифицировать SLA Англ. Service Level Agreement - утвержденные условия по обработке обращения (заявки) с установленными метриками времени, которые определяют пороговые значения для эскалации в зависимости от статуса обращения (заявки) (например, время реакции – время от регистрации до осуществления первичной обработки, время решения – время от регистрации обращения (заявки) до его решения и т.д.) SQL Англ. Structured Query Language — «язык структурированных запросов», — декларативный язык программирования, применяемый для создания, модификации и управления данными в реляционной базе данных, управляемой соответствующей СУБД - 1 Общие сведения 1.1 Полное наименование Услуг Оказание услуг по технической поддержке Модуля СЦ АСУ ТК в 2026 году. 1.2 Предмет Регламента оказания услуг Требования Технического задания - 2 Общие положения 2.1 Цель и задачи оказания услуг Целью технической поддержки Системы является обеспечение ее стабильного и безопасного функционирования и эксплуатации, предупреждение, выявление и устранение сбоев в работе Системы и минимизация их неблагоприятного влияния. Для достижения поставленной цели требуется решение следующих задач: 1. Обеспечение информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы. 2. Поддержание параметров функционирования ППО Системы, удовлетворяющих требованиям производственных процессов, включая их непрерывность. 3. Обеспечение бесперебойного функционирования ППО и своевременное устранение сбоев и аварийных ситуаций в Системе. 4. Своевременное устранение уязвимостей при выявлении таковых, в соответствии с требованиями к обеспечению информационной безопасности. 5. Адаптация, конфигурирование, коррекция программного обеспечения в соответствии с изменениями нормативно-правовой базы и запросами уполномоченных сотрудников органов государственной власти, включая выполнение процедур тестирования и участие в обновлениях ППО на стендах Заказчика. 6. Обеспечение сохранения работоспособности ППО в изменяемой среде эксплуатации. 7. Ведение документации по настоящему контракту и инициирование актуализации документации на Систему по результатам обработки запросов Заказчика и внесения соответствующих изменений в ППО - 2.2 Общее описание процесса оказания сопровождения (технической поддержки) Системы Процесс оказания технической поддержки Системы включает: 1. Поступление обращений (заявок) от пользователей и их регистрацию. 2. Сопровождение обращений (заявок) в соответствии с их классификацией и приоритизацией, в том числе, с их последующей эскалацией. 3. Определение ролей и регламент их взаимодействия при осуществлении деятельности по процессу. 4. Решение обращений (заявок) в установленные настоящим Регламентом сроки. 5. Взаимодействие между 1-м, 2-м и 3-м уровнями технической поддержки, в том числе, с формированием заданий для сопровождения Системы. 6. Контроль качества выполняемых Исполнителем работ, состоящий из проверки сценария, приводящего к ошибке, зафиксированной в Инциденте, и/или к ошибке воспроизведения, а также тестирование внесенных изменений в рамках ЗНИ. 7. Обеспечение мониторинга и проведение анализа процесса обработки поступающих в техническую поддержку обращений (заявок). Техническая поддержка реализуется путем проведения ответственными сотрудниками соответствующей информационно-консультационной деятельности в соответствии с определенными ролями, а также выполнения Исполнителем конкретных действий по своевременному выявлению причин сбоев и аварийных ситуаций и их устранению, а также по адаптации, конфигурированию, корректировке Системы, включая выполнение процедур тестирования и участия в обновлениях Системы. Все роли подразделяются на уровни поддержки, взаимодействующие между собой в соответствии с блок-схемой процесса технической поддержки. Общая схема процесса рассмотрения обращений (заявок) в соответствии с видами технической поддержки представлена на рисунке 1. . Рисунок 1 - Общая схема процесса рассмотрения обращений (заявок) в соответствии с видами технической поддержки - 2.3 Каналы связи Должна быть предусмотрена омниканальность в части приема обращений (заявок). Получение обращений (заявок) технической поддержкой происходит по следующим каналам связи: – СРО; – электронная почта; – телефонная линия. Исполнитель обеспечивает прием обращений (заявок) от Заказчика и предоставляет информацию в рамках оказания услуг по техническому сопровождению Системы, руководствуясь матрицей взаимодействия, приведенной в Приложении 1 к настоящему Регламенту - 3 Порядок оказания Услуг 3.1 Типы обращений (заявок) Обращения и заявки Заказчика классифицируются в соответствии с приоритетами и регламентными сроками, указанными в Приложении 2 к настоящему Регламенту. Регистрация обращений и заявок предусматривает создание новой записи в СРО с присвоением поступившему обращению или заявке (новой записи) уникального идентификатора. Запись в СРО должна содержать вопрос или проблему, которую требуется решить или оказать консультацию. Если обращение или заявка автоматически зарегистрированы в СРО при отправке представителем Заказчика, Исполнитель проверяет корректность указанного типа обращения (заявки) и может обратиться к Заказчику с просьбой корректировки, предоставив обоснования в соответствии с настоящей классификацией (Таблица 1) - Таблица 1 - Типы обращений (заявок) Тип обращения (заявки) Описание Запрос на обслуживание Подготовка SQL запроса к СУБД для решения прикладной задачи и д р. – запрос на любое действие, не являющееся запросом информации и несовершенный на основе происшествия, прямо или косвенно влияющего на работу Системы Консультация (входит в тип обращения (заявки) «Запрос на обслуживание») «Где взять / куда обратиться...?», «Как сделать / выполнить…», «Как это работает…?» - запрос, имеющий своей целью получение информационной поддержки Инцидент Разбор ошибок/сбоев и подготовка материалов (корректировочных релизов, инструкций) для Заказчика для устранения ошибок/сбоев, которые приводят к частичному и полному нарушению работоспособности всех или отдельных функций ППО. Подготовка изменения и материалов, необходимых для проведения аварийно-восстановительных работ для возобновления работоспособности Системы. ЗНИ Подготовка изменений, связанных с изменением, улучшением/оптимизацией Системы и выводом новой модифицированной функциональности в штатном режиме. Подготовка изменений, связанных с модификацией существующих и/или реализация новых интеграционных механизмов для получения/обработки данных внешних систем. Подготовка изменений графического интерфейса по требованиям Заказчика - 3.2 Участники технической поддержки, осуществляющие сопровождение обращений (заявок) Техническая поддержка Системы должна быть организована на трех уровнях: 1. Первый и второй уровни технической поддержки организуется Заказчиком. 2. Третий уровень технической поддержки организуется Исполнителем. Зона ответственности каждого уровня технической поддержки указана в Таблице 2. Таблица 2 - Зона ответственности каждого уровня технической поддержки Участники технической поддержки Описание - Первый уровень технической поддержки (далее – 1-й уровень) Группа ответственных сотрудников 1-го уровня Заказчика, осуществляющая прием и первичную обработку обращений (заявок) (описание предмета обращения, первичная классификация и приоритизация, определение назначения, маршрутизация обращений (заявок) по назначению), руководствуется в своей работе настоящим Регламентом и БЗ, наполняемой 2-м уровнем поддержки, самостоятельно решает часть обращений (заявок), связанных с недостаточной квалификацией пользователей или настройками в рамках своей компетенции. В случае невозможности решения обращений (заявок) на 1-ом уровне ответственный сотрудник передает ее на 2-й уровень - Второй уровень технической поддержки (далее – 2-й уровень) Группа ответственных сотрудников 2-го уровня Заказчика по установленным компетенциям (информационная безопасность, сопровождение и эксплуатация информационно-аналитических систем, развитие информационно-аналитических систем, техническая поддержка информационно-аналитических систем) отвечает за поддержание работоспособности Системы, обработку обращений (заявок) и их решение в регламентные сроки в соответствии с установленными приоритетами. Осуществляет информационно-консультационную поддержку пользователей Системы в рамках своей компетенции. Оказывает экспертную помощь ответственным сотрудникам 1-го уровня в части формирования БЗ, содержащей ответы на часто задаваемые вопросы пользователей, с целью передачи знаний, навыков и инструментария на 1-й уровень для ускорения решения обращений (заявок). В случае невозможности решения обращения (заявки) на 2-ом уровне ответственный сотрудник передает его на 3-й уровень. При выявлении необходимости изменений в ППО Системы инициирует формирование обращения (заявки) и направляет его на группу ответственных сотрудников 3-го уровня по соответствующему классификатору (ЗНО, ЗНИ, и т.д.) - Третий уровень технической поддержки (далее – 3-й уровень) Группа ответственных сотрудников Исполнителя, отвечающая за устранение сбоев и аварий, проведение информационно-консультационной поддержки пользователей Системы, проведение адаптации и конфигурирования Системы в объемах действующих контрактов на оказание технической поддержки - 3.3 Перечень и описание статусов обращений (заявок) В Таблице 3 приведен перечень статусов обращений (заявок), действующий в СРО, и их описание. Таблица 3 - Перечень статусов обращений (заявок) и их описание Статус Описание Зарегистрирован Обращение (заявка) принято и зарегистрировано Направлен в группу Присваивается при назначении ответственными сотрудниками 1-го уровня группе ответственных сотрудников 2-го уровня по тематике обращения (заявки) после заполнения всей необходимой информации и полей обращения (заявки), а также при его передаче между группами 2-го уровня Передан в группу Присваивается при передаче обращения (заявки) ответственными сотрудниками 2-го уровня на группу ответственных сотрудников 3-го уровня Назначен Присваивается при назначении обращения (заявки) на ответственного сотрудника для его решения в рамках компетенции В работе Присваивается при приеме обращения (заявки) в работу ответственным сотрудником для его решения Решен Присваивается ответственным сотрудником, выполнившим работы по обращению (заявке) Закрыт Присваивается автоматически при решении запроса по обращению (заявке), а также отсутствии дополнительных запросов пользователя в соответствии с действующим SLA, или при подтверждении решения обращения (заявки) со стороны пользователя Запрос доп. информации Присваивается при необходимости запроса дополнительной информации и/или уточнения предмета обращения по обращению (заявке) у пользователя Ответ предоставлен Присваивается после ответа пользователем на запрос дополнительной информации Отклонен Присваивается, если обращение (заявка) не актуальна (по информации от пользователя), отсутствует техническая возможность решения обращения (заявки), предмет обращения не входит в компетенции технической поддержки, или существует влияние доработки на другие компоненты, что нарушает общий порядок работы Системы - Согласование Присваивается при необходимости согласования направления обращения (заявки) ответственным сотрудником Заказчика на 3-й уровень Анализ Присваивается при проведении анализа на предмет возможности внесения изменений, связанных с развитием/улучшением/оптимизацией Системы и выводом новой функциональности и оценке ресурсоемкости Тестирование Присваивается Исполнителем при завершении разработки и проведенном предварительном тестировании для последующего осуществления приемочного тестирования Специалистом 2-го уровня Релиз Присваивается ответственным сотрудником Заказчика при принятии решения о возможности вывода доработки в продуктивную среду Утверждение заказчиком Присваивается при согласовании группой профильных специалистов на 2-м уровне поддержки с пользователем технического задания для внесения изменений, связанных с развитием/улучшением/оптимизацией Системы и выводом новой функциональности Доработка Присваивается в случае несогласования Заказчиком работ, проведенных Исполнителем в рамках контрактных обязательств, по внесению изменений, связанных с развитием/улучшением/оптимизацией Системы и выводом новой функциональности в штатном режиме, и необходимости последующего направления Исполнителю для ее доработки Отложен Присваивается в случае невозможности выполнения запроса, изложенного в обращении (заявке), в связи с необходимостью запроса дополнительной информации у третьих сторон - 3.4 Порядок регистрации и сопровождения Заявок Порядок регистрации и сопровождения обращений (заявок) в рамках оказываемых услуг по технической поддержке Системы зависит от типа обращения (заявки): 1. Услуга по решению инцидентов, связанных с работой ППО – тип обращения (заявки) «Инцидент». 2. Услуга по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности – тип обращения (заявки) «Инцидент». 3. Услуга информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы – тип обращения (заявки) «Запрос на обслуживание» (в том числе, консультационный запрос). 4. Услуга адаптационного, конфигурационного и коррекционного сопровождения Системы (в рамках действующих программных модулей и функциональностей) – тип обращения (заявки) «Запрос на изменение». В случае недоступности СРО взаимодействие и информирование Исполнителем о ходе оказания услуги по обращению (заявке), изменению статусов обращений (заявок) осуществляется по согласованию с Заказчиком в соответствии с матрицей взаимодействия, представленной в Приложении 1 к настоящему Регламенту. - 3.4.1 Инцидент На рисунке 2 представлена функциональная схема регистрации и сопровождения обращений (заявок) типа «Инцидент». Рисунок 2 - Функциональная схема регистрации и сопровождения обращений (заявок) типа «Инцидент» 3.4.2 Запрос на обслуживание На рисунке 3 представлена функциональная схема регистрации и сопровождения обращения (заявки) типа «ЗНО». Рисунок 3 - Функциональная схема регистрации и сопровождения обращения (заявки) типа «ЗНО» 3.4.3 Запрос на изменение На рисунке 4 представлена функциональная схема регистрации и сопровождения обращений (заявок) типа «ЗНИ». Рисунок 4 - Функциональная схема регистрации и сопровождения обращений (заявок) типа «ЗНИ» - 3.5 Порядок классификации и приоритизации обращений (заявок) Классификация является начальной стадией процесса оказания технической поддержки, необходимой для идентификации обращения (заявки) и определения соответствующих действий для его обработки. Для проведения первичной классификации необходимо получить от пользователя и зафиксировать в описании обращения (заявки) подробные сведения о сути запроса, в том числе, для Инцидентов зафиксировать сценарий воспроизведения обнаруженной ошибки. Для проведения вторичной классификации необходимо провести анализ и диагностику для определения корневой причины и затронутой Инцидентом функциональной области (инфраструктура, сеть, ППО). В процессе классификации осуществляется первичная диагностика и оценка проблемы, описанной пользователем Системы в обращении (заявке), в части функционирования и/или удобства использования Системы. Корректная классификация позволяет увеличить скорость обработки обращения (заявки) и решения описанной в обращении (заявке) проблемы при минимальном привлечении ресурсов, в частности, за счет использования известных решений для типовых обращений (заявок), которые должны описываться в БЗ СРО. Классификация позволяет произвести первоначальное назначение обращения (заявки) на ответственного сотрудника и выставить приоритет с учетом приоритизации. Приоритизация применяется для определения критичности описанной в обращении (заявке) проблемы для функционирования ППО Системы. Приоритет рассмотрения обращения (заявки) определяется в процессе ее классификации на основании ряда параметров, вводимых при заполнении обращения (заявки). Приоритизация используется для того, чтобы при одновременном наличии нескольких обращений (заявок) в первую очередь рассматривалась обращения (заявки) с наивысшим приоритетом и не позднее установленных для данного приоритета сроков - Термины и сокращения В настоящем регламенте используются следующие термины и сокращения на русском и английском языках: Термины/сокращения Полное наименование/описание БЗ (База знаний) База данных Системы регистрации обращений (заявок), созданная для сбора, хранения и поиска способов решения известных проблем в рамках Системы Жизненный цикл обращения (заявки) Совокупность статусов, по которым проходит обращение (заявка), и правила перехода обращения (заявки) из одного статуса в другой Заказчик ФГБУ «СИЦ Минтранса России» – Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» ЗНИ Запрос на изменение – тип заявки, предполагающий внесение изменений в прикладное программное обеспечение Системы ЗНО Запрос на обслуживание – тип заявки, предполагающий работы по предоставлению консультации, предоставление доступа к Системе или стандартизированные типовые изменения конфигураций Системы Инцидент Тип заявки, классифицируемый как нештатное событие в работе компонентов функциональных задач Системы, которое привело или может привести к нарушению или снижению качества функционирования Системы ИС Информационная система Исполнитель Организация, которая определяется по результатам конкурсных процедур Классификация Анализ и заполнение классификационных полей справочными значениями, определяющими последовательность действий и этапов жизненного цикла заявки, а также порядок рассмотрения заявок Консультация Разъяснения по алгоритму работы, требуемых настроек прикладного программного обеспечения и технологии обработки данных при работе с Системой, предоставление информации Маршрутизация Определение процесса движения обращения (заявки) в Системе управления заявками между уровнями технической поддержки и организационными структурами на уровнях поддержки путем назначения обращения (заявки) в соответствии с его классификацией и выставленным приоритетом - Обращение (заявка) Устное или письменное обращение пользователя АСУ ТК с вопросом, касающимся работоспособности АСУ ТК, по одному из определённых каналов связи: электронная почта, Система регистрации обращений (заявок) Пользователь Инициатор обращения (заявки) или пользователь Системы ППО Прикладное программное обеспечение Предмет обращения Справочник, классифицирующий типовые запросы в Системе регистрации обращений (заявок), характерные для Системы, выбранное значение определяет маршрутизацию обращения (заявки) (группу ответственных сотрудников) Приоритизация Значение, определяющее время, очередность решения обращений (заявок), ресурсы, привлекаемые для решения обращений (заявок), . Приоритет устанавливается в соответствии с масштабом выявленной проблемы, которая привела или может привести к нарушению или снижению качества функционирования Системы Релиз Выпуск версии прикладного программного обеспечения Системы, от разработки до тестирования и планового обновления Системы на продуктивной среде для установки изменений, связанных с развитием/улучшением/оптимизацией Системы Система, АСУ ТК, Информационно-аналитическая система регулирования на транспорте Информационно-аналитическая система, предназначенная для автоматизации и информационно-аналитического обеспечения процессов управления развитием транспортного комплекса Российской Федерации, обеспечения публичности деятельности органов государственного управления транспортным комплексом, а также обеспечения процессов оказания государственных услуг в электронном виде в сфере транспорта СМЭВ Система межведомственного электронного взаимодействия СПО Системное программное обеспечение СРО Система регистрации обращений (заявок) Статус обращения (заявки) Текущее состояние обращения (заявки) в жизненном цикле процесса оказания технической поддержки Системы СУБД Система управления базами данных - Изменение приоритета уже зарегистрированного обращения (заявки) используется в случае появления новых обстоятельств, которые ведут к изменению влияния и/или срочности существующего обращения (заявки). При регистрации обращения (заявки) необходимо провести его приоритизацию. В процессе управления обращениями (заявками) каждому обращению (заявке) присваивается приоритет, принимающий одно из значений: Низкий, Средний, Высокий или Критический. В соответствии с приоритетом определяется время, очередность устранения, , ресурсы, привлекаемые для работ по обращению (заявке), а также может определяться порядок/процедура действий при работе с обращением (заявкой). Заказчиком в зависимости от уровня сбоя в работе Системы обращению (заявке) присваивается приоритет с указанием максимального времени реакции и решения в соответствии с требованиями, указанными в Приложении 2 к настоящему Регламенту - 4 Формы обращений (заявок) на оказание услуг по технической поддержке Системы, заполняемые в СРО 4.1. Форма обращения (заявки) на оказание услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы При подаче обращения (заявки) типа «ЗНО» в СРО указывается (Таблица 5): Таблица 5 – Описание атрибутов формы обращения (заявки) на оказание услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 5) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 5) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 5) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 5) Категория обращения: информационно-консультационная поддержка Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 5) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 5) Текст запроса на оказание услуги по информационно-консультационной поддержке сотрудников Заказчика Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 5) - На рисунке 5 приведена форма обращения (заявки) типа «ЗНО» в СРО. Рисунок 5 - Форма обращения (заявки) типа «ЗНО» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы, заполненную в свободной форме.

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

ОПРЕДЕЛЕНИЯ, ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ - Автоматизированная система (АС) Система, состоящая из комплекса средств автоматизации, реализующего информационную технологию выполнения установленных функций, и персонала, обеспечивающего его функционирование (ГОСТ Р 59853-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения») АРМ Автоматизированное рабочее место АСУ ТК, Система Информационно-аналитическая система регулирования на транспорте АТС Автоматическая телефонная станция БД База данных ГИС Государственная информационная система ГОСТ Государственный стандарт ГЦОД СИЦ Минтранса России, ГЦОД Головной центр обработки данных ФГБУ «СИЦ Минтранса России» Дашборд Интерактивная аналитическая панель, графический интерфейс. ЕИС Единая информационная система в сфере закупок ЕСИА Единая система идентификации и аутентификации Заказчик Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» КИИ Критическая информационная инфраструктура Кластер Кла?стер (англ. cluster) – объединение нескольких однородных элементов, которое может рассматриваться как самостоятельная единица, обладающая определёнными свойствами Компонент Часть АС, выделенная по определенному признаку или совокупности признаков и рассматриваемая как единое целое (ГОСТ Р 59853-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения») Контракт Контракт на выполнение работ по развитию и оказанию услуг по технической поддержке Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК в 2026 году, заключаемый по результатам проведения конкурентной процедуры закупки в соответствии с требованиями Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» - - Значение характеристики не может изменяться участником закупки

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

ФГБУ «СИЦ Минтранса России» Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации», Заказчик Федеральный закон № 44-ФЗ Федеральный закон от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» ФЗ Функциональная задача ФЗ «Реестр объектов» Функциональная задача «Формирование и ведение единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации» ФСБ России Федеральная служба безопасности Российской Федерации ФСТЭК России Федеральная служба по техническому и экспортному контролю ЧС Чрезвычайная ситуация ЭВМ Электронно-вычислительная машина API От англ. Application Programming Interface – интерфейс прикладного программирования – совокупность инструментов и функций в виде интерфейса для взаимодействия с программой CSS От англ. Cascading Style Sheets — каскадные таблицы стилей FPS От англ. frame per second - количество кадров в секунду HTML От англ. HyperText Markup Language - стандартный язык разметки документов, создающий основу и структуру всех веб-страниц JSON От англ. JavaScript Object Notation – текстовый формат обмена данными, основанный на JavaScript WebAssembly (Wasm) Открытый стандарт, представляющий собой низкоуровневый бинарный формат инструкций, который позволяет выполнять код, написанный на языках C++, Rust или Go, в браузерах с производительностью, близкой к нативной

1. ОБЩИЕ СВЕДЕНИЯ - 1.6. Перечень документов, требования которых должны быть учтены при выполнении работ – Федеральный закон Российской Федерации от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации»; – Федеральный закон Российской Федерации от 27.07.2006 № 152-ФЗ «О персональных данных»; – Федеральный закон Российской Федерации от 06.04.2011 № 63-ФЗ «Об электронной подписи»; – Федеральный закон Российской Федерации от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации»; – Указ Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации»; – Указ Президента Российской Федерации от 01.05.2022 № 250 «О дополнительных мерах по обеспечению информационной безопасности Российской Федерации»; – Указ Президента Российской Федерации от 31.03.2010 № 403 «О создании комплексной системы обеспечения безопасности населения на транспорте»; – постановление Правительства Российской Федерации от 30.07.2004 № 395 «Об утверждении Положения о Министерстве транспорта Российской Федерации»; – постановление Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации»; – постановление Правительства Российской Федерации от 16.11.2015 № 1236 «Об установлении запрета на допуск программного обеспечения, происходящего из иностранных государств, для целей осуществления закупок для обеспечения государственных и муниципальных нужд»; – постановление Правительства Российской Федерации от 23.12.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 Федерального закона «Об электронной подписи»;

– постановление Правительства Российской Федерации от 08.06.2011 № 451 «Об инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг и исполнения государственных и муниципальных функций в электронной форме»; – постановление Правительства Российской Федерации от 30.01.2013 № 62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин»; – приказ ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации»; – приказ ФСТЭК России от 11.04.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений»; – приказ ФСБ России от 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.7. Сроки начала и окончания работ Начало работ: с даты заключения Контракта. Окончание работ: не позднее 15.12.2026. Работы выполняются в соответствии с этапами. Сроки выполнения этапов работ по развитию и технической поддержке Модуля СЦ определяются Календарным планом. Календарный план, приведен в разделе 5 настоящего ТЗ

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

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

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

1.1. Наименование Системы Полное наименование системы: Информационно-аналитическая система регулирования на транспорте. Условное обозначение системы: АСУ ТК. Полное наименование модуля: Модуль сбора, ведения и анализа информации о нештатных ситуациях на транспорте. Условное обозначение модуля: Модуль СЦ. Модуль СЦ создан в рамках контракта от 05.08.2024 № ОК/24_04 на выполнение работ по развитию АСУ ТК в части создания модуля «Сбора, ведения и анализа информации о нештатных ситуациях на транспорте». Развитие Модуля СЦ осуществлено в рамках контракта от 19.05.2025 № ОК/25_09 на выполнение работ по развитию Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК

1.2. Шифр темы или номер контракта Присваивается Заказчиком по результатам организации закупочных процедур. 1.2.1. Предмет контракта Выполнение работ по развитию Модуля СЦ. Код по ОКПД2: 62.01.11.000 – услуги по проектированию и разработке информационных технологий для прикладных задач и тестированию программного обеспечения. Оказание услуг по технической поддержке Модуля СЦ. Код по ОКПД2: 62.02.30.000 – услуги по технической поддержке информационных технологий. Выполнение работ по развитию Модуля СЦ предусмотрено с учетом ключевых результатов (ОКР) Ведомственной программы цифровой трансформации Минтранса России на 2026-2028 (далее - ВПЦТ Минтранса России) в составе мероприятия № 103.002 «АСУ ТК» ИТ расхода 103.26.000005 «Развитие Информационно-аналитической системы регулирования на транспорте (АСУ ТК)»: · «Обеспечено информационное взаимодействие с Минобороны о происшествиях на транспортных объектах»; · «Обеспечена автоматизация формирования отчетов о нештатных ситуациях на транспорте, в том числе по данным внешних систем». Выполнение работ по технической поддержке АСУ ТК предусмотрено ВПЦТ Минтранса России в составе мероприятия № 103.002 «АСУ ТК» ИТ расхода 103.26.000021 «Эксплуатация Информационно-аналитической системы регулирования на транспорте (АСУ ТК)»

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

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

1.5. Основания для выполнения работ Работы осуществляются на основании следующих документов: – постановление Правительства Российской Федерации от 30.12.2003 № 794 «О единой государственной системе предупреждения и ликвидации чрезвычайных ситуаций»; – постановление Правительства Российской Федерации от 08.11.2013 № 1007 «О силах и средствах единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций»; – распоряжение Правительства Российской Федерации от 27.11.2021 № 3363-р «О Транспортной стратегии Российской Федерации до 2030 года с прогнозом на период до 2035 года»; – Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 26.08.2025 №ЕФ-3; – Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 27.11.2025 №ЕФ-23;

– Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 19.02.2026 №ЕФ-1; – План мероприятий по профилактике случаев непроизводственного травматизма граждан на железнодорожном транспорте, являющийся приложением к постановлению коллегии Министерства транспорта Российской Федерации от 11.03.2026 № 2

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

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

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

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

3. ХАРАКТЕРИСТИКА ОБЪЕКТА АВТОМАТИЗАЦИИ - 3 Информирование – ведение справочника способов оповещения (веб-интерфейс, мессенджер); – формирование сценария выполнения оповещения (настройка условий, способа, параметров оповещения); – выполнение оповещений пользователей 4 Отчетность – формирование отчета и справки о событиях; – фильтрация событий для выгрузки в справку о событиях или в отчет о событиях 5 Администрирование – ведение ролей пользователей; – ведение учетных данных пользователей; – ведение справочника организаций; – ведение справочника групп системы мгновенного обмена сообщениями; – выполнение исходящего звонка на контактный телефонный номер организации; – формирование матрицы эскалации событий Архитектура Модуля СЦ представлена на рисунке 1. Рисунок 1. Архитектура Модуля СЦ - - Значение характеристики не может изменяться участником закупки

3.3. Состав используемого ПО Модуля СЦ Программная архитектура Модуля СЦ разработана как трехуровневая клиент-серверная архитектура. Архитектура включает в себя следующие уровни: • уровень представления – презентационный уровень, обеспечивающий взаимодействие с пользователя с клиентскими приложениями с использованием веб-браузера («тонкий» клиент); • уровень приложений – реализован в виде сервисов, обеспечивает обработку запросов, поступающих от клиентских приложений, формирование ответов на запрос в доступном пользователю виде (формирование пользовательских интерфейсов); • уровень хранения данных – реализуется как сервер БД и обеспечивает хранение и целостность хранимых данных, создание резервных копий, ведение журнала транзакций, восстановление данных после сбоев. Программная архитектура Модуля СЦ включает в себя сервисы и интерфейсы, указанные в Таблице 3. Таблица 3. Программная архитектура Модуля СЦ Программный сервис/интерфейс Технологии реализации Уровень представления Интерфейс пользователя и администратора (front-end) Javascript Уровень приложений Сервис (GateWay) Kotlin Сервис геокодирования (geocoding-service) Kotlin Сервис уведомлений (notifiсation-service) Kotlin Сервис работы с файлами (file-service) Kotlin Сервис отчетности (report-service) Kotlin Сервис управления событиями (event-service) Kotlin Сервис информирования через мессенджер (messenger-notifier) Python Сервис внешних интеграций (integration-service) Сбор информации из внешних систем и сервисов Брокер сообщений Kafka Уровень хранения данных Файловое хранилище MinIO S3 СУБД Postgres Pro Enterprise

3.4. Информационное взаимодействие программных сервисов и интерфейсов Модуля СЦ Объект автоматизации функционирует в распределенной информационной среде. Обмен данными осуществляется по защищенным каналам связи (в том числе ведомственным сетям передачи данных). Источники информации включают: · внешние автоматизированные системы (органов государственной власти); · внутренние базы данных (реестры объектов транспортной инфраструктуры, паспорта регионов и пр.); · оперативная информация от персонала, поступающая через автоматизированные рабочие места (АРМ) и мобильные устройства. 3.4.1. Взаимодействие Модуля СЦ со смежными подсистемами АСУ ТК Модуль СЦ входит в состав АСУ ТК и взаимодействует со следующими ее функциональными задачами и подсистемами: · Функциональной задачей «Формирование и ведение единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации» (ФЗ «Реестр объектов»); · Геоинформационной подсистемой АСУ ТК (П-ГИС); · Подсистемой ведения нормативно-справочной информации и метаданных (П-НСИ); · Подсистемой сбора данных и централизованное хранилище данных (П-СД); · Подсистемой информационного взаимодействия (П-ИВ). 3.4.2. Взаимодействие с внешними информационными системами Список внешних информационных систем, с которыми осуществляется взаимодействие Модуля СЦ: · ЕСИА; · мессенджер; · Яндекс Геокодер; · Информационная система «Централизованная система сбора информации систем-112»; · ПВК «Поиск-Море», АИС РПТ; · облачная АТС

3.1. Описание объекта автоматизации АСУ ТК Объектом автоматизации являются процессы основной и обеспечивающей деятельности, направленные на управление транспортным комплексом, в том числе, процессы информационного взаимодействия с другими организациями и субъектами транспортного комплекса. АСУ ТК относится к государственным информационным системам, а также к информационным системам персональных данных и значимым объектам критической информационной инфраструктуры Российской Федерации. АСУ ТК соответствует требованиям, предъявляемым к: – ГИС второго класса защищенности в соответствии с приказом ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах»; – ИС персональных данных при обеспечении третьего уровня защищенности персональных данных в соответствии с требованиями постановления Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»; – значимым объектам КИИ Российской Федерации второй категории значимости с постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении Правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений». Модуль СЦ является подсистемой АСУ ТК. Перечень платформенных решений и функциональных задач АСУ ТК представлен в Таблице 1

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

8 Подсистема проектного архива АСУ ТК Подсистема проектного архива АСУ ТК предназначена для автоматизации деловых процессов должностных лиц Министерства транспорта Российской Федерации, подведомственных агентств и службы, в том числе, и процессов информационного взаимодействия внутреннего и внешнего характера 9 ФЗ «Реестр объектов» Функциональная задача предназначена для формирования и ведения единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации 10 ФЗ «СТП» Функциональная задача предназначена для организации информационно-аналитической поддержки процессов территориального планирования Российской Федерации в области федерального транспорта 11 ФЗ «МРТБ ПП» Функциональная задача предназначена для формирования и ведения межрегионального транспортного баланса пассажирских перевозок в дальнем (межрегиональном) сообщении 12 ФЗ «МДД» Функциональная задача предназначена для осуществления мониторинга дорожного движения 13 ФЗ «ТПР» Функциональная задача предназначена для формирования и ведения транспортного паспорта региона 14 ФЗ «Данные по грузообороту» Функциональная задача предназначена для обеспечения подсистем и пользователей АСУ ТК данными по грузообороту между Российской Федерацией и зарубежными странами 15 ФЗ «МЖТ» Функциональная задача предназначена для осуществления мониторинга железнодорожного транспорта 16 ФЗ «МГМП» Функциональная задача предназначена для осуществления мониторинга грузопотоков в морских портах с целью формирования единой цифровой среды мониторинга и планирования перевозок в/из портов Дальнего Востока

17 Модуль ГЭТ Модуль предназначен для получения, хранения данных инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по отдельно взятому предприятию-перевозчику. Формирования отчетов об инвентаризации с детальными данными по каждому разделу инвентаризации с маршрутизацией в муниципалитет / регион / Минтранс. Содержит агрегированные данные инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по всем перевозчикам, относящихся к данному муниципалитету. Формирует сводный отчет по муниципалитету по каждому разделу инвентаризации с маршрутизацией в регион / Минтранс. Формирует агрегированные данные инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по всем перевозчикам, относящиеся к данному региону и по всем муниципалитетам, относящимся к данному региону. Аналитические и статистические данные о состоянии ГЭТ региона. Содержит данные о видах транспорта, цифровых транспортных сервисах и платежных инструментах Региона. Формирует сводный отчет по каждому разделу инвентаризации с маршрутизацией в Минтранс. Формирует агрегированную статистику и аналитику по всем регионам страны в разрезе транспортных средств, маршрутов, пассажиропотоков, инфраструктуры ГЭТ. Данные о рейтинге регионов и перевозчиков на основании выбранных параметров, документооборот с участниками Системы: получение подписанных печатных форм, их утверждение, возврат на доработку. 18 Модуль iМинтранс Модуль создан для отчета по ключевым показателям транспортного комплекса России (Отраслевые и статистические показатели, исполнение бюджета, исполнение поручений, аналитика СМИ, происшествия по видам транспорта). 19 Модуль СЦ Модуль СЦ предназначен для оперативного мониторинга нештатных ситуаций транспортной отрасли, оповещения заинтересованных лиц и структур и предоставления данных о нештатных ситуациях

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

АСУ ТК осуществляет идентификацию и авторизацию посредством Единой системы идентификации и аутентификации (ЕСИА). Информационный обмен с внешними информационными системами осуществляется посредством СМЭВ 3 и СМЭВ 4. АСУ ТК развернута на вычислительных мощностях ГЦОД СИЦ Минтранса России

3.2. Описание и текущее состояние объекта автоматизации Модуля СЦ Объектом автоматизации является процесс организации мониторинга информации о НС и ЧС на транспорте. Предметом деятельности Учреждения являются следующие функции: – информационное обеспечение в области транспортной безопасности, защиты населения и территорий от чрезвычайных ситуаций природного и техногенного характера в транспортном комплексе; – подготовка справочных материалов при угрозе возникновения и возникновении чрезвычайных ситуаций и иных происшествий в транспортном комплексе; – взаимодействие и обмен оперативной информацией с органами управления Единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций; – организация оперативного мониторинга обстановки на объектах транспорта при угрозе и возникновении чрезвычайных ситуаций и иных происшествий. Перечень компонентов Модуля СЦ и выполняемые ими функции представлены в Таблице 2

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

4. ТРЕБОВАНИЯ К МОДУЛЮ СЦ - 4.1. Требования к структуре Модуля СЦ В процессе работ по развитию Системы должны сохраниться основные требования к построению архитектуры Системы в соответствии с принципами трехуровневой архитектуры: 1. уровень хранения данных или уровень базы данных (сервер СУБД); 2. уровень сервера приложений (сервер аналитической обработки); 3. презентационный уровень, обеспечивающий взаимодействие с клиентскими приложениями. В состав Системы должны входить следующие основные компоненты: 4. сервер баз данных; 5. сервер приложений; 6. веб-сервер. Сервер баз данных должен обеспечивать хранение и целостность хранимых данных, создание резервных копий, ведение журнала транзакций, восстановление данных после сбоев. Сервер приложений должен обеспечивать обработку запросов, поступающих от клиентских приложений (через веб-сервер), формирование ответов на запрос в доступном пользователю виде (формирование пользовательских интерфейсов). Веб-сервер должен обеспечивать взаимодействие с оператором и внешними системами по HTTP / HTTPS протоколу в режиме «запрос-ответ» (получения запросов от пользователя и передачи ответа в виде соответствующей информации, обработанной серверами приложений). Взаимодействие Системы с пользователем должно отвечать требованиям модели «тонкого клиента» (т.е. представлять на стороне клиента (пользователя) лишь графический пользовательский интерфейс). Все составляющие Системы должны использовать единую методологию и отвечать единым принципам взаимодействия, надежности и управления. Перечень компонентов Модуля СЦ представлен в Таблице 4. Таблица 4. Перечень компонентов Модуля СЦ, в отношении которых выполняются работы по развитию № п.п. Наименование компонента Модуля СЦ Раздел ТЗ 1 Компонент регистрации событий 4.2.1. 2 Компонент отчетности 4.2.2 3 Компонент визуализации 4.2.3 4 «Интерактивная карта» (компонент создается) 4.2.4 5 Компонент администрирования 4.2.5 - - Значение характеристики не может изменяться участником закупки

4.2. Требования к дорабатываемым функциям модуля СЦ 4.2.1. Развитие компонента регистрации событий (1 очередь) Должны быть выполнены следующие доработки: – обеспечение логирования действий пользователя, связанных с карточкой события; – доработка объектной модели в части создания новых типов сущностей (карточек) с учетом реализуемых интеграций с информационными ресурсами (силы и средства предупреждения и ликвидации ЧС и нештатных ситуаций на транспорте, ТС, ограничения воздушного пространства, неблагоприятные и опасные природные явления); – реализация механизма установления связи между сущностями в Модуле СЦ автоматизированным и ручным способами (события, природные явления, силы и средства предупреждения и ликвидации ЧС и нештатных ситуаций на транспорте, ограничения воздушного пространства, ОТИ, ТС и др.); – отображение в карточке установленных связей между сущностями.

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

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

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

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

4.2.2. Развитие компонента отчетности (3 очередь) Должна быть обеспечена автоматизация процессов формирования отчетов о ЧС и нештатных ситуациях на транспорте, в т.ч. на основе данных из внешних систем. Включает следующие доработки: – разработка шаблонов отчетов в различных форматах (табличный, текстовый); – реализация выбора фотоматериалов для включения в справку; – форматирование содержимого справок с учетом правил русского языка в отношении окончаний слов (в зависимости от падежа, склонения, числа и рода); – автоматизированное формирование выводов к содержимому справки на основе настраиваемых критериев; – создание интерфейса выбора параметров (фильтрации) для формирования отчетов: o состав полей для включения в отчёт; o настройка диапазонов значений характеристик и дат; o порядок отображения полей; o настройка заголовка. – реализация способа подготовки отчётов в асинхронном режиме (очереди); – реализация интерфейса компонента формирования отчетности для отображения очереди формирования отчетов и статусов их подготовки; – экспорт отчётов в форматы xlsx, csv и справок в форматы pdf, docx. Необходимо разработать не менее 10 шаблонов отчетов и/или справок. Перечень, структура и содержание шаблонов должны быть согласованы с Заказчиком на этапе технического проектирования.

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

– отображение на карте связанных сущностей и ОТИ; – реализация функции выбора темного и светлого стилей отображения элементов интерфейса, карточек сущностей, картографической основы и объектов, отображаемых на карте; – реализация механизма для выбора картографической основы в одном из распространенных форматов WMTS, TMS, MVT и др. Должна быть предусмотрена возможность настройки перечня картографических основ и параметров доступа к ним; – настройка базового набора дашбордов, содержащих преднастроенные виджеты о количестве событий в разрезе видов транспорта с возможностью перехода к исходным данным (карточкам событий, ОТИ и т.д.), с фильтрацией по параметрам. Параметры фильтрации должны быть определены на этапе технического проектирования. Должно быть обеспечено автоматическое и принудительное обновление данных, отображаемых на дашбордах

4.2.4.1. Требования к технической реализации компонента «Интерактивная карта» При реализации компонента «Интерактивная карта» должны учитываться требования, указанные ниже. 4.2.4.1.1. Требования к отображению элементов Повторяющихся элементы карты (ТС, ОТИ, события и пр.) должны отрисовываться с использованием аппаратного создания экземпляров объектов на пользовательском устройстве (WebGL/WebGPU)). Отрисовка каждого объекта отдельным запросом не допускается, должна обеспечиваться возможность одновременного отображения не менее 5 000 объектов без снижения производительности (30 кадров в секунду на тестовой конфигурации). 4.2.4.1.2. Уровни детализации объектов Для управления отображением сложных объектов должно быть создано не менее 3-х уровней детализации, отображаемых при изменении масштаба с возможностью автоматического переключения между уровнями. Все отображаемые объекты должны масштабироваться с учетом разрешения экрана пользователя с сохранением качества детализации. 4.2.4.1.3. Полигональная оптимизация и текстурирование При реализации компонента «Интерактивная карта» должна обеспечиваться технология рельефного тестурирования объектов. Не должны использоваться высокополигональные трехмерные модели. Все повторяющиеся элементы должны генерироваться единоразово и повторно использоваться при последующих отображениях. 4.2.4.1.4. Управление памятью Требуется реализовать потоковую загрузку на устройство пользователя элементов карты и текстур. Загрузка данных целиком при старте приложения не допускается. Необходимо реализовать механизм очистки памяти от элементов, которые находятся вне области видимости камеры в течение заданного времени. 4.2.4.1.5. Требования к взаимодействию пользователя с интерфейсом компонента «Интерактивная карта» Программная реализация механизмов управление камерой (масштабирование и навигация) должна быть выполнена с поддержкой технологии WebAssembly (WASM). Элементы управления должны являться неотъемлемой частью интерактивной карты.

4.2.5. Развитие компонента администрирования (3 очередь) Должна быть выполнена доработка ролевой модели. Ролевая модель должна обеспечивать управление доступом к отдельным объектам Модуля СЦ и их элементам (атрибутам) с разграничением по видам транспорта, регионам и пр., в частности: – определение набора конкретных действий, доступных пользователям (выполняемых над объектом доступа, например, удаление записи, редактирование записи, формирование отчета и др.); – реализация возможности объединения пользователей в группы; – определение прав доступа для групп пользователей; – реализация интерфейса визуальной настройки прав доступа пользователей к объектам Модуля СЦ

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

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

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

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

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

4.4.7.1. Требования к инструментам разработки и процессу контроля версий программного обеспечения 4.4.7.1.1. Система контроля версий Для управления исходным кодом должна использоваться система контроля версий кода, развернутая в инфраструктуре Заказчика. 4.4.7.1.2. Правила именования веток Имя ветки должно соответствовать следующему формату: / / Категории веток: ? feature/ — разработка новой функциональности, а также рефакторинг или удаление существующей; ? fix/ — исправление ошибок; ? hotfix/ — срочные исправления, применяемые в обход стандартного процесса разработки; ? test/ — для проведения экспериментов, не влияющих на основную разработку. Идентификатор задачи: после категории указывается ссылка на задачу (issue) в системе контроля версий кода. Описание: добавляется краткое описание решаемой задачи в формате kebab-case (слова разделяются дефисами, например, add-user-auth). Примеры именования веток: ? feature/#123/add-payment-integration; ? fix/#45/correct-calculation-logic; ? hotfix/#67/urgent-database-connection-patch. 4.4.7.1.3. Правила именования коммитов Сообщение коммита должно соответствовать соглашению Conventional Commits и состоять из категории и описания: : ? fix — исправление ошибки. Примеры сообщений коммитов: ? feat: добавление формы регистрации пользователя; ? fix: исправление ошибки валидации email-адреса; ? refactor: оптимизация алгоритма сортировки данных; ? chore: обновление версий в файле dependencies. 4.4.7.1.4. Модель ветвления В процессе разработки используются следующие основные ветви: ? main / master — стабильная ветка, содержит только код, прошедший полное тестирование и развернутый в продуктивных контурах; ? dev — ветка для интеграции завершенных задач, предназначенная для сборки и тестирования в тестовых средах. Попадание кода в main осуществляется только через Merge Request (MR) из dev

4.2.4. Создание компонента «Интерактивная карта» (2 очередь) В составе создаваемого компонента должны отображаться данные, доступные в компоненте визуализации. Требования к интерфейсу интерактивной карты: – интерактивная карта должна быть представлена в виде объемной карты с учетом макетов, представленных в Приложении А к ТЗ; – интерфейс должен корректно отображаться на экранах мониторов (разрешение Full HD 1920?1080), телевизоров (разрешение 4К 3840?2160), жидкокристаллических панелей для видеостены, используемой Заказчиком, с параметрами каждой панели: диагональ 55 дюймов, разрешение 1920x1080; – интерфейс должен корректно отображаться на планшетных устройствах с диагональю экрана 10-12 дюймов, конкретные требования должны быть уточнены на этапе технического проектирования; – должна быть обеспечена кластеризация и генерализация отображения объектов на карте при изменении масштаба; – должно быть обеспечено отображение основных характеристик объектов при выборе их на карте; – должно быть обеспечено управление отображением слоев на карте; – должна быть обеспечена настройка цветовой индикации отображаемых объектов транспортной инфраструктуры; – должно быть обеспечено отображение легенды карты, содержащей отображаемые объекты на карте; – должна быть обеспечена возможность одновременного отображения не менее 5 000 ОТИ и ТС на карте.

На интерактивной карте должны быть отображены подвижные объекты совместно с объектами транспортной инфраструктуры (ОТИ), включая следующие возможности: § отображение местоположения транспортных средств (воздушный, водный и автомобильный транспорт) на карте в режиме реального времени (с заданным периодом обновления данных); § отображение маршрутов движения всех ТС за выбранный период времени, в том числе с использованием эффектов анимации; § отображение маршрутов движения ТС, связанных с карточкой события: ТС, являющихся участниками события, и ТС, находящиеся в заданном радиусе от события; § управление отображением сущностей и ОТИ на карте, включая настройку состава отображаемых объектов, поиск, фильтрацию, с использованием соответствующей панели управления и наглядным представлением результатов; § автоматическое изменение вида отображения объектов (цветовая индикация) по заданным условиям (например, при достижении критических значений параметров, характеризующих функционирование объекта); Должна обеспечиваться производительность обновления изображения на экране в 30 кадров в секунду на тестовой конфигурации пользовательского устройства (модель Бештау AIO2402/B560, входящая в Реестр российской промышленной продукции под номером 10394100 или аналог) при одновременном отображении не менее 5 000 объектов и 200 уникальных моделей объектов. Макеты интерфейсов Модуля СЦ должны быть предварительно согласованы с Заказчиком и разработаны с учетом требований ГОСТ Р ИСО 9241-161-2016 «Элементы графического пользовательского интерфейса»

4.2.6. Взаимосвязи с внешними автоматизированными системами (1 очередь) Способы взаимодействия с внешними информационными системами должны быть определены на этапе технического проектирования. Должны быть выполнены следующие доработки: – интеграции с информационными ресурсами в целях получения данных о движении подвижных ТС (воздушные суда, суда водного транспорта); – интеграция с информационным ресурсом в целях получения данных о событиях на железнодорожном транспорте. Реализация интеграций должна включать проектирование и реализацию интеграционных механизмов обмена данными с учетом доступных вариантов реализации, обеспечение защищенных способов взаимодействия, настройку отображения отдельных данных на карте (настройка слоев). Взаимодействия, имеющие каналы связи, выходящие за пределы контролируемой зоны взаимодействующих систем, считаются защищенными, если для их защиты используются программные и/или программно-аппаратные шифровальные (криптографические) средства, сертифицированные ФСБ России (далее – СКЗИ). Выбор СКЗИ, схемы подключения и требуемого класса криптостойкости должен производиться в соответствии с Техническими условиями на подключение к информационным ресурсам ФГБУ «СИЦ Минтранса России» и инструкциями по подключению пользователей к ресурсам инфраструктуры Головного центра обработки данных, утвержденных приказом директора ФБГУ «СИЦ Минтранса России» от 24.05.2024 № 21-ОД

4.3. Требования к оказанию услуг по технической поддержке Модуля СЦ 4.3.1. Общие требования к оказанию Услуг Техническая поддержка Модуля СЦ должна осуществляться с учетом требований постановления Правительства Российской Федерации от 06.07.2015 N 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации». Подрядчик обязан выполнять требования законодательства в сфере защиты информации, требования по защите информации, информационной безопасности, указанные в локальных нормативных актах ФГБУ «СИЦ Минтранса России», регламентирующих условия информационного взаимодействия, защиты информации и подключения к информационным ресурсам ФГБУ «СИЦ Минтранса России», участвующих в информационном взаимодействии в рамках оказания услуг по технической поддержке АСУ ТК в 2026 году

4.3.1.1. Требования к составу и содержанию услуг третьего уровня технической поддержки Оказание услуг по технической поддержке Системы осуществляется в рамках этапов в соответствии с календарным планом. Подрядчик в течение 5 рабочих дней с даты заключения Контракта должен предоставить со своей стороны, а Заказчик со своей стороны Матрицу ответственных за взаимодействия в соответствии с Приложением 1 к Регламенту оказания услуг по третьему уровню технической поддержки Модуля СЦ (далее – Регламент, Приложение В). Подрядчик в течение 10 рабочих дней с даты заключения Контракта должен провести мероприятия по организации третьего уровня технической поддержки в соответствии с Регламентом. Услуги по третьему уровню технической поддержки Модуля СЦ должны включать: – организацию Подрядчиком третьего уровня технической поддержки; – информационно-консультационную поддержку работников Заказчика; – решение инцидентов, связанных с работой ППО; – адаптационное, конфигурационное и коррекционное сопровождение Модуля СЦ (в рамках действующих программных модулей и функциональности); – устранение уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности

4.3.4. Требования к документированию результатов оказываемых услуг Для обеспечения контроля оказываемых услуг по поддержке Модуля СЦ со стороны Заказчика, по окончании каждого отчетного периода по контракту в соответствии с календарным планом, Подрядчик обязан предоставить Заказчику Отчет об оказанных услугах. Отчет должен содержать детальную информацию об оказанных услугах с указанием даты выполненных мероприятий и приложением обосновывающих документов (заявок, запросов, требований) или ссылкой на такие документы, если они содержатся в Модуле СЦ. Информация о выполненных мероприятиях по заявкам должна быть сформирована на основании соответствующих записей СРО по каждому этапу исполнения Контракта. В случае оказания услуги адаптационного, конфигурационного и коррекционного сопровождения Модуля СЦ, должны быть предоставлены документы, подтверждающие выполнение требований п. 29.3 приказа ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации». Фактическое время реагирования и время решения по всем обращениям, поступившим в СРО, формируется в СРО по итогам отчетного периода в разделе «Отчеты». Фактическое время реагирования и время решения по обращениям учитывает суммарное время, затраченное на реагирование и, соответственно, на работу по обращению с момента назначения обращения специалисту Подрядчика или группе исполнителей, ответственным за оказание услуг технической поддержки 3 уровня от начала до завершения работ Подрядчиком. При этом принимается суммарное время нахождения заявки в соответствующих статусах заявки СРО на стороне Подрядчика

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

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

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

4.3.6.4. Требования к услугам адаптационного, конфигурационного и коррекционного сопровождения и доработки Модуля СЦ (в рамках действующих программных модулей и функциональностей) Услуги адаптационного, конфигурационного и коррекционного сопровождения и доработки Модуля СЦ включают: – управление изменениями и адаптация функций Модуля СЦ; – изменение настроек функционирования Модуля СЦ; – внесение изменений и/или модификаций Модуля СЦ (в рамках действующих программных модулей и функциональностей), направленных на улучшение их работоспособности и функциональных возможностей; – подготовка и передача Заказчику SQL запросов в СУБД для получения агрегированной информации из Модуля СЦ, которую невозможно получить с использованием графического пользовательского интерфейса; – адаптация модулей интеграций со смежными информационными системами

4.4.7.1.5. Требования к используемым зависимостям (библиотекам) Все внешние зависимости проекта должны быть зафиксированы с указанием точных версий. Для контроля версий зависимостей в репозиторий обязательно должны быть включены следующие файлы: · Для JavaScript: package-lock.json или yarn.lock; · Для Python: requirements.txt (с зафиксированными версиями) или Pipfile.lock; · Для Go: go.mod и go.sum; Загрузка всех зависимостей должна производиться исключительно через внутренний прокси-репозиторий Заказчика, настроенный в соответствующем системе менеджере пакетов. Запрещается: · Использование плавающих версий (например, ^1.2.3, ~4.5.0, latest); · Использование библиотек, содержащих критические уязвимости, в том числе зарегистрированные в реестре CVE (Common Vulnerabilities and Exposures). 4.4.7.1.6. Требования к процессу непрерывной интеграции (CI) Сборка программного обеспечения, включая этапы компиляции, тестирования и анализа кода, должна выполняться исключительно в инфраструктуре непрерывной интеграции Заказчика. 4.4.7.1.7. Требования к хранению артефактов сборки Все артефакты сборки (результирующие пакеты, Docker-образы и т.д.) подлежат обязательному хранению в предназначенной для этого инфраструктуре Заказчика (артефакторий). Запрещается размещение финальных артефактов сборки на сторонних ресурсах

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

4.5. Общие технические требования 4.5.1. Требования к численности и квалификации персонала и пользователей Модуля СЦ Программное обеспечение Модуля СЦ не должно требовать изменения штатной численности персонала Заказчика. Программное обеспечение Модуля СЦ не должно требовать наличия у пользователей дополнительной квалификации в сфере информационных технологий, кроме базовых знаний в обращении с персональным компьютером, базовых навыков работы в интернет-обозревателях и знаний о Модуле СЦ в объеме документов Руководство пользователя, Руководство администратора

4.3.1.2. Требования к общему порядку оказания услуг Техническая поддержка Модуля СЦ должна быть организована на трех уровнях: – первый и второй уровни технической поддержки организуется Заказчиком; – третий уровень технической поддержки организуется Подрядчиком. Перечень действий на каждом уровне технической поддержки указан в Таблице 5: Таблица 5 – Перечень действий на каждом уровне технической поддержки Уровень технической поддержки Доступные действия Условия передачи задачи на следующий уровень Первый уровень технической поддержки (далее – 1-й уровень) – принимает обращения (заявки) пользователей Модуля СЦ и работников Заказчика; – регистрирует обращения в Модуле СЦ регистрации обращений; – присваивает уникальный идентификационный номер, классифицирует обращения; – самостоятельно решает обращения, которые связаны с недостаточной квалификацией пользователей или настройками в рамках своей компетенции; – взаимодействует с пользователями Модуля СЦ при решении проблемы Передает обращение на второй уровень поддержки в случае невозможности решения на своем уровне Второй уровень технической поддержки (далее – 2-й уровень) – принимает обращения от 1-го уровня; – уточняет классификацию обращения в результате дополнительного анализа; – самостоятельно решает обращения в рамках своей компетенции; – осуществляет техническую и консультационную поддержку Модуля СЦ; – взаимодействует с сотрудниками 1-го и 3-го уровня и пользователями Модуля СЦ; – формирует заявки для 3-го уровня и контролирует исполнение Передает обращение на третий уровень поддержки в случае невозможности решения на своем уровне Третий уровень технической поддержки (далее – 3-й уровень) – принимает обращения от 2-го уровня; – обеспечивает выполнение требований, предъявляемых Контрактом и настоящим Техническим заданием к Услугам, оказываемым Подрядчиком Все поступающие обращения должны быть исполнены Подрядчиком

Для обеспечения взаимодействия с Заказчиком Подрядчик со своей стороны определяет ответственных лиц, уполномоченных в структуре Подрядчика за своевременное и качественное оказание Услуг в рамках настоящего ТЗ, а также контактную информацию ответственных лиц (телефон, электронную почту). Подрядчик должен предоставить Заказчику единый адрес электронной почты для приема обращений (заявок) в течение 3 (трех) рабочих дней после заключения Контракта. Указанный в настоящем пункте адрес электронной почты (способ направления обращений (заявок) применяется в случае сбоя в работе СРО Заказчика. Со своей стороны, Заказчик предоставляет Подрядчику перечень и контактную информацию (телефон, электронную почту) уполномоченных лиц для осуществления взаимодействия с указанием зон ответственности. О любых изменениях в контактной информации ответственных лиц Стороны должны уведомить друг друга в течение 1 (одного) рабочего дня с момента возникновения таких изменений посредством уведомления на электронную почту ответственных лиц и/или в письменной форме. В результате оказания услуг по настоящему ТЗ не должны быть изменены исходные коды, дистрибутивы и иные компоненты Модуля СЦ вне согласованных с Заказчиком изменений. Любые изменения исходных кодов, дистрибутивов и иных компонентов Модуля СЦ должны производиться только после согласования с Заказчиком уполномоченными лицами по электронной почте или иным заранее согласованным способом. Не должна быть ухудшена надежность и производительность Модуля СЦ. Оказание услуг по Контракту не должно нарушать требования к информационной безопасности, описанной в документации на Модуль СЦ

Таблица 6. Категории обращений и заявок Категория Примеры Запрос на обслуживание Подготовка SQL запроса к СУБД для решения прикладной задачи и д.р. – запрос на любое действие, не являющееся запросом информации и несовершенный на основе происшествия, прямо или косвенно влияющего на работу Модуля СЦ Консультация «Где взять / куда обратиться...?», «Как сделать / выполнить…», «Как это работает…?» - запрос, имеющий своей целью получение информационной поддержки Инцидент Разбор ошибок/сбоев и подготовка материалов (корректировочных релизов, инструкций) для Заказчика для устранения ошибок/сбоев, которые приводят к частичному и полному нарушению работоспособности всех или отдельных функций ППО. Подготовка изменения и материалов, необходимых для проведения аварийно-восстановительных работ для возобновления работоспособности Модуля СЦ ЗНИ Подготовка изменений, связанных с изменением, улучшением/оптимизацией Модуля СЦ и выводом новой модифицированной функциональности в штатном режиме. Подготовка изменений, связанных с модификацией существующих и/или реализация новых интеграционных механизмов для получения/обработки данных внешних систем. Подготовка изменений графического интерфейса по требованиям Заказчика. Перечень статусов обращений (заявок) приведен в пункте 3.3. Регламента оказания Услуг. Назначение обращению (заявке) статуса «Закрыто» осуществляется Заказчиком только после получения от инициатора обращения (заявки) подтверждения о его исполнении или нахождения обращения (заявки) в статусе «Выполнено» и отсутствия повторных вопросов/запросов по данному обращению (заявки) в течение 5 рабочих дней. Категории и статусы обращений (заявок) могут быть скорректированы в процессе оказания услуг исключительно по согласованию с Заказчиком

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

4.3.6.4.1. Требования к проведению изменений Основанием для внесения изменений является запрос от Заказчика. Все активности по внесению изменений должны быть согласованы с Заказчиком, а действия Подрядчика при оказании данной услуги должны быть зафиксированы. В рамках данного Технического задания изменениями считаются локальные доработки функционала Модуля СЦ, которые не должны приводить к необходимости выполнения дополнительных аттестационных испытаний или переаттестации АСУ ТК в соответствии с п. 33 приказа от 29.04.2021 № 77 «Об утверждении Порядка организации и проведения работ по аттестации объектов информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну». При необходимости внесения изменений в Модуль СЦ, не связанных с критичным инцидентом, существенно нарушающим работоспособность Модуля СЦ, Заказчик направляет Подрядчику обращение (заявку), в котором излагает суть изменения, которое требуется внести в Модуль СЦ. Исполнитель, в течение 3 (трех) рабочих дней с момента поступления соответствующего обращения (заявки), оценивает техническую возможность реализации запрашиваемого изменения и варианты реализации. По итогу проведения оценки Подрядчик направляет Заказчику заключение о возможности реализации данного изменения с описанием возможных вариантов реализации и согласует с Заказчиком проведение данного изменения

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

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

В аварийном режиме осуществляется поиск неисправностей и проведение работ по их устранению. Перевод в аварийный режим должен осуществляться при возникновении сбоев, аварий и прочих незапланированных воздействий, сразу после наступления одной или нескольких аварийных ситуаций, с последующим возвратом в штатный режим функционирования сразу после окончания восстановительных работ. ПО Модуля СЦ должно обладать надежностью, обеспечивающей работу пользователей в произвольном режиме и оперативное восстановление работоспособности при сбоях. В целях обеспечения надежного функционирования ПО должно предусматривать: – сохранение целостности данных при нештатном завершении работы компонентов Модуля СЦ; – сохранение работоспособности программного обеспечения при некорректных действиях пользователя; – резервное копирование базы данных Модуля СЦ. – время восстановления работоспособности Модуля СЦ после отказа не более 4 часов. – отказоустойчивость на уровне 99% при единовременной количестве не менее 200 пользовательских сессий в Модуле СЦ. Указанные характеристики приведены без учета характеристик надежности инфраструктуры и времени передачи информации по каналам связи. При возникновении сбоев в аппаратном обеспечении, включая аварийное отключение электропитания, Модуль СЦ должен автоматически восстанавливать свою работоспособность (не требовать перенастройки) после устранения сбоев и корректного перезапуска аппаратного обеспечения

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

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

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

4.3.6.2. Требования к услугам информационно-консультационной поддержки работников Заказчика и пользователей Модуля СЦ Услуги информационно-консультационной поддержки сотрудников Заказчика включают: – обработку обращений и заявок, поступивших от сотрудников Заказчика; – консультирование сотрудников Заказчика и пользователей Модуля СЦ; – актуализацию документации, и других материалов по работе с Модулем СЦ при необходимости. – консультирование и разработку рекомендаций по настройке Модуля СЦ (без изменения программного кода), включая изменение настроек функционирования; – консультации по вопросам использования, настройки и возможностям Модуля СЦ; – консультации по проведению превентивных мер для недопущения аварийных ситуаций в Модуле СЦ; – консультации по предварительной диагностике и локализации возникшей неисправности Модуля СЦ; – консультации по вопросам обеспечения информационной безопасности Модуля СЦ и настройки функций, обеспечивающих корректную работу программного обеспечения для совершения юридически значимых действий в Модуле СЦ; – другие вопросы, связанные с работой Модуля СЦ. 4.3.6.2.1. Требования к порядку оказания услуг информационно-консультационной поддержки работников Заказчика и пользователей Модуля СЦ Подрядчик выполняет консультирование сотрудников Заказчика и пользователей Модуля СЦ. Консультация может быть предоставлена по согласованным с представителем Заказчика каналам коммуникации с регистрацией результата консультации в СРО Подрядчиком. Детальный порядок оказания консультационных услуг определен в Регламенте оказания Услуг

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

4.3.6.4.2. Требования к изменению настроек функционирования Изменение настроек функционирования может проводиться в рамках допустимых пределов изменения функционирования, заложенных в архитектуру Модуля СЦ. Изменение настроек функционирования включает в себя изменение данных и справочников, изменение форм документов, формируемых Модулем СЦ, изменение и настройку форматов и версий передачи данных в смежные системы. Доработка программного кода Модуля СЦ может допускаться (в случае необходимости) при выполнении работ по адаптации функций Модуля СЦ в части изменения формата передачи данных в смежные информационные системы при условии соблюдения требований пункта 29.3 приказа ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации»

4.3.6.5. Требования к услугам по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности По запросу Заказчика Подрядчик должен провести работу по приведению ППО в соответствие с требованиями по обеспечению информационной безопасности. Критичность уязвимости оценивается в соответствии в соответствии с Методическим документом ФСТЭК России «Методика оценки уровня критичности уязвимостей программных, программно-аппаратных средств» (утвержден ФСТЭК России 30.06.2025), а также с учетом ГОСТ 56545-2015 и международными стандартами (CVSS 3.0 и выше), и задает необходимый срок устранения. В процессе проведения Заказчиком обследования Модуля СЦ и выявления уязвимостей в ППО, связанных с исходным кодом Модуля СЦ и/или используемыми компонентами (библиотеками), Заказчик направляет Подрядчику обращение (заявку) на устранение, с указанием критичности и срочности принятия мер по устранению в СРО.

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

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

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

4.5.3. Требования по диагностированию Модуля СЦ Диагностирование Модуля СЦ должно осуществляться путем анализа записей в системных журналах СУБД, операционных систем серверов, а также с помощью встроенных средств диагностирования общего программного обеспечения Модуля СЦ. Диагностированию подлежат: – сбои и нарушения функционирования технического обеспечения (серверов) Модуля СЦ; – сбои и нарушения функционирования системного программного обеспечения серверов, используемых для работы Модуля СЦ; – сбои и нарушения функционирования прикладного программного обеспечения серверов, используемых для работы Модуля СЦ; – случаи недоступности (отсутствия ответа) или некорректные ответы внешних систем; – сбои и нарушения функционирования СУБД; – сбои при выполнении регламентных операций резервного копирования. При возникновении аварийных ситуаций либо ошибок в программном обеспечении диагностические инструменты должны позволять сохранять набор информации, необходимой для идентификации и устранения проблемы. Модуль СЦ и ее компоненты должны обеспечивать возможность диагностики своей работоспособности с возможностью интеграции с модулем мониторинга АСУ ТК. Набор передаваемых журналов и метрик должен быть определен на этапе технического проектирования

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

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

4.5.8. Требования к защите от влияния внешних воздействий Требования к защите от влияния внешних воздействий не предъявляются

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

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

4.4. Требования к видам обеспечения 4.4.1. Требования к лингвистическому обеспечению Документация на Модуль СЦ должна разрабатываться на русском языке. Взаимодействие пользователей с Модулем СЦ посредством графического интерфейса должно происходить на русском языке за исключением сообщений, зависящих от настроек системного программного обеспечения, установленного на рабочих местах пользователей. При разработке программных решений Модуля СЦ должно быть предусмотрено использование языков программирования высокого уровня, приведенных в Таблице 7. Таблица 7. Языки и средства разработки, специального программного обеспечения Модуля СЦ Категория Наименование Назначение Языки программирования Kotlin Разработка серверной логики и сервисов (backend) JavaScript / TypeScript Разработка клиентской части (frontend) Python Разработка скриптов интеграции, обработки данных и автоматизации Фреймворки и библиотеки Vue.JS Разработка пользовательских интерфейсов (веб-интерфейсы компонентов визуализации и отчетности) React Разработка пользовательских интерфейсов (при необходимости создания сложных интерактивных компонентов) Решения по лингвистическому обеспечению, включая перечень используемых языков программирования, должны быть согласованы с Заказчиком на этапе технического проектирования

4.4.2. Требования к математическому обеспечению Требования к математическому обеспечению не предъявляются. 4.4.3. Требования к метрологическому обеспечению Требования к метрологическому обеспечению не предъявляются. 4.4.4. Требования к организационному обеспечению Требования к организационному обеспечению не предъявляются. 4.4.5. Требования к методическому обеспечению Задачи методического обеспечения Модуля СЦ должны быть обеспечены за счет использования технологических и методических документов касающихся вопросов функционирования транспортного комплекса и разработки и эксплуатации ПО. 4.4.6. Требования к информационному обеспечению Состав, структура и способы организации информационного обеспечения в Модуле СЦ должны быть определены на этапе технического проектирования. Факты информационного обмена с внешними системами должны фиксироваться в соответствующем журнале

4.5.5. Требования к информационной безопасности Работы по защите информации/информационной безопасности, не включенные в состав настоящего раздела, требуемые в соответствии с требованиями постановления Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации», а также нормативно правовых актов в области защиты персональных данных и обеспечения безопасности объектов критической информационной инфраструктуры, будут проведены в рамках исполнения отдельного контракта, заключенного по результатам отдельной закупочной процедуры (не является частью данного ТЗ), включающего: – определение актуальных угроз безопасности информации и актуализация модели угроз безопасности информации (при необходимости); – выполнение требований о согласовании технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России в установленном порядке; – выполнение требований по устранению Подрядчиком замечаний и недостатков, в случае их выявления при согласовании Заказчиком технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России; – выполнение требований к классу защищенности ГИС, уровню защищенности персональных данных и категории значимости объекта КИИ РФ, установленных для Головного центра обработки данных ФГБУ «СИЦ Минтранса России» (далее – ГЦОД);

– определение перечня объектов защиты информационной системы; – описание (актуализированных) требований к системе защиты информации, а также к мерам защиты информации информационной системы в зависимости от установленных классов защищенности, уровня защищенности персональных данных и категории значимости объектов КИИ РФ (приказы ФСТЭК России № 21, 117, 239); – выполнение требований к мерам по защите ГИС от атак, направленных на отказ в обслуживании, в соответствии с пунктами 30, 34, 59, 63 Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений, утвержденных приказом ФСТЭК России от 11.04.2025 № 117; – описание (актуализированных) требований по защите информации, подлежащих реализации в информационно телекоммуникационной инфраструктуре ГЦОД; – выполнение требований о применении сертифицированных средств защиты информации, включая их классы защиты и уровни доверия; – выполнение требований о запрете использования с 01.01.2025 органами (организациями) средств защиты информации странами происхождения, которых являются иностранные государства в соответствии с пунктом 6 Указа Президента Российской Федерации от 01.05.2022 № 250; – выполнение требований по обеспечению непрерывного взаимодействия с ГосСОПКА в установленном порядке;

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

Лицензионное (сублицензионное) соглашение (договор) не может возлагать на Заказчика какие-либо обязанности (в т.ч. в части конфиденциальности, предоставления отчетности), не предусмотренные Контрактом. 4.5.9.7. Передача Заказчику исключительных прав, или простых (неисключительных) прав не может повлечь увеличение стоимости Контракта и/или изменение иных существенных условий Контракта. 4.5.9.8. Функциональность Модуля СЦ передается в объеме и в сроки, установленные Техническим заданием. 4.5.9.9. Нарушение условий настоящего раздела Технического задания, в т.ч. отсутствие соответствующего лицензионного (сублицензионного) соглашения (или договора), либо предоставление лицензионного (сублицензионного) соглашения (или договора), не соответствующего требованиям действующего законодательства Российской Федерации или требованиям Контракта, является нарушением существенных условий Контракта. 4.5.9.10. В случае, если в соответствии с пунктом 4.5.9.6 Заказчику передается исключительное право, такая передача осуществляется в порядке, установленном Гражданским кодексом Российской Федерации. 4.5.9.11. В случае, если при выполнении Работ положения пунктов 4.5.9.5-4.5.9.6 не применялись, Подрядчик в составе отчетной документации предоставляет об этом декларацию в свободной форме. Декларация должна содержать сведения о полном соответствии результата Работ требованиям Контракта, а также о неприменении при выполнении работ готового программного обеспечения (платформ, подсистем, СУБД и т.д.), которое стало частью (компонентом) Системы

– выполнение требований по обеспечению в автоматизированном режиме с Национальной системой противодействия DDoS-атакам (НСПА) Центра мониторинга и управления сетью связи общего пользования ФГУП «ГРЧЦ» в рамках реализации мер по защите ГИС от атак, направленных на отказ в обслуживании; – детализированные требования к составу и содержанию работ по аттестации, а также к их результатам в соответствии с пунктами 13, 15 и 16 требований приказа ФСТЭК России от 29.04.2021 № 77 «Об утверждении Порядка организации и проведения работ по аттестации объектов информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну»

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

Подрядчик должен обеспечить реализацию и проведение внутренних проверок мер по разработке безопасного ПО, приведенных в Руководстве. Подрядчик должен провести анализ угроз безопасности информации программного обеспечения в соответствии с ГОСТ 58412-2019 «Защита информации. Разработка безопасного программного обеспечения. Угрозы безопасности информации при разработке программного обеспечения». Подрядчик должен провести испытания по выявлению уязвимостей в программном обеспечении Системы: · проведение статического анализа исходного кода программы; · проведение динамического анализа исходного кода программы; · проведение композитного анализа исходного кода и образов программы; · проведение фаззинг-тестирования программы, направленного на выявление в ней уязвимостей. Испытания по выявлению уязвимостей в программном обеспечении Системы должны быть проведены в рамках: · предварительных испытаний; · опытной эксплуатации; · приемочных испытаний

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

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

4.5.11. Требования к показателям назначения 4.5.11.1. Требования к показателям назначения мероприятий по развитию Модуля СЦ В рамках выполнения работ по развитию Модуля СЦ, предусмотренных ТЗ, показатель назначения «Количество пользователей» должен соответствовать значениям, приведенным в данном разделе. Пояснения по показателям, связанным с количеством пользователей, приведены в Таблице 8. Таблица 8. Определения показателей, связанных с количеством пользователей в Модуле СЦ № Показатель Определение Расчетное количество пользователей Количество пользователей, работу которых должен обеспечить Модуль СЦ к моменту сдачи работ по Контракту с учетом достижения всех показателей назначения Расчетное количество одновременно работающих пользователей Количество одновременно работающих пользователей, работу которых должен обеспечивать Модуль СЦ к моменту сдачи работ по Контракту с учетом достижения всех показателей назначения Значения показателей количества пользователей, достижение которых необходимо обеспечить, представлено в Таблице 9

Таблица 9. Значения показателей количества пользователей № Показатель Значение 1. Расчетное количество пользователей 1 000 2. Расчетное среднее количество одновременно работающих пользователей 200 Развитие Модуля СЦ должно быть направлено на достижение следующего эффекта (показателя), подставленного в мероприятии 103.002 «Информационно-аналитическая система регулирования на транспорте (АСУ ТК)» ВПЦТ Минтранса России: Выполнение работ по развитию Модуля СЦ предусмотрено мероприятием по развитию АСУ ТК, приведенном в ВПЦТ Минтранса России на 2026-2028 гг: № 103.002 «АСУ ТК» в составе ИТ расхода 103.26.000005 «Развитие предусматривает реализацию ОКР и эффектов, приведенных в Таблице 10. Таблица 10. ОКР и эффекты, приведенные в ВПЦТ Минтранса России на 2026 г. № ОКР Дата ОКР Эффекты 1 Обеспечено информационное взаимодействие с Минобороны России о происшествиях на транспортных объектах 25.12.2026 Сокращено время сбора и передачи сведений для Минобороны России о ЧС и НС на транспорте с 120 до 10 минут 2 Обеспечена автоматизация формирования отчетов о нештатных ситуациях на транспорте, в том числе по данным внешних систем 25.12.2026 Сокращено время на подготовку отчетов о нештатных ситуациях на транспорте с 20 до 5 минут Реализация остальных ОКР не является предметом данного ТЗ и проводится в рамках отдельного технического задания.

4.5.11.2. Требования к показателям назначения мероприятий по эксплуатации Модуля СЦ. Работы по эксплуатации Модуля СЦ не должны обеспечивать режимы функционирования Модуля СЦ, приведенные в разделе 4.5.2 данного ТЗ

5. СОСТАВ И СОДЕРЖАНИЕ РАБОТ ПО РАЗВИТИЮ И ТЕХНИЧЕСКОЙ ПОДДЕРЖКЕ МОДУЛЯ СЦ (КАЛЕНДАРНЫЙ ПЛАН) - 1 Техническое проектирование Сопроводительным письмом предоставляются Заказчику: · Технический проект, включая следующие документы: – Ведомость технического проекта; – Ведомость машинных носителей информации – Пояснительная записка; – Описание информационного обеспечения системы; – Описание автоматизируемых функций; – Схема функциональной структуры; – Описание организации информационной базы; – Описание программного обеспечения; · Макеты экранных форм компонента «Интерактивная карта»; · Руководство по безопасной разработке программного обеспечения; · Документ о приемке Начало: с даты заключения контракта Окончание: не позднее 31.07.2026 - - Значение характеристики не может изменяться участником закупки

2 Услуги по технической поддержке Модуля СЦ (с даты заключения контракта по 10.09.2026) По окончании оказания Услуг сопроводительным письмом предоставляются Заказчику: – Отчет об оказанных Услугах по технической поддержке; – Актуальные на дату окончания оказания Услуг по данному этапу исходные коды прикладного ПО на электронном носителе (в случае внесения изменений); – Инструкция по сборке и развертыванию (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство пользователя (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство администратора (в случае внесения изменений); – Документ о приемке Начало: с даты заключения контракта Окончание: не позднее 10.09.2026

3 Разработка программного обеспечения (1 очередь, пп. 4.2.1, 4.2.6 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ; – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 1 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 1 очереди; – Руководство по резервному копированию; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 16.09.2026

4 Разработка программного обеспечения (2 очередь, пп. 4.2.3, 4.2.4 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ. – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 2 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 2 очереди; – Руководство по резервному копированию; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 25.09.2026

5 Разработка программного обеспечения (3 очередь, пп. 4.2.2, 4.2.5 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ; – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 3 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 3 очереди; – Руководство по резервному копированию; – Описание ролевой модели; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 09.10.2026

6 Опытная эксплуатация (1 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акт о завершении опытной эксплуатации 1 очереди; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке 17.09.2026 Окончание: не позднее 26.10.2026

7 Опытная эксплуатация (2 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акт о завершении опытной эксплуатации 2 очереди; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке 26.09.2026 Окончание: не позднее 26.10.2026

8 Опытная эксплуатация (3 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Акт о завершении опытной эксплуатации 3 очереди; – Документ о приемке Начало: с 10.10.2026 Окончание: не позднее 26.10.2026

9 Приемочные испытания Сопроводительным письмом предоставляются Заказчику: – Программа и методика приёмочных испытаний; – Протокол приемочных испытаний; – Исходные коды и дистрибутивы на электронном носителе (при условии внесения изменений, с учетом доработок по результатам опытной эксплуатации и проведенных испытаний); – Комплект рабочей документации на Модуль СЦ (при условии внесения изменений, с учетом доработок по результатам опытной эксплуатации и проведенных испытаний); – Акт приемки Системы в эксплуатацию; – Акт приемки-передачи исключительных прав на объект; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке; – Документы в соответствии с разделом 4.5.9 ТЗ; – Обеспечение гарантийных обязательств Начало: с 27.10.2026 Окончание: не позднее 10.11.2026

10 Услуги по технической поддержке Модуля СЦ (с 11.09.2026 по 15.12.2026) По окончании оказания Услуг сопроводительным письмом предоставляются Заказчику: – Отчет об оказанных Услугах по технической поддержке; – Актуальные на дату окончания оказания Услуг по данному этапу исходные коды прикладного ПО на электронном носителе (в случае внесения изменений); – Инструкция по сборке и развертыванию (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство пользователя (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство администратора (в случае внесения изменений); – Документ о приемке Начало: с 11.09.2026 Окончание: не позднее 15.12.2026

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

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

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

6.1. Сведения о гарантийном обслуживании Модуля СЦ Под гарантией понимается устранение Подрядчиком своими силами и за свой счет допущенных по его вине недостатков, выявленных после приемки выполненных Работ, как в работе самой Модуля СЦ, так и недостатков в отчетной документации. Если в период гарантийного срока обнаружатся недостатки, то Подрядчик обязан устранить их за свой счет, в сроки, установленные Заказчиком. Гарантийный срок в этом случае продлевается на период устранения недостатков. Срок гарантии: 1 год с даты приемки Заказчиком результатов исполнения Этапа № 9 контракта. Подрядчиком должны быть внесены соответствующие исправления в техническую и рабочую документацию (указанную в пунктах 5 и 6 настоящего ТЗ), связанные с устранением замечаний к работе Модуля СЦ или в случае выявления Заказчиком недостатков в такой документации в период гарантийного срока. Внесение изменений в документацию технического и рабочего проектирования осуществляется в соответствии с ГОСТ 2.503-2023 и ГОСТ Р 2.504-2021.

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

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

8. ТРЕБОВАНИЯ К СОСТАВУ И СОДЕРЖАНИЮ РАБОТ ПО ПОДГОТОВКЕ МОДУЛЯ СЦ К ВВОДУ В ЭКСПЛУАТАЦИЮ - По результатам проведения приемочных испытаний оформляется Протокол приемочных испытаний и Акт приемки в эксплуатацию. В случае, если взаимодействие с внешними системами не может быть проверено на средах постоянной эксплуатации взаимодействующих систем (по причине неготовности со стороны внешней системы или иным причинам), функции взаимодействия, разработанные в соответствии с требованиями ТЗ, должны быть проверены на тестовых данных с использованием программ-имитаторов взаимодействия. По результатам выполнения этапа приемочных испытаний должны быть подготовлены материалы для регистрации доработанной версии Модуля СЦ (объекта учета) в НФАП в соответствии с требованиями постановления Правительства Российской Федерации от 30 января 2013?г. №?62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин» (с изменениями и дополнениями) в части обязательности размещения результатов работ в национальном фонде алгоритмов и программ для электронных вычислительных машин. Сдача-приемка результатов выполнения Работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная, техническая документация, а также программное обеспечение предоставляется Заказчику в порядке, предусмотренном Контрактом и ТЗ до размещения Подрядчиком в Единой информационной системе в сфере закупок документа о приемке. Результаты проведения опытной эксплуатации, предварительных и приемочных испытаний должны быть зафиксированы в соответствующих протоколах и актах. Выявленные отклонения от настоящего ТЗ, оформляются как недостатки Модуля СЦ - - Значение характеристики не может изменяться участником закупки

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

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

9. ТРЕБОВАНИЯ К ДОКУМЕНТИРОВАНИЮ - 9.1. Общие требования Документация на Модуль СЦ должна быть разработана в составе, указанном в разделах 5-8 данного ТЗ, и должна удовлетворять требованиям комплекса стандартов и руководящих документов на автоматизированные системы: – ГОСТ Р 2.105-2019 в части оформления текстовых документов; – ГОСТ 34.201-2020 в части наименования и обозначения документов. Документация на Модуль СЦ должны оформляться на листах формата А4. Допускается для размещения рисунков и таблиц использование листов формата А3 с подшивкой по короткой стороне листа. Документы объемом более 25 (двадцати пяти) листов должны содержать информационную часть, состоящую из аннотации и содержания. Исходные коды должны быть представлены в 1 (одном) экземпляре на электронном носителе, отчетные материалы должны быть представлены в 2 (двух) экземплярах на бумажном носителе (по одному экземпляру для Заказчика и Подрядчика) и в 1 (одном) экземпляре на электронном носителе в формате документов DOCX и PDF. При разработке документов на Модуль СЦ допускается отклонение от требований комплекса стандартов, описанных выше. Документам на Модуль СЦ должны в обязательном порядке присваиваться уникальные децимальные номера в соответствии с порядком, установленном в ГОСТ 34.201-2020. Документ «Программа и методика предварительных испытаний» должен включать приложения с формой протокола предварительных испытаний и формой акта приемки в опытную эксплуатацию. Документ «Программа опытной эксплуатации» должен включать приложение с формой журнала опытной эксплуатации. Документ «Программа и методика приемочных испытаний» должен включать приложения с формой протокола приемочных испытаний и формой акта приемки в эксплуатацию - - Значение характеристики не может изменяться участником закупки

10. ИСТОЧНИКИ РАЗРАБОТКИ - 10.1. Список литературы Специальная литература для разработки ТЗ не использовалась. 10.2. Нормативно-методические документы Список используемых нормативно-методических документов представлен в разделе 1.6 технического задания. ? Приложение А Эскизы визуального оформления компонента «Интерактивная карта» - - Значение характеристики не может изменяться участником закупки

Приложение Б Параметры оказания услуг - Б.1. Базовые параметры оказания Услуг Базовые параметры оказания Услуг приведены ниже: – режимы оказания Услуг (таблица Б.1.1); – сроки предоставления отчетности (таблица Б.1.2). Таблица Б.1.1 - Режимы оказания Услуг № п/п Параметр Значение - - Значение характеристики не может изменяться участником закупки

1 Режим работы Системы Круглосуточно (24х7) 2 Режим доступности информационно-консультационной поддержки пользователей Системы 2.1 Прием и регистрация обращений (заявок) в СРО Регистрация обращений (заявок) производится круглосуточно в режиме 24х7, без праздников и выходных дней. Обработка заявок первой линией поддержки осуществляется в рабочие дни с 9 до 18 часов 2.2 Консультирование сотрудников Заказчика и пользователей Системы в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 3 Режим доступности по решению инцидентов, связанных с работой ППО: 3.1 - приоритет «Критический» Круглосуточно (24х7) 3.2 - приоритет «Высокий» Круглосуточно (24х7) 3.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 3.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4 Режим доступности услуг по адаптации, конфигурации и коррекционному сопровождению Системы 4.1 - приоритет «Критический» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.2 - приоритет «Высокий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 5 Режим доступности по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности 5.1 - приоритет «Критический» Круглосуточно (24х7) 5.2 - приоритет «Высокий» Круглосуточно (24х7) 5.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 5.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням)

Таблица Б.1.2. Сроки предоставления отчетности, с момента получения запроса № п/п Параметр Значение 1 Предоставление отчета об оказанных услугах за произвольный период 10 рабочих дней 2 Предоставление подробной информации по инциденту с приоритетом «Критический» 16 рабочих часов 3 Предоставление актуализированной документации 10 рабочих дней

Б.2. Приоритеты и регламентные сроки решения обращений (заявок) В зависимости от уровня сбоя в работе Системы обращению (заявке) присваивается один из следующих приоритетов, а также в зависимости от приоритета обращения (заявки) устанавливаются следующие контрольные сроки решения в соответствии с таблицей ниже (Таблица Б.2.1). Таблица Б.2.1 – Приоритеты и регламентные сроки решения обращений (заявок) № п/п Приоритет Максимальное время реагирования Время решения (срок выполнения) Описание приоритета По информационно-консультационной поддержке сотрудников Заказчика и пользователей Системы 1 - не более 1 часа не более 10 часов - По решению инцидентов, связанных с работой ППО: 1 Критический не более 30 минут не более 4 часов - полная недоступность ППО; - недоступность ключевых функций - ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО; - невозможность информационного обмена с ППО для ИС более 4 часов 2 Высокий не более 1 часа не более 8 часов - ошибки/сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; - снижение быстродействия СПО (время отклика ППО на операции превышает 30 секунд); - недоступность управления правами и ролями пользователей 3 Средний не более 4 часов не более 24 часов - невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым -недоступность функции формирования отчетов 4 Низкий не более 8 часов не более 40 часов - отклонение в работе ППО, не влияющее на корректную работу функций; - другие сбои и ошибки, затрагивающие основные функции ППО

По адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) 1 Критический не более 40 минут не более 8 часов - изменения, необходимые при проведении аварийно-восстановительных работ для возобновления работоспособности Системы; - изменения, связанные с критичными ошибками, блокирующими возможность оказания государственных услуг и/или чтение и внесение данных в Систему 2 Высокий не более 1 часа не более 40 часов - изменения, относящиеся к обеспечению работоспособности основной функциональности Системы, устраняют выявленные дефекты в работе Системы, оказывающие существенное влияние на работу пользователей в Системе; - изменения, затрагивающие три и более подсистемы/модуля Системы для адаптации 3 Средний не более 4 часов не более 72 часов - изменения, связанные с развитием/улучшением/оптимизацией Системы и выводом новой функциональности в штатном режиме для одного-двух модулей/подсистем; - изменения, связанные с развитием интеграционных механизмов Системы, например обновление существующих и/или реализация новых видов сведений СМЭВ, обновление существующих и/или реализация новых API, адаптация и/или изменение механизмов импорта и экспорта данных Системы и т.д. 4 Низкий не более 8 часов не более 160 часов - изменения, связанные с ошибками/корректировкой/изменением в отображении информации в пользовательском графическом интерфейсе Системы (графика, текст, органы управления, элементы интерфейса)

По устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности 1 Критический не более 30 минут не более 24 часов - критические уязвимости, влияющие на возможную полную недоступность ППО, ключевых функций Системы, ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО без возможности восстановления работоспособности Системы. - Критический уровень CVSS > 8.0 2 Высокий не более 1 часа не более 84 часов - критические уязвимости, влияющие на ошибки и сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО. - Высокий уровень CVSS 5.0 - 8.0 3 Средний не более 4 часов не более 120 часов - уязвимости, влияющие на невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым - Средний уровень CVSS 2.0 - 4.9 4 Низкий не более 8 часов не более 160 часов - уязвимости, влияющие на отклонение в работе ППО, не влияющее на корректную работу функций; - другие сбои и ошибки, затрагивающие основные функции ППО - Низкий уровень CVSS < 2.0

Взаимодействие Заказчика и Подрядчика в части регистрации и контроля времени реагирования и решения обращения (заявки) осуществляется через СРО. Заказчик предоставляет Подрядчику доступ к СРО после заключения Контракта. Поступившие от разных пользователей заявки по поводу однотипных инцидентов или имеющие общую причину должны объединяться в одну заявку. Срок выполнения включает время диагностики инцидента, в ходе которого определяется причина инцидента (проблемы) и способ его устранения. Подрядчик должен обеспечить функционирование Модуля СЦ в соответствии с требованиями и параметрами, указанными в настоящем ТЗ и Регламенте оказании услуг. Основные параметры быстродействия типовых операций в Модуле СЦ указаны в таблице ниже (таблица Б.2.2). Таблица Б.2.2 - Параметры быстродействия Модуля СЦ № п/п Наименование параметра Значение (секунд) 1 Среднее время получения сообщения из очереди сообщений 10 2 Среднее время получения ответа от Системы 5 3 Среднее время открытия карточки реестра 5

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

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

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

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

На рисунке 8 приведена форма обращения (заявки) типа «Инцидент» в СРО. Рисунок 8 - Форма обращения (заявки) типа «Инцидент» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуги по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности, заполненную в свободной форме

Приложение 1 к Регламенту Матрица ответственных за взаимодействия в рамках выполнения работ по техническому сопровождению Системы Таблица 1 – Ответственные за взаимодействия в рамках выполнения работ по техническому сопровождению Системы со стороны Исполнителя ФИО Должность Адрес электронной почты Телефон — — — Общий контакт

Приложение 2 к Регламенту Приоритеты и регламентные сроки решения обращений (заявок) Приоритеты и регламентные сроки решения обращений (заявок) приведены в таблице 1. Таблица 1 – Приоритеты и регламентные сроки решения обращений (заявок) № п/п Приоритет Максимальное время реагирования Время решения (срок выполнения) Описание приоритета

По информационно-консультационной поддержке сотрудников Заказчика и пользователей Системы 1 – не более 1 часа не более 10 часов –

По решению инцидентов, связанных с работой ППО 1 Критический не более 30 минут не более 4 часов – полная недоступность ППО; – недоступность ключевых функций; – ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО; – невозможность информационного обмена с ППО для ИС более 4 часов 2 Высокий не более 1 часа не более 8 часов – ошибки/сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; – снижение быстродействия СПО (время отклика ППО на операции превышает 30 секунд); – невозможность управления правами и ролями пользователей 3 Средний не более 4 часов не более 24 часов – невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым недоступность функции формирования отчетов 4 Низкий не более 8 часов не более 40 часов – отклонение в работе ППО, не влияющее на корректную работу функций; – другие сбои и ошибки, затрагивающие основные функции ППО

По адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) 1 Критический не более 40 минут не более 8 часов – изменения необходимые при проведении аварийно-восстановительных работ для возобновления работоспособности Системы; – изменения, связанные с критичными ошибками, блокирующими возможность оказания государственных услуг и/или чтение и внесение данных в Систему 2 Высокий не более 1 часа не более 40 часов – изменения относящиеся к обеспечению работоспособности основной функциональности Системы, устраняют выявленные дефекты в работе Системы, оказывающие существенное влияние на процесс оказания государственных услуг и работу пользователей в Системе; – изменения, затрагивающие три и более подсистемы/модуля Системы для адаптации 3 Средний не более 4 часов не более 72 часов – изменения, связанные с развитием/улучшением/оптимизацией Системы и выводом новой функциональности в штатном режиме для одного-двух модулей/подсистем; – изменения, связанные с развитием интеграционных механизмов Системы, например, обновление существующих и/или реализация новых видов сведений СМЭВ, обновление существующих и/или реализация новых API, адаптация и/или изменение механизмов импорта и экспорта данных Системы и т.д. 4 Низкий не более 8 часов не более 160 часов – изменения, связанные с ошибками/ корректировкой/изменение в отображении информации в пользовательском графическом интерфейсе Системы (графика, текст, органы управления, элементы интерфейса)

По устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности 1 Критический не более 30 минут не более 24 часов – критические уязвимости, влияющие на возможную полную недоступность ППО, ключевых функций Системы, ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО без возможности восстановления работоспособности Системы; – Критический уровень CVSS > 8.0 2 Высокий не более 1 часа не более 84 часов – критические уязвимости, влияющие на ошибки и сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; – Высокий уровень CVSS 5.0 - 8.0 3 Средний не более 4 часов не более 120 часов – уязвимости, влияющие на невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым; – Средний уровень CVSS 2.0 - 4.9 4 Низкий не более 8 часов не более 160 часов – уязвимости, влияющие на отклонение в работе ППО, не влияющее на корректную работу функций; – другие сбои и ошибки, затрагивающие основные функции ППО; – Низкий уровень CVSS < 2.0

Приложение Г Форма Отчета об оказанных услугах Отчет об оказанных услугах за этап «наименование этапа» в период с «__» _________ по «__» _________. № п/п Наименование услуги Общее количество Номер ОРС Краткое Описание Время реагирования по ТЗ Время реагирования фактическое Время решения по ТЗ Время решения фактическое Результат соблюдения времени реагирования Результат соблюдения времени решения Примечание 1 Услуги по информационно-консультационной поддержке работников Заказчика 2 546782 Консультация по работе Модуля СЦ 1 2 10 часов 11 часов Нет Нет 567123 Консультация по схеме БД 1 1 10 часов 1 час Да Да 2 … … Заказчик Подрядчик /Должность/ /Должность/ ____________________ /Ф.И.О/ ___________________ /Ф.И.О/ М.П. М.П. «_____»_______________________202_г. «_____»_______________________202_г

Приложение 1 к Отчету об оказанных услугах Журнал обращений (заявок) на оказание услуги по информационно-консультационной поддержке пользователей Системы (шаблон) Наименование Исполнителя в этапе «наименование этапа» в период с ________________ по _______________ оказал(о) Услугу по поддержке пользователей Системы в объеме, указанном в Таблице 1 Таблица 1 - Журнал обращений (заявок) пользователей Системы № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. ИТОГО зарегистрировано: Всего обращений (заявок): ________ ИТОГО решено: Всего обращений (заявок): ________

Приложение 2 к Отчету об оказанных услугах Журнал обращений (заявок) по решению инцидентов, связанных с работой ППО (шаблон) Наименование Исполнителя в этапе «наименование этапа» в период с ________________ по _______________ оказал(о) Услугу по решению инцидентов в объеме, указанном в Таблице 1. Таблица 1 - Журнал по решению инцидентов № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. ИТОГО зарегистрировано: Всего инцидентов: ________ ИТОГО решено: Всего инцидентов: ________

Приложение 3 к Отчету об оказанных услугах Журнал обращений (заявок) выполнения адаптационного, конфигурационного и коррекционного сопровождения Системы (шаблон) Журнал выполнения адаптации, конфигурации и коррекции Системы сформирован за этап «наименование этапа» в период с «__» _________ по «__» ____________ и представлен в таблице ниже (Таблица 1). Таблица 1 - Журнал выполнения адаптации, конфигурации и коррекции сопровождения Системы № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. Количество выполненных заявок за этап: ________

Приложение 4 к Отчету об оказанных услугах Журнал обращений (заявок) по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности (шаблон) Журнал обращений (заявок) по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности сформирован за этап «наименование этапа» в период с «__» _________ по «__» ____________ и представлен в таблице ниже (Таблица 1). Таблица 1 - Журнал выполнения заявок по устранению уязвимостей в ППО № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. Количество выполненных заявок за этап: ________

Приложение Д Форма Протокола проверки результатов организационно-штатных и подготовительных мероприятий (шаблон) Протокол проверки результатов организационно-штатных и подготовительных мероприятий Настоящий Протокол содержит результаты проверки организационно-штатных и подготовительных мероприятий, проведенных Исполнителем (Таблица Д.1). Таблица Д.1. Протокол проверки результатов № Мероприятия Подготовительного этапа Результат проверки 1. Определить и направить Заказчику документ «Ответственные за взаимодействия в рамках выполнения работ по техническому сопровождению Системы со стороны Исполнителя». Документ содержит контактную информацию (ФИО, должность, адрес электронной рабочей почты, номер телефона) не менее чем о 2 лицах, ответственных за оказание услуг со стороны Подрядчика Выполнено/Не выполнено 2. Обеспечить подключение специалистов Подрядчика к Системе Выполнено/Не выполнено 3. Обеспечить подключение специалистов Подрядчика к СРО Выполнено/Не выполнено Заказчик Подрядчик /Должность/ /Должность/ ____________________ /Ф.И.О/ ___________________ /Ф.И.О/ М.П. М.П. «_____»_______________________202_г. «_____»_______________________202_г

4.2. Форма обращения (заявки) на оказание услуги по решению инцидентов, связанных с работой ППО При подаче обращения (заявки) типа «Инцидент» в СРО указывается (Таблица 6): Таблица 6 – Описание атрибутов формы обращения (заявки) на оказание услуги по решению инцидентов, связанных с работой ППО Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 6) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 6) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 6,) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 6) Категория обращения (заявки): инцидент Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 6) Приоритет изменения Время - одно из значений: Низкий, Средний, Высокий или Критический. Определяет, очередность решения обращения (заявки), ресурсы, привлекаемые для решения обращения (заявки), порядок/процедура действий при решении обращения (заявки) – поле СРО «Приоритет» (см. рисунок 6,)

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

На рисунке 6 приведена форма обращения (заявки) типа «Инцидент» в СРО. Рисунок 6 - Форма обращения (заявки) типа «Инцидент» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуги по решению инцидентов, связанных с работой ППО, заполненную в свободной форме

Уровень технической поддержки Организационно-структурная часть технической поддержки, имеющая определённые организационно-нормативными документами зоны ответственности, обязанности, а также временные нормативы, в течение которых эти обязательства должны выполняться либо эскалироваться на следующий уровень технической поддержки Услуги Услуги по технической поддержке Информационно-аналитической системы регулирования на транспорте АСУ ТК ФИО Фамилия, имя, отчество Эскалация Процедура повышения внимания к обращению (заявке) путем повышения его приоритета и/или передачи на следующий уровень технической поддержки, а также привлечение ролей, которые могут принимать решения без передачи на следующий уровень технической поддержки API Англ. Application Programming Interface — программный интерфейс приложения, интерфейс прикладного программирования — описание способов (набор классов, процедур, функций, структур или констант), которыми одна компьютерная программа может взаимодействовать с другой программой

CVSS Англ. Common Vulnerability Scoring System - открытый стандарт, используемый для расчета количественных оценок уязвимости в безопасности компьютерной системы, обычно с целью понять приоритет ее исправления. В современном инструментарии информационной безопасности используется версия 3.0 и выше с дополнительными метриками к базовым оценкам ID Англ. Identifier – идентификатор, уникальный признак объекта, позволяющий отличать его от других объектов, то есть, идентифицировать SLA Англ. Service Level Agreement - утвержденные условия по обработке обращения (заявки) с установленными метриками времени, которые определяют пороговые значения для эскалации в зависимости от статуса обращения (заявки) (например, время реакции – время от регистрации до осуществления первичной обработки, время решения – время от регистрации обращения (заявки) до его решения и т.д.) SQL Англ. Structured Query Language — «язык структурированных запросов», — декларативный язык программирования, применяемый для создания, модификации и управления данными в реляционной базе данных, управляемой соответствующей СУБД

1 Общие сведения 1.1 Полное наименование Услуг Оказание услуг по технической поддержке Модуля СЦ АСУ ТК в 2026 году. 1.2 Предмет Регламента оказания услуг Требования Технического задания

2 Общие положения 2.1 Цель и задачи оказания услуг Целью технической поддержки Системы является обеспечение ее стабильного и безопасного функционирования и эксплуатации, предупреждение, выявление и устранение сбоев в работе Системы и минимизация их неблагоприятного влияния. Для достижения поставленной цели требуется решение следующих задач: 1. Обеспечение информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы. 2. Поддержание параметров функционирования ППО Системы, удовлетворяющих требованиям производственных процессов, включая их непрерывность. 3. Обеспечение бесперебойного функционирования ППО и своевременное устранение сбоев и аварийных ситуаций в Системе. 4. Своевременное устранение уязвимостей при выявлении таковых, в соответствии с требованиями к обеспечению информационной безопасности. 5. Адаптация, конфигурирование, коррекция программного обеспечения в соответствии с изменениями нормативно-правовой базы и запросами уполномоченных сотрудников органов государственной власти, включая выполнение процедур тестирования и участие в обновлениях ППО на стендах Заказчика. 6. Обеспечение сохранения работоспособности ППО в изменяемой среде эксплуатации. 7. Ведение документации по настоящему контракту и инициирование актуализации документации на Систему по результатам обработки запросов Заказчика и внесения соответствующих изменений в ППО

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

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

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

Таблица 1 - Типы обращений (заявок) Тип обращения (заявки) Описание Запрос на обслуживание Подготовка SQL запроса к СУБД для решения прикладной задачи и д р. – запрос на любое действие, не являющееся запросом информации и несовершенный на основе происшествия, прямо или косвенно влияющего на работу Системы Консультация (входит в тип обращения (заявки) «Запрос на обслуживание») «Где взять / куда обратиться...?», «Как сделать / выполнить…», «Как это работает…?» - запрос, имеющий своей целью получение информационной поддержки Инцидент Разбор ошибок/сбоев и подготовка материалов (корректировочных релизов, инструкций) для Заказчика для устранения ошибок/сбоев, которые приводят к частичному и полному нарушению работоспособности всех или отдельных функций ППО. Подготовка изменения и материалов, необходимых для проведения аварийно-восстановительных работ для возобновления работоспособности Системы. ЗНИ Подготовка изменений, связанных с изменением, улучшением/оптимизацией Системы и выводом новой модифицированной функциональности в штатном режиме. Подготовка изменений, связанных с модификацией существующих и/или реализация новых интеграционных механизмов для получения/обработки данных внешних систем. Подготовка изменений графического интерфейса по требованиям Заказчика

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

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

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

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

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

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

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

3.4.1 Инцидент На рисунке 2 представлена функциональная схема регистрации и сопровождения обращений (заявок) типа «Инцидент». Рисунок 2 - Функциональная схема регистрации и сопровождения обращений (заявок) типа «Инцидент» 3.4.2 Запрос на обслуживание На рисунке 3 представлена функциональная схема регистрации и сопровождения обращения (заявки) типа «ЗНО». Рисунок 3 - Функциональная схема регистрации и сопровождения обращения (заявки) типа «ЗНО» 3.4.3 Запрос на изменение На рисунке 4 представлена функциональная схема регистрации и сопровождения обращений (заявок) типа «ЗНИ». Рисунок 4 - Функциональная схема регистрации и сопровождения обращений (заявок) типа «ЗНИ»

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

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

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

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

4 Формы обращений (заявок) на оказание услуг по технической поддержке Системы, заполняемые в СРО 4.1. Форма обращения (заявки) на оказание услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы При подаче обращения (заявки) типа «ЗНО» в СРО указывается (Таблица 5): Таблица 5 – Описание атрибутов формы обращения (заявки) на оказание услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 5) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 5) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 5) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 5) Категория обращения: информационно-консультационная поддержка Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 5) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 5) Текст запроса на оказание услуги по информационно-консультационной поддержке сотрудников Заказчика Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 5)

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

- 62.02.30.000 - Этап№2: Услуги по технической поддержке Модуля СЦ (с даты заключения контракта по 10.09.2026) ОКПД2: 62.02.30.000 ОПРЕДЕЛЕНИЯ, ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ Автоматизированная система (АС) Система, состоящая из комплекса средств автоматизации, реализующего информационную технологию выполнения установленных функций, и персонала, обеспечивающего его функционирование (ГОСТ Р 59853-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения») АРМ Автоматизированное рабочее место АСУ ТК, Система Информационно-аналитическая система регулирования на транспорте АТС Автоматическая телефонная станция БД База данных ГИС Государственная информационная система ГОСТ Государственный стандарт ГЦОД СИЦ Минтранса России, ГЦОД Головной центр обработки данных ФГБУ «СИЦ Минтранса России» Дашборд Интерактивная аналитическая панель, графический интерфейс. ЕИС Единая информационная система в сфере закупок ЕСИА Единая система идентификации и аутентификации Заказчик Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» КИИ Критическая информационная инфраструктура Кластер Кла?стер (англ. cluster) – объединение нескольких однородных элементов, которое может рассматриваться как самостоятельная единица, обладающая определёнными свойствами Компонент Часть АС, выделенная по определенному признаку или совокупности признаков и рассматриваемая как единое целое (ГОСТ Р 59853-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения») Контракт Контракт на выполнение работ по развитию и оказанию услуг по технической поддержке Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК в 2026 году, заключаемый по результатам проведения конкурентной процедуры закупки в соответствии с требованиями Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» ... 1. ОБЩИЕ СВЕДЕНИЯ 1.1. Наименование Системы Полное наименование системы: Информационно-аналитическая система регулирования на транспорте. Условное обозначение системы: АСУ ТК. Полное наименование модуля: Модуль сбора, ведения и анализа информации о нештатных ситуациях на транспорте. Условное обозначение модуля: Модуль СЦ. Модуль СЦ создан в рамках контракта от 05.08.2024 № ОК/24_04 на выполнение работ по развитию АСУ ТК в части создания модуля «Сбора, ведения и анализа информации о нештатных ситуациях на транспорте». Развитие Модуля СЦ осуществлено в рамках контракта от 19.05.2025 № ОК/25_09 на выполнение работ по развитию Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК ... 2. ЦЕЛИ И НАЗНАЧЕНИЕ ВЫПОЛНЕНИЯ РАБОТ 2.1. Назначение АСУ ТК АСУ ТК предназначена для автоматизации и информационно-аналитического обеспечения процессов управления развитием транспортного комплекса Российской Федерации, обеспечения публичности деятельности органов государственного управления транспортным комплексом. Основными целями АСУ ТК являются: – повышение эффективности процессов управления функционированием и развитием транспортного комплекса на основе создания единой информационной среды и комплекса информационно-аналитических услуг на уровне органов государственного управления ТК; – повышение уровня безопасности ТК на базе получения полной, достоверной и оперативной информации о происходящих изменениях, своевременного выявления негативных тенденций и для принятия соответствующих мер по их устранению и ликвидации последствий ... - Условная единица - 1,00 - 19 269 780,65 - 19 269 780,65

- Наименование характеристики Значение характеристики Единица измерения характеристики Инструкция по заполнению характеристик в заявке ОПРЕДЕЛЕНИЯ, ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ Автоматизированная система (АС) Система, состоящая из комплекса средств автоматизации, реализующего информационную технологию выполнения установленных функций, и персонала, обеспечивающего его функционирование (ГОСТ Р 59853-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения») АРМ Автоматизированное рабочее место АСУ ТК, Система Информационно-аналитическая система регулирования на транспорте АТС Автоматическая телефонная станция БД База данных ГИС Государственная информационная система ГОСТ Государственный стандарт ГЦОД СИЦ Минтранса России, ГЦОД Головной центр обработки данных ФГБУ «СИЦ Минтранса России» Дашборд Интерактивная аналитическая панель, графический интерфейс. ЕИС Единая информационная система в сфере закупок ЕСИА Единая система идентификации и аутентификации Заказчик Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» КИИ Критическая информационная инфраструктура Кластер Кла?стер (англ. cluster) – объединение нескольких однородных элементов, которое может рассматриваться как самостоятельная единица, обладающая определёнными свойствами Компонент Часть АС, выделенная по определенному признаку или совокупности признаков и рассматриваемая как единое целое (ГОСТ Р 59853-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения») Контракт Контракт на выполнение работ по развитию и оказанию услуг по технической поддержке Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК в 2026 году, заключаемый по результатам проведения конкурентной процедуры закупки в соответствии с требованиями Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» Значение характеристики не может изменяться участником закупки Модуль iМинтранс Модуль сбора данных и представления показателей деятельности Министерства транспорта Российской Федерации iМинтранс АСУ ТК Модуль СЦ Модуль сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК НС Нештатная ситуация НСИ Нормативно-справочная информация ОТИ Объект транспортной инфраструктуры П-ГИС Геоинформационная подсистема П-ИВ Подсистема информационного взаимодействия П-НСИ Подсистема ведения нормативно-справочной информации и метаданных ПО Программное обеспечение Подрядчик, Исполнитель Организация, с которой будет заключен контракт на выполнение работ по развитию Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК П-СД Подсистема сбора данных Работы Работы по развитию Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК СЗИ Средство защиты информации СМЭВ Система межведомственного электронного взаимодействия СУБД Система управления базами данных ТЗ Техническое задание (настоящий документ) ТС Транспортное средство ТК Транспортный комплекс Учреждение Учреждения в области информационной безопасности ФГБУ «СИЦ Минтранса России» Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации», Заказчик Федеральный закон № 44-ФЗ Федеральный закон от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» ФЗ Функциональная задача ФЗ «Реестр объектов» Функциональная задача «Формирование и ведение единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации» ФСБ России Федеральная служба безопасности Российской Федерации ФСТЭК России Федеральная служба по техническому и экспортному контролю ЧС Чрезвычайная ситуация ЭВМ Электронно-вычислительная машина API От англ. Application Programming Interface – интерфейс прикладного программирования – совокупность инструментов и функций в виде интерфейса для взаимодействия с программой CSS От англ. Cascading Style Sheets — каскадные таблицы стилей FPS От англ. frame per second - количество кадров в секунду HTML От англ. HyperText Markup Language - стандартный язык разметки документов, создающий основу и структуру всех веб-страниц JSON От англ. JavaScript Object Notation – текстовый формат обмена данными, основанный на JavaScript WebAssembly (Wasm) Открытый стандарт, представляющий собой низкоуровневый бинарный формат инструкций, который позволяет выполнять код, написанный на языках C++, Rust или Go, в браузерах с производительностью, близкой к нативной 1. ОБЩИЕ СВЕДЕНИЯ 1.1. Наименование Системы Полное наименование системы: Информационно-аналитическая система регулирования на транспорте. Условное обозначение системы: АСУ ТК. Полное наименование модуля: Модуль сбора, ведения и анализа информации о нештатных ситуациях на транспорте. Условное обозначение модуля: Модуль СЦ. Модуль СЦ создан в рамках контракта от 05.08.2024 № ОК/24_04 на выполнение работ по развитию АСУ ТК в части создания модуля «Сбора, ведения и анализа информации о нештатных ситуациях на транспорте». Развитие Модуля СЦ осуществлено в рамках контракта от 19.05.2025 № ОК/25_09 на выполнение работ по развитию Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК Значение характеристики не может изменяться участником закупки 1.2. Шифр темы или номер контракта Присваивается Заказчиком по результатам организации закупочных процедур. 1.2.1. Предмет контракта Выполнение работ по развитию Модуля СЦ. Код по ОКПД2: 62.01.11.000 – услуги по проектированию и разработке информационных технологий для прикладных задач и тестированию программного обеспечения. Оказание услуг по технической поддержке Модуля СЦ. Код по ОКПД2: 62.02.30.000 – услуги по технической поддержке информационных технологий. Выполнение работ по развитию Модуля СЦ предусмотрено с учетом ключевых результатов (ОКР) Ведомственной программы цифровой трансформации Минтранса России на 2026-2028 (далее - ВПЦТ Минтранса России) в составе мероприятия № 103.002 «АСУ ТК» ИТ расхода 103.26.000005 «Развитие Информационно-аналитической системы регулирования на транспорте (АСУ ТК)»: · «Обеспечено информационное взаимодействие с Минобороны о происшествиях на транспортных объектах»; · «Обеспечена автоматизация формирования отчетов о нештатных ситуациях на транспорте, в том числе по данным внешних систем». Выполнение работ по технической поддержке АСУ ТК предусмотрено ВПЦТ Минтранса России в составе мероприятия № 103.002 «АСУ ТК» ИТ расхода 103.26.000021 «Эксплуатация Информационно-аналитической системы регулирования на транспорте (АСУ ТК)» 1.3. Заказчик Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» (ФГБУ «СИЦ Минтранса России»). Адрес: 107078, Москва, Садовая-Спасская ул., д.18, стр. 1. Оператором Системы является Заказчик - Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» (ФГБУ «СИЦ Минтранса России) 1.4. Подрядчик Определяется по результатам проведения конкурентной процедуры закупки в соответствии с требованиями Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (далее – Федеральный закон № 44-ФЗ) 1.5. Основания для выполнения работ Работы осуществляются на основании следующих документов: – постановление Правительства Российской Федерации от 30.12.2003 № 794 «О единой государственной системе предупреждения и ликвидации чрезвычайных ситуаций»; – постановление Правительства Российской Федерации от 08.11.2013 № 1007 «О силах и средствах единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций»; – распоряжение Правительства Российской Федерации от 27.11.2021 № 3363-р «О Транспортной стратегии Российской Федерации до 2030 года с прогнозом на период до 2035 года»; – Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 26.08.2025 №ЕФ-3; – Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 27.11.2025 №ЕФ-23; – Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 19.02.2026 №ЕФ-1; – План мероприятий по профилактике случаев непроизводственного травматизма граждан на железнодорожном транспорте, являющийся приложением к постановлению коллегии Министерства транспорта Российской Федерации от 11.03.2026 № 2 1.6. Перечень документов, требования которых должны быть учтены при выполнении работ – Федеральный закон Российской Федерации от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации»; – Федеральный закон Российской Федерации от 27.07.2006 № 152-ФЗ «О персональных данных»; – Федеральный закон Российской Федерации от 06.04.2011 № 63-ФЗ «Об электронной подписи»; – Федеральный закон Российской Федерации от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации»; – Указ Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации»; – Указ Президента Российской Федерации от 01.05.2022 № 250 «О дополнительных мерах по обеспечению информационной безопасности Российской Федерации»; – Указ Президента Российской Федерации от 31.03.2010 № 403 «О создании комплексной системы обеспечения безопасности населения на транспорте»; – постановление Правительства Российской Федерации от 30.07.2004 № 395 «Об утверждении Положения о Министерстве транспорта Российской Федерации»; – постановление Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации»; – постановление Правительства Российской Федерации от 16.11.2015 № 1236 «Об установлении запрета на допуск программного обеспечения, происходящего из иностранных государств, для целей осуществления закупок для обеспечения государственных и муниципальных нужд»; – постановление Правительства Российской Федерации от 23.12.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 Федерального закона «Об электронной подписи»; – постановление Правительства Российской Федерации от 08.06.2011 № 451 «Об инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг и исполнения государственных и муниципальных функций в электронной форме»; – постановление Правительства Российской Федерации от 30.01.2013 № 62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин»; – приказ ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации»; – приказ ФСТЭК России от 11.04.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений»; – приказ ФСБ России от 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.7. Сроки начала и окончания работ Начало работ: с даты заключения Контракта. Окончание работ: не позднее 15.12.2026. Работы выполняются в соответствии с этапами. Сроки выполнения этапов работ по развитию и технической поддержке Модуля СЦ определяются Календарным планом. Календарный план, приведен в разделе 5 настоящего ТЗ 1.8. Общие сведения об источниках и порядке финансирования работ Источником финансирования являются средства субсидии федерального бюджета Российской Федерации, предоставленной в соответствии с абзацем вторым пункта 1 статьи 78.1 Бюджетного кодекса Российской Федерации (код цели 08-01) 1.9. Порядок оформления и предъявления результатов работ Подрядчик должен передать Заказчику результаты работ в порядке, определенном Контрактом в сроки, установленные п. 5 настоящего ТЗ, в соответствии с Календарным планом 1.10. Место выполнения Работ Работы выполняются удаленно на комплексе технических средств Заказчика. Адрес размещения комплекса технических средств Заказчика: Московская обл., Богородский район, пос. Горбуша, Радиоцентр. Техническая возможность удаленного подключения обеспечивается Заказчиком (в части предоставления параметров доступа). Оплата телематических и иных услуг, технических и программных средств, необходимых Подрядчику для удаленного подключения и для выполнения требований по информационной безопасности, осуществляется Подрядчиком самостоятельно за свой счет 2. ЦЕЛИ И НАЗНАЧЕНИЕ ВЫПОЛНЕНИЯ РАБОТ 2.1. Назначение АСУ ТК АСУ ТК предназначена для автоматизации и информационно-аналитического обеспечения процессов управления развитием транспортного комплекса Российской Федерации, обеспечения публичности деятельности органов государственного управления транспортным комплексом. Основными целями АСУ ТК являются: – повышение эффективности процессов управления функционированием и развитием транспортного комплекса на основе создания единой информационной среды и комплекса информационно-аналитических услуг на уровне органов государственного управления ТК; – повышение уровня безопасности ТК на базе получения полной, достоверной и оперативной информации о происходящих изменениях, своевременного выявления негативных тенденций и для принятия соответствующих мер по их устранению и ликвидации последствий Значение характеристики не может изменяться участником закупки Основными задачами АСУ ТК являются: – автоматизация процессов прогнозирования развития транспортного комплекса и поддержки принятия управленческих решений; – автоматизация процессов мониторинга безопасности и устойчивости транспортного комплекса, управления в чрезвычайных и нештатных ситуациях; – автоматизация процессов управления программами и проектами развития и модернизации транспортного комплекса; – автоматизация процессов мониторинга состояния транспортного комплекса, в том числе с использованием набора ключевых показателей эффективности деятельности транспортного комплекса; – информационно-технологическая поддержка взаимодействия субъектов транспортного комплекса Российской Федерации, органов государственного управления и контроля, международных организаций на основе создания единой технологической среды взаимодействия и управления движением данных (и связанных с ними документов) в транспортном комплексе; – использование в процессах управления транспортным комплексом РФ современных технологий электронного документооборота и электронного обмена данными; – организация межведомственного электронного взаимодействия подразделений Министерства транспорта Российской Федерации, подведомственных агентств и службы с другими организациями 2.2. Назначение и цели развития и технической поддержки Модуля СЦ Назначение Модуля СЦ: – оперативный мониторинг нештатных и чрезвычайных ситуаций на транспорте ; – оповещение заинтересованных лиц и структур о нештатных и чрезвычайных ситуациях; – сбор, обработка и хранение данных о нештатных и чрезвычайных ситуациях. Целями развития Модуля СЦ являются: – расширение состава данных об оперативной обстановке на транспорте; – оптимизация процесса сбора данных об оперативной обстановке на транспорте; – повышение информированности пользователей за счет визуализация данных Модуля СЦ; – автоматизация процесса формирования отчетов о ЧС и нештатной ситуации на транспорте; – обеспечение информационного взаимодействия с заинтересованными организациями по вопросам ведения. Целями оказания услуг по технической поддержке являются: – обеспечение информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы; – поддержание параметров функционирования ППО Системы, удовлетворяющих требованиям производственных процессов, включая их непрерывность; – обеспечение бесперебойного функционирования ППО и своевременное устранение сбоев и аварийных ситуаций в Системе; – своевременное устранение уязвимостей при выявлении таковых, в соответствии с требованиями к обеспечению информационной безопасности; – адаптация, конфигурирование, коррекция программного обеспечения в соответствии с изменениями нормативно-правовой базы и запросами уполномоченных сотрудников органов государственной власти, включая выполнение процедур тестирования и участие в обновлениях ППО на стендах Заказчика; – обеспечение сохранения работоспособности ППО в изменяемой среде эксплуатации; – ведение документации по настоящему ТЗ, инициирование и актуализация документации на Систему по результатам обработки запросов Заказчика и внесении соответствующих изменений в ППО. Модуль СЦ применяется в деятельности Министерства транспорта Российской Федерации, подведомственных агентств и службы и другими организациями в соответствии с соглашениями об информационном обмене 3. ХАРАКТЕРИСТИКА ОБЪЕКТА АВТОМАТИЗАЦИИ 17 Модуль ГЭТ Модуль предназначен для получения, хранения данных инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по отдельно взятому предприятию-перевозчику. Формирования отчетов об инвентаризации с детальными данными по каждому разделу инвентаризации с маршрутизацией в муниципалитет / регион / Минтранс. Содержит агрегированные данные инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по всем перевозчикам, относящихся к данному муниципалитету. Формирует сводный отчет по муниципалитету по каждому разделу инвентаризации с маршрутизацией в регион / Минтранс. Формирует агрегированные данные инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по всем перевозчикам, относящиеся к данному региону и по всем муниципалитетам, относящимся к данному региону. Аналитические и статистические данные о состоянии ГЭТ региона. Содержит данные о видах транспорта, цифровых транспортных сервисах и платежных инструментах Региона. Формирует сводный отчет по каждому разделу инвентаризации с маршрутизацией в Минтранс. Формирует агрегированную статистику и аналитику по всем регионам страны в разрезе транспортных средств, маршрутов, пассажиропотоков, инфраструктуры ГЭТ. Данные о рейтинге регионов и перевозчиков на основании выбранных параметров, документооборот с участниками Системы: получение подписанных печатных форм, их утверждение, возврат на доработку. 18 Модуль iМинтранс Модуль создан для отчета по ключевым показателям транспортного комплекса России (Отраслевые и статистические показатели, исполнение бюджета, исполнение поручений, аналитика СМИ, происшествия по видам транспорта). 19 Модуль СЦ Модуль СЦ предназначен для оперативного мониторинга нештатных ситуаций транспортной отрасли, оповещения заинтересованных лиц и структур и предоставления данных о нештатных ситуациях Значение характеристики не может изменяться участником закупки АСУ ТК осуществляет идентификацию и авторизацию посредством Единой системы идентификации и аутентификации (ЕСИА). Информационный обмен с внешними информационными системами осуществляется посредством СМЭВ 3 и СМЭВ 4. АСУ ТК развернута на вычислительных мощностях ГЦОД СИЦ Минтранса России 3.2. Описание и текущее состояние объекта автоматизации Модуля СЦ Объектом автоматизации является процесс организации мониторинга информации о НС и ЧС на транспорте. Предметом деятельности Учреждения являются следующие функции: – информационное обеспечение в области транспортной безопасности, защиты населения и территорий от чрезвычайных ситуаций природного и техногенного характера в транспортном комплексе; – подготовка справочных материалов при угрозе возникновения и возникновении чрезвычайных ситуаций и иных происшествий в транспортном комплексе; – взаимодействие и обмен оперативной информацией с органами управления Единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций; – организация оперативного мониторинга обстановки на объектах транспорта при угрозе и возникновении чрезвычайных ситуаций и иных происшествий. Перечень компонентов Модуля СЦ и выполняемые ими функции представлены в Таблице 2 Таблица 2. Перечень компонентов Модуля СЦ и их функции № п/п Компонент Выполняемые функции 1 Регистрация событий – ведение карточки события; – удаление комментария; – динамическое отображение существующих событий в заданном радиусе и за заданный период; – возможность автоматической проверки вводимых данных в части количества пострадавших; – отображение карточки ОТИ, ТС в соответствии с ФЗ Реестр объектов; – сохранение и отображение версии карточки события; – привязка события к координатам по картографической основе; – указание признака выполнения действия по отработке события; – перевод статуса события; – закрытие карточки события; – публикация информации о событии в канале мессенджера; – возможность перехода из карточки события на картографическую основу для просмотра местоположения события 2 Визуализация – отображение событий на картографической основе в виде пиктограмм; – масштабирование карты; – отображение краткой карточки события при выборе события на картографической основе; – отображение списка событий; – отображение карточки события; – отображение журнала действий пользователя; – отображение дополнительной информации (текстовая информация и приложенные файлы); – отображение справки о событиях и отчета о событиях; – отображение фильтров и количества отфильтрованных объектов; – отображение результатов поиска; – отображение статистики по событиям на экране; – возможность создания события с картографической основы; – отображения картографических слоев в зависимости от примененных фильтров; – возможность настройки шага картографической сети; – возможность настройки географической точки центра карты; – отображение количества непрочитанных сообщений; – возможность перехода к детальной карточке события из краткой карточки события при выборе события на картографической основе 3 Информирование – ведение справочника способов оповещения (веб-интерфейс, мессенджер); – формирование сценария выполнения оповещения (настройка условий, способа, параметров оповещения); – выполнение оповещений пользователей 4 Отчетность – формирование отчета и справки о событиях; – фильтрация событий для выгрузки в справку о событиях или в отчет о событиях 5 Администрирование – ведение ролей пользователей; – ведение учетных данных пользователей; – ведение справочника организаций; – ведение справочника групп системы мгновенного обмена сообщениями; – выполнение исходящего звонка на контактный телефонный номер организации; – формирование матрицы эскалации событий Архитектура Модуля СЦ представлена на рисунке 1. Рисунок 1. Архитектура Модуля СЦ 3.3. Состав используемого ПО Модуля СЦ Программная архитектура Модуля СЦ разработана как трехуровневая клиент-серверная архитектура. Архитектура включает в себя следующие уровни: • уровень представления – презентационный уровень, обеспечивающий взаимодействие с пользователя с клиентскими приложениями с использованием веб-браузера («тонкий» клиент); • уровень приложений – реализован в виде сервисов, обеспечивает обработку запросов, поступающих от клиентских приложений, формирование ответов на запрос в доступном пользователю виде (формирование пользовательских интерфейсов); • уровень хранения данных – реализуется как сервер БД и обеспечивает хранение и целостность хранимых данных, создание резервных копий, ведение журнала транзакций, восстановление данных после сбоев. Программная архитектура Модуля СЦ включает в себя сервисы и интерфейсы, указанные в Таблице 3. Таблица 3. Программная архитектура Модуля СЦ Программный сервис/интерфейс Технологии реализации Уровень представления Интерфейс пользователя и администратора (front-end) Javascript Уровень приложений Сервис (GateWay) Kotlin Сервис геокодирования (geocoding-service) Kotlin Сервис уведомлений (notifiсation-service) Kotlin Сервис работы с файлами (file-service) Kotlin Сервис отчетности (report-service) Kotlin Сервис управления событиями (event-service) Kotlin Сервис информирования через мессенджер (messenger-notifier) Python Сервис внешних интеграций (integration-service) Сбор информации из внешних систем и сервисов Брокер сообщений Kafka Уровень хранения данных Файловое хранилище MinIO S3 СУБД Postgres Pro Enterprise 3.4. Информационное взаимодействие программных сервисов и интерфейсов Модуля СЦ Объект автоматизации функционирует в распределенной информационной среде. Обмен данными осуществляется по защищенным каналам связи (в том числе ведомственным сетям передачи данных). Источники информации включают: · внешние автоматизированные системы (органов государственной власти); · внутренние базы данных (реестры объектов транспортной инфраструктуры, паспорта регионов и пр.); · оперативная информация от персонала, поступающая через автоматизированные рабочие места (АРМ) и мобильные устройства. 3.4.1. Взаимодействие Модуля СЦ со смежными подсистемами АСУ ТК Модуль СЦ входит в состав АСУ ТК и взаимодействует со следующими ее функциональными задачами и подсистемами: · Функциональной задачей «Формирование и ведение единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации» (ФЗ «Реестр объектов»); · Геоинформационной подсистемой АСУ ТК (П-ГИС); · Подсистемой ведения нормативно-справочной информации и метаданных (П-НСИ); · Подсистемой сбора данных и централизованное хранилище данных (П-СД); · Подсистемой информационного взаимодействия (П-ИВ). 3.4.2. Взаимодействие с внешними информационными системами Список внешних информационных систем, с которыми осуществляется взаимодействие Модуля СЦ: · ЕСИА; · мессенджер; · Яндекс Геокодер; · Информационная система «Централизованная система сбора информации систем-112»; · ПВК «Поиск-Море», АИС РПТ; · облачная АТС 3.5. Требования к эксплуатации Применяемое в Системе программное обеспечение, программно-аппаратные и аппаратные комплексы должны соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации» 3.1. Описание объекта автоматизации АСУ ТК Объектом автоматизации являются процессы основной и обеспечивающей деятельности, направленные на управление транспортным комплексом, в том числе, процессы информационного взаимодействия с другими организациями и субъектами транспортного комплекса. АСУ ТК относится к государственным информационным системам, а также к информационным системам персональных данных и значимым объектам критической информационной инфраструктуры Российской Федерации. АСУ ТК соответствует требованиям, предъявляемым к: – ГИС второго класса защищенности в соответствии с приказом ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах»; – ИС персональных данных при обеспечении третьего уровня защищенности персональных данных в соответствии с требованиями постановления Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»; – значимым объектам КИИ Российской Федерации второй категории значимости с постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении Правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений». Модуль СЦ является подсистемой АСУ ТК. Перечень платформенных решений и функциональных задач АСУ ТК представлен в Таблице 1 Таблица 1 – Перечень платформенных решений и функциональных задач АСУ ТК № Наименование подсистемы/ функциональной задачи/ модуля Назначение 1 Подсистема сбора данных и централизованного хранилища данных Подсистема обеспечивает выполнение сбора данных в АСУ ТК, и в т. ч., в рамках функциональных задач «Формирование и ведение межрегионального транспортного баланса пассажирских перевозок в дальнем (межрегиональном) сообщении» и «Формирование и ведение транспортного паспорта региона» 2 Подсистема информационного взаимодействия Подсистема информационного предназначена для обеспечения информационного взаимодействия подсистем АСУ ТК, а также, взаимодействия АСУ ТК с АС федеральных органов исполнительной власти 3 Подсистема ведения нормативно-справочной информации и метаданных Подсистема предназначена для автоматизации функций формирования и актуализации справочников, классификаторов, реестров и регистров, необходимых для обеспечения информационной поддержки пользователей НСИ и интеграции подсистем АСУ ТК в части применения НСИ 4 Модуль СМЭВ Модуль взаимодействия со СМЭВ представляет собой набор сервисов взаимодействия: сервис синхронного взаимодействия и сервис отправки, осуществляющих дополнительную обработку сообщений, отправляемых в СМЭВ и принимаемых из СМЭВ 5 Геоинформационная подсистема Программное обеспечение геоинформационной подсистемы предназначено для обеспечения смежных подсистем АСУ ТК возможностью работы с картографической информацией, в том числе, отображения на электронных картах объектов транспортной инфраструктуры и получения информации о местоположении, характеристиках контролируемых транспортных объектов 6 Подсистема информационного портала АСУ ТК Подсистема информационного портала предназначена для отображения и входа в функциональные задачи АСУ ТК 7 Подсистема технического портала АСУ ТК Подсистема технического портала АСУ ТК предназначена для управления заявками пользователей и технологического документооборота заявок 8 Подсистема проектного архива АСУ ТК Подсистема проектного архива АСУ ТК предназначена для автоматизации деловых процессов должностных лиц Министерства транспорта Российской Федерации, подведомственных агентств и службы, в том числе, и процессов информационного взаимодействия внутреннего и внешнего характера 9 ФЗ «Реестр объектов» Функциональная задача предназначена для формирования и ведения единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации 10 ФЗ «СТП» Функциональная задача предназначена для организации информационно-аналитической поддержки процессов территориального планирования Российской Федерации в области федерального транспорта 11 ФЗ «МРТБ ПП» Функциональная задача предназначена для формирования и ведения межрегионального транспортного баланса пассажирских перевозок в дальнем (межрегиональном) сообщении 12 ФЗ «МДД» Функциональная задача предназначена для осуществления мониторинга дорожного движения 13 ФЗ «ТПР» Функциональная задача предназначена для формирования и ведения транспортного паспорта региона 14 ФЗ «Данные по грузообороту» Функциональная задача предназначена для обеспечения подсистем и пользователей АСУ ТК данными по грузообороту между Российской Федерацией и зарубежными странами 15 ФЗ «МЖТ» Функциональная задача предназначена для осуществления мониторинга железнодорожного транспорта 16 ФЗ «МГМП» Функциональная задача предназначена для осуществления мониторинга грузопотоков в морских портах с целью формирования единой цифровой среды мониторинга и планирования перевозок в/из портов Дальнего Востока 4. ТРЕБОВАНИЯ К МОДУЛЮ СЦ 4.3.6.4.1. Требования к проведению изменений Основанием для внесения изменений является запрос от Заказчика. Все активности по внесению изменений должны быть согласованы с Заказчиком, а действия Подрядчика при оказании данной услуги должны быть зафиксированы. В рамках данного Технического задания изменениями считаются локальные доработки функционала Модуля СЦ, которые не должны приводить к необходимости выполнения дополнительных аттестационных испытаний или переаттестации АСУ ТК в соответствии с п. 33 приказа от 29.04.2021 № 77 «Об утверждении Порядка организации и проведения работ по аттестации объектов информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну». При необходимости внесения изменений в Модуль СЦ, не связанных с критичным инцидентом, существенно нарушающим работоспособность Модуля СЦ, Заказчик направляет Подрядчику обращение (заявку), в котором излагает суть изменения, которое требуется внести в Модуль СЦ. Исполнитель, в течение 3 (трех) рабочих дней с момента поступления соответствующего обращения (заявки), оценивает техническую возможность реализации запрашиваемого изменения и варианты реализации. По итогу проведения оценки Подрядчик направляет Заказчику заключение о возможности реализации данного изменения с описанием возможных вариантов реализации и согласует с Заказчиком проведение данного изменения Значение характеристики не может изменяться участником закупки При проведении работ по изменению и адаптации Подрядчик должен: – обеспечить выполнение требований безопасной разработки программного обеспечения; – обеспечить предварительное проектирование технических решений и согласование с Заказчиком проекта реализации изменения; – использовать семантическое версионирование (SemVer) в работе, передать Заказчику все артефакты разработки (исходный код и сторонние библиотеки, конфигурации, сборочные и собранные образы и др.); – подготовить полноценное описание функционала, включенного в релиз, с необходимыми схемами и пояснениями к обновлению на стендах Заказчика; – обеспечить тестирование разработанного функционала на стендах Заказчика силами Подрядчика; – решение о переносе измененного ППО на продуктивный стенд принимается Заказчиком по итогу результатов проведенного тестирования; – обеспечить техническое сопровождение процедуры тестирования ППО и переноса измененного ППО на продуктивный стенд Заказчика; – обеспечить экстренное внесение соответствующих изменений в случае выявления некорректной работы продуктивного стенда Заказчика после проведения обновления по итогам разработанного изменения в кратчайшие сроки; – актуализировать при необходимости комплект эксплуатационной документации: o руководство пользователя; o руководство администратора; o иные документы (при необходимости). Результат выполнения изменений должен быть отражен в Отчете по оказанию услуг. Типы и приоритеты изменений могут быть скорректированы в процессе оказания услуг исключительно по согласованию с Заказчиком 4.3.6.4.2. Требования к изменению настроек функционирования Изменение настроек функционирования может проводиться в рамках допустимых пределов изменения функционирования, заложенных в архитектуру Модуля СЦ. Изменение настроек функционирования включает в себя изменение данных и справочников, изменение форм документов, формируемых Модулем СЦ, изменение и настройку форматов и версий передачи данных в смежные системы. Доработка программного кода Модуля СЦ может допускаться (в случае необходимости) при выполнении работ по адаптации функций Модуля СЦ в части изменения формата передачи данных в смежные информационные системы при условии соблюдения требований пункта 29.3 приказа ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации» 4.3.6.5. Требования к услугам по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности По запросу Заказчика Подрядчик должен провести работу по приведению ППО в соответствие с требованиями по обеспечению информационной безопасности. Критичность уязвимости оценивается в соответствии в соответствии с Методическим документом ФСТЭК России «Методика оценки уровня критичности уязвимостей программных, программно-аппаратных средств» (утвержден ФСТЭК России 30.06.2025), а также с учетом ГОСТ 56545-2015 и международными стандартами (CVSS 3.0 и выше), и задает необходимый срок устранения. В процессе проведения Заказчиком обследования Модуля СЦ и выявления уязвимостей в ППО, связанных с исходным кодом Модуля СЦ и/или используемыми компонентами (библиотеками), Заказчик направляет Подрядчику обращение (заявку) на устранение, с указанием критичности и срочности принятия мер по устранению в СРО. Подрядчик при оказании услуг по обновлению или устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности должен: – провести анализ уязвимостей и связанных с ними исходным кодом и/или используемыми компонентами (библиотеками); – выработать варианты устранения указанных уязвимостей и согласовать с Заказчиком их реализацию; – своевременно внести изменения в исходный код Модуля СЦ и/или используемые компоненты (библиотеки) и подготовить соответствующее обновление; – провести обновление Модуля СЦ в тестовом контуре Заказчика и проинформировать Заказчика о готовности проведения тестирования; – протестировать успешность обновления или устранения уязвимостей в ППО и корректность функционирования Модуля СЦ на тестовом контуре, совместно с Заказчиком; – при невозможности незамедлительного устранения уязвимости приоритетов «Критический» и «Высокий» Подрядчик обязан предоставить исчерпывающий список причин и согласовать план достаточных компенсирующих мер с ответственными сотрудниками Заказчика. Результат внесения изменений отображается в соответствующей записи в СРО и в составе Отчета об оказанных услугах 4.3.6.5.1. Требования к порядку оказания услуг по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности Подрядчик в соответствии с приоритетами обращений и контрольными сроками исполнения (см. Приложение Б к ТЗ) оценивает техническую возможность и сроки устранения уязвимостей, и реализацию обновления Модуля СЦ. По итогу проведения оценки Подрядчик направляет в заявке СРО Заказчику заключение о возможности устранения уязвимостей и/или обновления в ППО и согласует с Заказчиком проведение данных работ При проведении работ по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности необходимо выполнить следующее: – Заказчику сформировать заявку на устранение (обновление) в СРО с полным списком обнаруженных уязвимостей и планируемыми работами; – согласовать в рабочем порядке время начала и завершения работ, перечень работ, выполняемых в рамках обновления или устранения уязвимостей в ППО с Заказчиком; – оповестить Заказчика о начале проведения работ на тестовом контуре; – провести работы по обновлению или устранению уязвимостей в ППО на тестовом контуре Модуля СЦ в установленные сроки; – протестировать выполнение работ в тестовом контуре и проинформировать Заказчика о готовности переноса ППО на продуктивный контур; – силами Заказчика обновить продуктивный контур Модуля СЦ, в соответствии с планом устранения и выполненными работами; – совместно с Заказчиком проверить корректность функционирования Модуля СЦ и устранения уязвимостей в продуктивном контуре Модуля СЦ по результатам обновления; – при необходимости актуализировать документацию (описание архитектуры, анкеты постановки на мониторинг и иные документы). Любые изменения в части обновления или устранения уязвимостей в ППО на промышленном контуре Модуля СЦ должны применяться только в случае успешного проведения аналогичных работ на тестовом контуре. Детальный порядок оказания услуги по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности определен в Регламенте оказания Услуг 4.4. Требования к видам обеспечения 4.4.1. Требования к лингвистическому обеспечению Документация на Модуль СЦ должна разрабатываться на русском языке. Взаимодействие пользователей с Модулем СЦ посредством графического интерфейса должно происходить на русском языке за исключением сообщений, зависящих от настроек системного программного обеспечения, установленного на рабочих местах пользователей. При разработке программных решений Модуля СЦ должно быть предусмотрено использование языков программирования высокого уровня, приведенных в Таблице 7. Таблица 7. Языки и средства разработки, специального программного обеспечения Модуля СЦ Категория Наименование Назначение Языки программирования Kotlin Разработка серверной логики и сервисов (backend) JavaScript / TypeScript Разработка клиентской части (frontend) Python Разработка скриптов интеграции, обработки данных и автоматизации Фреймворки и библиотеки Vue.JS Разработка пользовательских интерфейсов (веб-интерфейсы компонентов визуализации и отчетности) React Разработка пользовательских интерфейсов (при необходимости создания сложных интерактивных компонентов) Решения по лингвистическому обеспечению, включая перечень используемых языков программирования, должны быть согласованы с Заказчиком на этапе технического проектирования 4.4.2. Требования к математическому обеспечению Требования к математическому обеспечению не предъявляются. 4.4.3. Требования к метрологическому обеспечению Требования к метрологическому обеспечению не предъявляются. 4.4.4. Требования к организационному обеспечению Требования к организационному обеспечению не предъявляются. 4.4.5. Требования к методическому обеспечению Задачи методического обеспечения Модуля СЦ должны быть обеспечены за счет использования технологических и методических документов касающихся вопросов функционирования транспортного комплекса и разработки и эксплуатации ПО. 4.4.6. Требования к информационному обеспечению Состав, структура и способы организации информационного обеспечения в Модуле СЦ должны быть определены на этапе технического проектирования. Факты информационного обмена с внешними системами должны фиксироваться в соответствующем журнале Технические меры по обеспечению надежности должны предусматривать: – резервирование критически важных компонентов и данных Системы и отсутствие единой точки отказа; – использование программного резервирования (программной избыточности); – изменение конфигурации используемых средств и применение специализированного ПО, обеспечивающего высокую надёжность. Организационные меры по обеспечению надежности должны быть направлены на минимизацию ошибок пользователей (а также обслуживающего персонала при эксплуатации и проведении работ по обслуживанию), минимизацию времени ремонта или замены вышедших из строя компонентов за счёт: – обеспечения для обслуживающего персонала требуемого уровня квалификации; – регламентации и нормативного обеспечения выполнения работ обслуживающим персоналом; – своевременной диагностики неисправностей. Расчетное значение коэффициента доступности Модуля СЦ должно составлять не менее 0,95. 4.5.3. Требования по диагностированию Модуля СЦ Диагностирование Модуля СЦ должно осуществляться путем анализа записей в системных журналах СУБД, операционных систем серверов, а также с помощью встроенных средств диагностирования общего программного обеспечения Модуля СЦ. Диагностированию подлежат: – сбои и нарушения функционирования технического обеспечения (серверов) Модуля СЦ; – сбои и нарушения функционирования системного программного обеспечения серверов, используемых для работы Модуля СЦ; – сбои и нарушения функционирования прикладного программного обеспечения серверов, используемых для работы Модуля СЦ; – случаи недоступности (отсутствия ответа) или некорректные ответы внешних систем; – сбои и нарушения функционирования СУБД; – сбои при выполнении регламентных операций резервного копирования. При возникновении аварийных ситуаций либо ошибок в программном обеспечении диагностические инструменты должны позволять сохранять набор информации, необходимой для идентификации и устранения проблемы. Модуль СЦ и ее компоненты должны обеспечивать возможность диагностики своей работоспособности с возможностью интеграции с модулем мониторинга АСУ ТК. Набор передаваемых журналов и метрик должен быть определен на этапе технического проектирования 4.5.4. Требования к надежности Должно быть предусмотрено сохранение работоспособности Модуля СЦ при некорректных действиях пользователя и сохранение целостности данных при нештатном завершении работы Модуля СЦ (отказ рабочей станции, потеря сетевого доступа и т.п.). Модуль СЦ должен предоставлять механизмы обеспечения сохранности данных через применение процедур резервного копирования и восстановления, описанных в документации на Систему. Ключевые показатели надежности информационной системы — допустимое время на восстановление работоспособности Модуля СЦ (RTO - recovery time objective) и/или допустимый интервал времени потери изменений в данных при сбоях/отказах (RPO – recovery point objective) должны быть определены Подрядчиком и согласованы с Заказчиком на этапе технического проектирования 4.1. Требования к структуре Модуля СЦ В процессе работ по развитию Системы должны сохраниться основные требования к построению архитектуры Системы в соответствии с принципами трехуровневой архитектуры: 1. уровень хранения данных или уровень базы данных (сервер СУБД); 2. уровень сервера приложений (сервер аналитической обработки); 3. презентационный уровень, обеспечивающий взаимодействие с клиентскими приложениями. В состав Системы должны входить следующие основные компоненты: 4. сервер баз данных; 5. сервер приложений; 6. веб-сервер. Сервер баз данных должен обеспечивать хранение и целостность хранимых данных, создание резервных копий, ведение журнала транзакций, восстановление данных после сбоев. Сервер приложений должен обеспечивать обработку запросов, поступающих от клиентских приложений (через веб-сервер), формирование ответов на запрос в доступном пользователю виде (формирование пользовательских интерфейсов). Веб-сервер должен обеспечивать взаимодействие с оператором и внешними системами по HTTP / HTTPS протоколу в режиме «запрос-ответ» (получения запросов от пользователя и передачи ответа в виде соответствующей информации, обработанной серверами приложений). Взаимодействие Системы с пользователем должно отвечать требованиям модели «тонкого клиента» (т.е. представлять на стороне клиента (пользователя) лишь графический пользовательский интерфейс). Все составляющие Системы должны использовать единую методологию и отвечать единым принципам взаимодействия, надежности и управления. Перечень компонентов Модуля СЦ представлен в Таблице 4. Таблица 4. Перечень компонентов Модуля СЦ, в отношении которых выполняются работы по развитию № п.п. Наименование компонента Модуля СЦ Раздел ТЗ 1 Компонент регистрации событий 4.2.1. 2 Компонент отчетности 4.2.2 3 Компонент визуализации 4.2.3 4 «Интерактивная карта» (компонент создается) 4.2.4 5 Компонент администрирования 4.2.5 4.2. Требования к дорабатываемым функциям модуля СЦ 4.2.1. Развитие компонента регистрации событий (1 очередь) Должны быть выполнены следующие доработки: – обеспечение логирования действий пользователя, связанных с карточкой события; – доработка объектной модели в части создания новых типов сущностей (карточек) с учетом реализуемых интеграций с информационными ресурсами (силы и средства предупреждения и ликвидации ЧС и нештатных ситуаций на транспорте, ТС, ограничения воздушного пространства, неблагоприятные и опасные природные явления); – реализация механизма установления связи между сущностями в Модуле СЦ автоматизированным и ручным способами (события, природные явления, силы и средства предупреждения и ликвидации ЧС и нештатных ситуаций на транспорте, ограничения воздушного пространства, ОТИ, ТС и др.); – отображение в карточке установленных связей между сущностями. 4.4.7. Требования к программному обеспечению Общесистемное ПО, используемое в составе Модуля СЦ, должно быть зарегистрировано в Едином реестре российских программ для электронных вычислительных машин и баз данных и соответствовать рекомендованным показателям эффективности и соответствующим им значениям индикаторов эффективности перехода подведомственных организаций на использование российского ПО, заданных Приказом Минцифры России от 18.01.2023 № 21 «Об утверждении методических рекомендаций по переходу на использование российского программного обеспечения, в том числе на значимых объектах критической информационной инфраструктуры Российской Федерации, и о реализации мер, направленных на ускоренный переход органов государственной власти и организаций на использование российского программного обеспечения в Российской Федерации». Применяемое в системе программное обеспечение должно соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации, постановления Правительства Российской Федерации от 23 декабря 2024 г. № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц» Прикладное программное обеспечение должно отвечать следующим требованиям: – совместимость программных продуктов в части используемых технических средств, системного программного обеспечения и общесистемной инфраструктуры в пределах требований к техническому обеспечению, а также их информационная совместимость в пределах требований к информационному обмену; – обеспечение трехуровневой архитектуры с разделением на уровень хранения данных (сервер БД), уровень бизнес-логики (сервер приложений) и уровень представления ( 4.4.7.1. Требования к инструментам разработки и процессу контроля версий программного обеспечения 4.4.7.1.1. Система контроля версий Для управления исходным кодом должна использоваться система контроля версий кода, развернутая в инфраструктуре Заказчика. 4.4.7.1.2. Правила именования веток Имя ветки должно соответствовать следующему формату: / / Категории веток: ? feature/ — разработка новой функциональности, а также рефакторинг или удаление существующей; ? fix/ — исправление ошибок; ? hotfix/ — срочные исправления, применяемые в обход стандартного процесса разработки; ? test/ — для проведения экспериментов, не влияющих на основную разработку. Идентификатор задачи: после категории указывается ссылка на задачу (issue) в системе контроля версий кода. Описание: добавляется краткое описание решаемой задачи в формате kebab-case (слова разделяются дефисами, например, add-user-auth). Примеры именования веток: ? feature/#123/add-payment-integration; ? fix/#45/correct-calculation-logic; ? hotfix/#67/urgent-database-connection-patch. 4.4.7.1.3. Правила именования коммитов Сообщение коммита должно соответствовать соглашению Conventional Commits и состоять из категории и описания: : ? fix — исправление ошибки. Примеры сообщений коммитов: ? feat: добавление формы регистрации пользователя; ? fix: исправление ошибки валидации email-адреса; ? refactor: оптимизация алгоритма сортировки данных; ? chore: обновление версий в файле dependencies. 4.4.7.1.4. Модель ветвления В процессе разработки используются следующие основные ветви: ? main / master — стабильная ветка, содержит только код, прошедший полное тестирование и развернутый в продуктивных контурах; ? dev — ветка для интеграции завершенных задач, предназначенная для сборки и тестирования в тестовых средах. Попадание кода в main осуществляется только через Merge Request (MR) из dev 4.5.5. Требования к информационной безопасности Работы по защите информации/информационной безопасности, не включенные в состав настоящего раздела, требуемые в соответствии с требованиями постановления Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации», а также нормативно правовых актов в области защиты персональных данных и обеспечения безопасности объектов критической информационной инфраструктуры, будут проведены в рамках исполнения отдельного контракта, заключенного по результатам отдельной закупочной процедуры (не является частью данного ТЗ), включающего: – определение актуальных угроз безопасности информации и актуализация модели угроз безопасности информации (при необходимости); – выполнение требований о согласовании технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России в установленном порядке; – выполнение требований по устранению Подрядчиком замечаний и недостатков, в случае их выявления при согласовании Заказчиком технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России; – выполнение требований к классу защищенности ГИС, уровню защищенности персональных данных и категории значимости объекта КИИ РФ, установленных для Головного центра обработки данных ФГБУ «СИЦ Минтранса России» (далее – ГЦОД); – определение перечня объектов защиты информационной системы; – описание (актуализированных) требований к системе защиты информации, а также к мерам защиты информации информационной системы в зависимости от установленных классов защищенности, уровня защищенности персональных данных и категории значимости объектов КИИ РФ (приказы ФСТЭК России № 21, 117, 239); – выполнение требований к мерам по защите ГИС от атак, направленных на отказ в обслуживании, в соответствии с пунктами 30, 34, 59, 63 Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений, утвержденных приказом ФСТЭК России от 11.04.2025 № 117; – описание (актуализированных) требований по защите информации, подлежащих реализации в информационно телекоммуникационной инфраструктуре ГЦОД; – выполнение требований о применении сертифицированных средств защиты информации, включая их классы защиты и уровни доверия; – выполнение требований о запрете использования с 01.01.2025 органами (организациями) средств защиты информации странами происхождения, которых являются иностранные государства в соответствии с пунктом 6 Указа Президента Российской Федерации от 01.05.2022 № 250; – выполнение требований по обеспечению непрерывного взаимодействия с ГосСОПКА в установленном порядке; 4.2.2. Развитие компонента отчетности (3 очередь) Должна быть обеспечена автоматизация процессов формирования отчетов о ЧС и нештатных ситуациях на транспорте, в т.ч. на основе данных из внешних систем. Включает следующие доработки: – разработка шаблонов отчетов в различных форматах (табличный, текстовый); – реализация выбора фотоматериалов для включения в справку; – форматирование содержимого справок с учетом правил русского языка в отношении окончаний слов (в зависимости от падежа, склонения, числа и рода); – автоматизированное формирование выводов к содержимому справки на основе настраиваемых критериев; – создание интерфейса выбора параметров (фильтрации) для формирования отчетов: o состав полей для включения в отчёт; o настройка диапазонов значений характеристик и дат; o порядок отображения полей; o настройка заголовка. – реализация способа подготовки отчётов в асинхронном режиме (очереди); – реализация интерфейса компонента формирования отчетности для отображения очереди формирования отчетов и статусов их подготовки; – экспорт отчётов в форматы xlsx, csv и справок в форматы pdf, docx. Необходимо разработать не менее 10 шаблонов отчетов и/или справок. Перечень, структура и содержание шаблонов должны быть согласованы с Заказчиком на этапе технического проектирования. 4.2.3. Развитие компонента визуализации (2 очередь) В рамках развития компонента визуализации должны быть выполнены следующие доработки, обеспечивающие: – вывод перечней (списков) сил и средств предупреждения и ликвидации ЧС и нештатных ситуаций на транспорте с отображением мест их постоянного размещения (дислокации) на карте, включая: o отображение зон ответственности на карте; o возможность их фильтрации (по видам транспорта, регионам и пр.); o реализацию инструмента расчета расстояния (с использованием сети автомобильных и железных дорог) между местом события и местами дислокации сил и средств, а также вывода маршрутов на карте; – отображение зон (полигонов) с установленными ограничениями движения в воздушном пространстве на карте; – отображение термических точек; – реализация возможности отображения данных из паспорта региона, отображаемого в модуле iМинтранс (модуль АСУ ТК); – отображение краткой карточки сущностей и ОТИ (краткой информации и/или динамических характеристик объекта) при выборе объекта на карте с возможностью перехода в полную карточку сущности и ОТИ; – отображение данных от Росгидромета, предусматривающих: o отображение неблагоприятных и опасных природных явлений на карте (с заданным периодом обновления данных); o управление отображением явлений на карте, включая настройку состава отображаемых объектов, поиск, фильтрацию, с использованием соответствующей панели управления; o выведение краткой карточки явления при выборе объекта, с возможностью перехода в полную карточку объекта – отображение на карте связанных сущностей и ОТИ; – реализация функции выбора темного и светлого стилей отображения элементов интерфейса, карточек сущностей, картографической основы и объектов, отображаемых на карте; – реализация механизма для выбора картографической основы в одном из распространенных форматов WMTS, TMS, MVT и др. Должна быть предусмотрена возможность настройки перечня картографических основ и параметров доступа к ним; – настройка базового набора дашбордов, содержащих преднастроенные виджеты о количестве событий в разрезе видов транспорта с возможностью перехода к исходным данным (карточкам событий, ОТИ и т.д.), с фильтрацией по параметрам. Параметры фильтрации должны быть определены на этапе технического проектирования. Должно быть обеспечено автоматическое и принудительное обновление данных, отображаемых на дашбордах 4.4.7.1.5. Требования к используемым зависимостям (библиотекам) Все внешние зависимости проекта должны быть зафиксированы с указанием точных версий. Для контроля версий зависимостей в репозиторий обязательно должны быть включены следующие файлы: · Для JavaScript: package-lock.json или yarn.lock; · Для Python: requirements.txt (с зафиксированными версиями) или Pipfile.lock; · Для Go: go.mod и go.sum; Загрузка всех зависимостей должна производиться исключительно через внутренний прокси-репозиторий Заказчика, настроенный в соответствующем системе менеджере пакетов. Запрещается: · Использование плавающих версий (например, ^1.2.3, ~4.5.0, latest); · Использование библиотек, содержащих критические уязвимости, в том числе зарегистрированные в реестре CVE (Common Vulnerabilities and Exposures). 4.4.7.1.6. Требования к процессу непрерывной интеграции (CI) Сборка программного обеспечения, включая этапы компиляции, тестирования и анализа кода, должна выполняться исключительно в инфраструктуре непрерывной интеграции Заказчика. 4.4.7.1.7. Требования к хранению артефактов сборки Все артефакты сборки (результирующие пакеты, Docker-образы и т.д.) подлежат обязательному хранению в предназначенной для этого инфраструктуре Заказчика (артефакторий). Запрещается размещение финальных артефактов сборки на сторонних ресурсах 4.4.8. Требования к техническому обеспечению Количество серверов, подключаемых и настраиваемых сервисов, их параметров, схемы соединений и настройки межсетевого взаимодействия должны быть согласованы с Заказчиком на этапе № 1 Техническое проектирование. Доступ к комплексу технических средств предоставляется Заказчиком по письменному запросу Подрядчика. Применяемые в Системе программно-аппаратные и аппаратные комплексы должны соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации», требованиям Постановления Правительства Российской Федерации от 23 декабря 2024 г. № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц». Модуль СЦ, работающий в составе АСУ ТК, развернут на вычислительных мощностях ГЦОД СИЦ Минтранса России 4.5. Общие технические требования 4.5.1. Требования к численности и квалификации персонала и пользователей Модуля СЦ Программное обеспечение Модуля СЦ не должно требовать изменения штатной численности персонала Заказчика. Программное обеспечение Модуля СЦ не должно требовать наличия у пользователей дополнительной квалификации в сфере информационных технологий, кроме базовых знаний в обращении с персональным компьютером, базовых навыков работы в интернет-обозревателях и знаний о Модуле СЦ в объеме документов Руководство пользователя, Руководство администратора – выполнение требований по обеспечению в автоматизированном режиме с Национальной системой противодействия DDoS-атакам (НСПА) Центра мониторинга и управления сетью связи общего пользования ФГУП «ГРЧЦ» в рамках реализации мер по защите ГИС от атак, направленных на отказ в обслуживании; – детализированные требования к составу и содержанию работ по аттестации, а также к их результатам в соответствии с пунктами 13, 15 и 16 требований приказа ФСТЭК России от 29.04.2021 № 77 «Об утверждении Порядка организации и проведения работ по аттестации объектов информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну» 4.5.5.1. Требования к безопасности исходного кода Процесс разработки исходного кода должен соответствовать требованиям законодательства, нормативным правовым актам Российской Федерации, приказу ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по безопасности значимых объектов критической информационной инфраструктуры Российской Федерации», а также учитывать отраслевые практики безопасной разработки. Подрядчик должен предоставить Заказчику Руководство по безопасной разработке программного обеспечения (далее – Руководство), применяемое при разработке исходного кода Модуля СЦ. Руководство должно содержать: · описание процесса безопасной разработки и ролевой модели, отражающей зоны ответственности сотрудников Подрядчика; · описание процессов моделирования, оценки и формирования мер предотвращения угроз, применяемых Подрядчиком; · описание методик, применяемых Подрядчиком при разработке исходного кода (правила написания кода); · описание методик, периодичности проведения и инструментария статического, динамического, композитного и фаззинг тестирования исходного кода, включающего критерии отбора релизных версий ПО, применяемые Подрядчиком в процессе разработки; · описание механизмов безопасности в процессе сборки и доставки (безопасность образов, безопасность секретов, безопасность окружения и сборочной среды), применяемые Подрядчиком; · утвержденные шаблоны отчетной документации (в том числе акты), в соответствии с которыми Заказчик принимает результаты проверок (артефакты сборочного процесса), проведенных Подрядчиком; · описание процедур отслеживания и исправления обнаруженных ошибок и уязвимостей программного обеспечения; · описание способов и сроков доведения Подрядчиком до Заказчика информации об уязвимостях программного обеспечения, о компенсирующих мерах по защите информации или ограничениях по применению программного обеспечения, способов получения пользователями программного обеспечения его обновлений, проверки их целостности и подлинности Подрядчик должен обеспечить реализацию и проведение внутренних проверок мер по разработке безопасного ПО, приведенных в Руководстве. Подрядчик должен провести анализ угроз безопасности информации программного обеспечения в соответствии с ГОСТ 58412-2019 «Защита информации. Разработка безопасного программного обеспечения. Угрозы безопасности информации при разработке программного обеспечения». Подрядчик должен провести испытания по выявлению уязвимостей в программном обеспечении Системы: · проведение статического анализа исходного кода программы; · проведение динамического анализа исходного кода программы; · проведение композитного анализа исходного кода и образов программы; · проведение фаззинг-тестирования программы, направленного на выявление в ней уязвимостей. Испытания по выявлению уязвимостей в программном обеспечении Системы должны быть проведены в рамках: · предварительных испытаний; · опытной эксплуатации; · приемочных испытаний 4.2.4. Создание компонента «Интерактивная карта» (2 очередь) В составе создаваемого компонента должны отображаться данные, доступные в компоненте визуализации. Требования к интерфейсу интерактивной карты: – интерактивная карта должна быть представлена в виде объемной карты с учетом макетов, представленных в Приложении А к ТЗ; – интерфейс должен корректно отображаться на экранах мониторов (разрешение Full HD 1920?1080), телевизоров (разрешение 4К 3840?2160), жидкокристаллических панелей для видеостены, используемой Заказчиком, с параметрами каждой панели: диагональ 55 дюймов, разрешение 1920x1080; – интерфейс должен корректно отображаться на планшетных устройствах с диагональю экрана 10-12 дюймов, конкретные требования должны быть уточнены на этапе технического проектирования; – должна быть обеспечена кластеризация и генерализация отображения объектов на карте при изменении масштаба; – должно быть обеспечено отображение основных характеристик объектов при выборе их на карте; – должно быть обеспечено управление отображением слоев на карте; – должна быть обеспечена настройка цветовой индикации отображаемых объектов транспортной инфраструктуры; – должно быть обеспечено отображение легенды карты, содержащей отображаемые объекты на карте; – должна быть обеспечена возможность одновременного отображения не менее 5 000 ОТИ и ТС на карте. На интерактивной карте должны быть отображены подвижные объекты совместно с объектами транспортной инфраструктуры (ОТИ), включая следующие возможности: § отображение местоположения транспортных средств (воздушный, водный и автомобильный транспорт) на карте в режиме реального времени (с заданным периодом обновления данных); § отображение маршрутов движения всех ТС за выбранный период времени, в том числе с использованием эффектов анимации; § отображение маршрутов движения ТС, связанных с карточкой события: ТС, являющихся участниками события, и ТС, находящиеся в заданном радиусе от события; § управление отображением сущностей и ОТИ на карте, включая настройку состава отображаемых объектов, поиск, фильтрацию, с использованием соответствующей панели управления и наглядным представлением результатов; § автоматическое изменение вида отображения объектов (цветовая индикация) по заданным условиям (например, при достижении критических значений параметров, характеризующих функционирование объекта); Должна обеспечиваться производительность обновления изображения на экране в 30 кадров в секунду на тестовой конфигурации пользовательского устройства (модель Бештау AIO2402/B560, входящая в Реестр российской промышленной продукции под номером 10394100 или аналог) при одновременном отображении не менее 5 000 объектов и 200 уникальных моделей объектов. Макеты интерфейсов Модуля СЦ должны быть предварительно согласованы с Заказчиком и разработаны с учетом требований ГОСТ Р ИСО 9241-161-2016 «Элементы графического пользовательского интерфейса» 4.5.2. Требования к режимам функционирования Модуля СЦ Модуль СЦ должен предусматривать наличие следующих режимов работы: – штатный; – регламентный (профилактический); – аварийный. Основным режимом функционирования является штатный. В штатном режиме все компоненты корректно и полностью выполняют свои функции. Перерывов в работе как Модуля СЦ в целом, так и одного, либо нескольких компонентов не предусмотрено. Режим регламентного (профилактического) обслуживания предназначен для проведения работ по обновлению и техническому обслуживанию компонентов Модуля СЦ, а также резервному копированию данных. При работе в данном режиме допускаются перерывы в работе Модуля СЦ с предварительным информированием пользователей. Состав процедур по регламентному обслуживанию Модуля СЦ и их периодичность определяются Подрядчиком в процессе выполнения работ по созданию Модуля СЦ. В режиме регламентного (профилактического) обслуживания Модуль СЦ может функционировать с частичным ограничением своих функциональных возможностей, либо без ограничения, но со снижением показателей надежности и производительности. Перевод в данный режим работы должен осуществляться сразу после начала выполнения любой операции, отнесенной к этому режиму, с последующим возвратом в штатный режим функционирования сразу после ее завершения. Перевод в указанный режим должен осуществляться при возникновении необходимости проведения работ по обновлению и техническому обслуживанию компонентов Модуля СЦ, а также резервному копированию данных с условием предварительного оповещения пользователей. Аварийный режим функционирования характеризуется отказом одной или нескольких подсистем, вызванных выходом из строя аппаратного и/или программного обеспечения, а также в случае временной неработоспособности каналов связи между серверами. В аварийном режиме осуществляется поиск неисправностей и проведение работ по их устранению. Перевод в аварийный режим должен осуществляться при возникновении сбоев, аварий и прочих незапланированных воздействий, сразу после наступления одной или нескольких аварийных ситуаций, с последующим возвратом в штатный режим функционирования сразу после окончания восстановительных работ. ПО Модуля СЦ должно обладать надежностью, обеспечивающей работу пользователей в произвольном режиме и оперативное восстановление работоспособности при сбоях. В целях обеспечения надежного функционирования ПО должно предусматривать: – сохранение целостности данных при нештатном завершении работы компонентов Модуля СЦ; – сохранение работоспособности программного обеспечения при некорректных действиях пользователя; – резервное копирование базы данных Модуля СЦ. – время восстановления работоспособности Модуля СЦ после отказа не более 4 часов. – отказоустойчивость на уровне 99% при единовременной количестве не менее 200 пользовательских сессий в Модуле СЦ. Указанные характеристики приведены без учета характеристик надежности инфраструктуры и времени передачи информации по каналам связи. При возникновении сбоев в аппаратном обеспечении, включая аварийное отключение электропитания, Модуль СЦ должен автоматически восстанавливать свою работоспособность (не требовать перенастройки) после устранения сбоев и корректного перезапуска аппаратного обеспечения По результатам анализа угроз безопасности информации программного обеспечения и испытаний по выявлению уязвимостей в программном обеспечении Системы должна быть предоставлена отчетная документация по формам, утвержденным в Руководстве, и артефакты сборочной среды, подтверждающие проведение испытаний по выявлению уязвимостей в программном обеспечении Систем. Уязвимости подлежат устранению в сроки, обозначенные Заказчиком. В случае обнаружения уязвимого компонента Подрядчик должен заменить/обновить библиотеки. В случае, если уязвимость не подлежит исправлению на программном уровне, Подрядчик должен разработать меры предотвращения угроз безопасности, в том числе правила безопасности для наложенных средств защиты, рекомендации по безопасной настройке конфигурации для устранения потенциальных уязвимостей и снижения рисков информационной безопасности. Уязвимости, найденные ФСБ России, ФСТЭК России, Минцифры России, Роскомнадзором в ходе исполнения Контракта, а также в течение гарантийного периода, должны быть устранены Подрядчиком за свой счет в сроки, согласованные с Заказчиком 4.5.6. Требования к эргономике и технической эстетике Взаимодействие пользователей с Модулем СЦ должно осуществляться посредством визуального графического интерфейса. Ввод-вывод данных, прием управляющих команд и отображение результатов их исполнения должны выполняться в интерактивном режиме. Интерфейс должен быть рассчитан на преимущественное использование манипулятора типа «мышь», то есть управление Модулем СЦ должно осуществляться с помощью набора экранных меню, кнопок, значков и т. п. элементов. Клавиатурный режим ввода должен использоваться главным образом при заполнении и/или редактировании текстовых и числовых полей экранных форм. Все надписи экранных форм, а также сообщения, выдаваемые пользователю (кроме системных сообщений), должны быть на русском языке. Модуль СЦ должен обеспечивать проверку вводимых пользователем данных и предупреждать о некорректно введённых значениях Экранные формы должны проектироваться с учетом требований унификации: – все экранные формы пользовательского интерфейса должны быть выполнены в едином графическом дизайне, с одинаковым расположением основных элементов управления и навигации; – для обозначения сходных операций должны использоваться сходные графические элементы, кнопки и другие управляющие (навигационные) элементы. Термины, используемые для обозначения типовых операций, а также последовательности действий пользователя при их выполнении должны быть унифицированы; – внешнее поведение сходных элементов интерфейса (реакция на наведение указателя «мыши», переключение фокуса, нажатие кнопки) должно реализовываться одинаково. Структура размещения информации и представление этой структуры в Модуле СЦ должны соответствовать следующим требованиям: – пункты меню в пользовательском веб-интерфейсе должны быть сгруппированы в соответствии с тематикой информации, функциональными задачами и технологией работы; – каждому пункту меню должна соответствовать только одна выполняемая функция; – при совершении пользователями ошибочных действий должны выдаваться сообщения об ошибках. Эскизы визуального оформления компонента «Интерактивная карта» представлены в Приложении А. 4.2.4.1. Требования к технической реализации компонента «Интерактивная карта» При реализации компонента «Интерактивная карта» должны учитываться требования, указанные ниже. 4.2.4.1.1. Требования к отображению элементов Повторяющихся элементы карты (ТС, ОТИ, события и пр.) должны отрисовываться с использованием аппаратного создания экземпляров объектов на пользовательском устройстве (WebGL/WebGPU)). Отрисовка каждого объекта отдельным запросом не допускается, должна обеспечиваться возможность одновременного отображения не менее 5 000 объектов без снижения производительности (30 кадров в секунду на тестовой конфигурации). 4.2.4.1.2. Уровни детализации объектов Для управления отображением сложных объектов должно быть создано не менее 3-х уровней детализации, отображаемых при изменении масштаба с возможностью автоматического переключения между уровнями. Все отображаемые объекты должны масштабироваться с учетом разрешения экрана пользователя с сохранением качества детализации. 4.2.4.1.3. Полигональная оптимизация и текстурирование При реализации компонента «Интерактивная карта» должна обеспечиваться технология рельефного тестурирования объектов. Не должны использоваться высокополигональные трехмерные модели. Все повторяющиеся элементы должны генерироваться единоразово и повторно использоваться при последующих отображениях. 4.2.4.1.4. Управление памятью Требуется реализовать потоковую загрузку на устройство пользователя элементов карты и текстур. Загрузка данных целиком при старте приложения не допускается. Необходимо реализовать механизм очистки памяти от элементов, которые находятся вне области видимости камеры в течение заданного времени. 4.2.4.1.5. Требования к взаимодействию пользователя с интерфейсом компонента «Интерактивная карта» Программная реализация механизмов управление камерой (масштабирование и навигация) должна быть выполнена с поддержкой технологии WebAssembly (WASM). Элементы управления должны являться неотъемлемой частью интерактивной карты. 4.2.5. Развитие компонента администрирования (3 очередь) Должна быть выполнена доработка ролевой модели. Ролевая модель должна обеспечивать управление доступом к отдельным объектам Модуля СЦ и их элементам (атрибутам) с разграничением по видам транспорта, регионам и пр., в частности: – определение набора конкретных действий, доступных пользователям (выполняемых над объектом доступа, например, удаление записи, редактирование записи, формирование отчета и др.); – реализация возможности объединения пользователей в группы; – определение прав доступа для групп пользователей; – реализация интерфейса визуальной настройки прав доступа пользователей к объектам Модуля СЦ 4.5.7. Требования по сохранности информации при авариях В случае возникновения аварии или сбоя в процессе выполнения пользовательских задач должно быть обеспечено восстановление баз данных до состояния на момент последней завершенной Модулем СЦ транзакции, и структуры файлового хранилища. Все аварийные ситуации должны обрабатываться программно с выдачей соответствующих сообщений, с корректной обработкой ситуации (завершение транзакций, закрытие файлов и т.п.), без потери обрабатываемой информации. В Модуле СЦ должны быть предусмотрены меры, обеспечивающие целостность данных в случае отказа программного обеспечения или аппаратных средств, исключая случаи физического уничтожения носителя или нарушения функциональности носителя, операционной системы или СУБД по вине их производителя либо обслуживающего персонала. Используемые аппаратные и системные платформы должны обеспечивать сохранность и целостность информации в Модуле СЦ при полном или частичном отключении электропитания, аварии сетей телекоммуникации, полном или частичном отказе технических средств Модуля СЦ. Технические решения должны обеспечивать сохранность информации в случае возникновения следующих событий (аварий, отказов и т.п.): – отказ аппаратного обеспечения на сервере; – отключение питания на сервере; – отказ аппаратного обеспечения на рабочей станции; – отключение питания на рабочей станции администратора; – отказ линий связи, в том числе при осуществлении обмена данными 4.5.8. Требования к защите от влияния внешних воздействий Требования к защите от влияния внешних воздействий не предъявляются 4.5.9. Требования к патентной чистоте и патентоспособности 4.5.9.1. Исключительные права на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, базы данных, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, принадлежат Российской Федерации в лице Заказчика. Право собственности на результаты работ, отчетные документы и материалы, полученные в ходе выполнения работ по Контракту, принадлежат Российской Федерации в лице Заказчика и считаются переданными с момента подписания Сторонами Акта сдачи-приемки выполненных работ. Разработанное программное обеспечение поставляется вместе с исходными кодами. 4.5.9.2. Все проектные и технические решения должны отвечать требованиям четвертой части Гражданского кодекса Российской Федерации. Результаты Работ должны быть свободными от возможности предъявления любых прав и притязаний третьих лиц, основанных на промышленной, интеллектуальной или другой собственности. 4.5.9.3 Результаты выполненных Работ не должны повлечь необходимость осуществления Заказчиком закупок программного обеспечения (как исключительных, так и неисключительных прав) для обеспечения функциональности Системы в соответствии с Техническим заданием. При выполнении работ Подрядчик должен использовать только объекты интеллектуальной собственности, права на которые приобретены (получены) и используются без нарушений прав на интеллектуальную собственность третьих лиц или предоставлены Заказчиком 4.2.6. Взаимосвязи с внешними автоматизированными системами (1 очередь) Способы взаимодействия с внешними информационными системами должны быть определены на этапе технического проектирования. Должны быть выполнены следующие доработки: – интеграции с информационными ресурсами в целях получения данных о движении подвижных ТС (воздушные суда, суда водного транспорта); – интеграция с информационным ресурсом в целях получения данных о событиях на железнодорожном транспорте. Реализация интеграций должна включать проектирование и реализацию интеграционных механизмов обмена данными с учетом доступных вариантов реализации, обеспечение защищенных способов взаимодействия, настройку отображения отдельных данных на карте (настройка слоев). Взаимодействия, имеющие каналы связи, выходящие за пределы контролируемой зоны взаимодействующих систем, считаются защищенными, если для их защиты используются программные и/или программно-аппаратные шифровальные (криптографические) средства, сертифицированные ФСБ России (далее – СКЗИ). Выбор СКЗИ, схемы подключения и требуемого класса криптостойкости должен производиться в соответствии с Техническими условиями на подключение к информационным ресурсам ФГБУ «СИЦ Минтранса России» и инструкциями по подключению пользователей к ресурсам инфраструктуры Головного центра обработки данных, утвержденных приказом директора ФБГУ «СИЦ Минтранса России» от 24.05.2024 № 21-ОД 4.3. Требования к оказанию услуг по технической поддержке Модуля СЦ 4.3.1. Общие требования к оказанию Услуг Техническая поддержка Модуля СЦ должна осуществляться с учетом требований постановления Правительства Российской Федерации от 06.07.2015 N 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации». Подрядчик обязан выполнять требования законодательства в сфере защиты информации, требования по защите информации, информационной безопасности, указанные в локальных нормативных актах ФГБУ «СИЦ Минтранса России», регламентирующих условия информационного взаимодействия, защиты информации и подключения к информационным ресурсам ФГБУ «СИЦ Минтранса России», участвующих в информационном взаимодействии в рамках оказания услуг по технической поддержке АСУ ТК в 2026 году 4.3.1.1. Требования к составу и содержанию услуг третьего уровня технической поддержки Оказание услуг по технической поддержке Системы осуществляется в рамках этапов в соответствии с календарным планом. Подрядчик в течение 5 рабочих дней с даты заключения Контракта должен предоставить со своей стороны, а Заказчик со своей стороны Матрицу ответственных за взаимодействия в соответствии с Приложением 1 к Регламенту оказания услуг по третьему уровню технической поддержки Модуля СЦ (далее – Регламент, Приложение В). Подрядчик в течение 10 рабочих дней с даты заключения Контракта должен провести мероприятия по организации третьего уровня технической поддержки в соответствии с Регламентом. Услуги по третьему уровню технической поддержки Модуля СЦ должны включать: – организацию Подрядчиком третьего уровня технической поддержки; – информационно-консультационную поддержку работников Заказчика; – решение инцидентов, связанных с работой ППО; – адаптационное, конфигурационное и коррекционное сопровождение Модуля СЦ (в рамках действующих программных модулей и функциональности); – устранение уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности 4.5.9.4. Подрядчик подтверждает, что обладает всеми правами на передачу Заказчику исключительных прав в соответствии с требованиями настоящего раздела Технического задания. В случае, если к Заказчику по вине Подрядчика будут предъявлены претензии в этой части, иски третьих лиц, связанные с нарушением их прав, Подрядчик принимает на себя такие претензии и иски и возмещает Заказчику все расходы и весь ущерб, понесенный в связи с ними. 4.5.9.5. Подрядчик обязан согласовать с Заказчиком необходимость использования при выполнении работ охраняемых результатов интеллектуальной деятельности, права на которые принадлежат Подрядчику или третьим лицам. 4.5.9.6. В случае, если при выполнении Работ используется готовое программное обеспечение (платформа, подсистема, СУБД и т.д.), которое становится частью (компонентом) Системы, Заказчику передаются полные исключительные права, или неисключительные права (путем заключения лицензионного/сублицензионного договора/соглашения) на такое программное обеспечение со следующими возможностями: – права передаются бессрочно (на весь срок действия исключительных прав); – территория действия Российская Федерация; – должно быть обеспечено право Российской Федерации (в лице Заказчика) передавать, дорабатывать, распространять, развивать результаты работ, созданные в процессе исполнения Контракта, а также перерабатывать такое программное обеспечение. Лицензионное (сублицензионное) соглашение (договор), Акт передачи прав, подписанные Подрядчиком, согласие правообладателя, оформленное в соответствии с положениями Гражданского кодекса Российской Федерации (в случае, если Подрядчик не является правообладателем такого программного обеспечения), инструкция по инсталляции, руководство администратора, руководство пользователя передаются Заказчику в сроки, установленные Техническим заданием для соответствующего функционала Системы Лицензионное (сублицензионное) соглашение (договор) не может возлагать на Заказчика какие-либо обязанности (в т.ч. в части конфиденциальности, предоставления отчетности), не предусмотренные Контрактом. 4.5.9.7. Передача Заказчику исключительных прав, или простых (неисключительных) прав не может повлечь увеличение стоимости Контракта и/или изменение иных существенных условий Контракта. 4.5.9.8. Функциональность Модуля СЦ передается в объеме и в сроки, установленные Техническим заданием. 4.5.9.9. Нарушение условий настоящего раздела Технического задания, в т.ч. отсутствие соответствующего лицензионного (сублицензионного) соглашения (или договора), либо предоставление лицензионного (сублицензионного) соглашения (или договора), не соответствующего требованиям действующего законодательства Российской Федерации или требованиям Контракта, является нарушением существенных условий Контракта. 4.5.9.10. В случае, если в соответствии с пунктом 4.5.9.6 Заказчику передается исключительное право, такая передача осуществляется в порядке, установленном Гражданским кодексом Российской Федерации. 4.5.9.11. В случае, если при выполнении Работ положения пунктов 4.5.9.5-4.5.9.6 не применялись, Подрядчик в составе отчетной документации предоставляет об этом декларацию в свободной форме. Декларация должна содержать сведения о полном соответствии результата Работ требованиям Контракта, а также о неприменении при выполнении работ готового программного обеспечения (платформ, подсистем, СУБД и т.д.), которое стало частью (компонентом) Системы 4.3.1.2. Требования к общему порядку оказания услуг Техническая поддержка Модуля СЦ должна быть организована на трех уровнях: – первый и второй уровни технической поддержки организуется Заказчиком; – третий уровень технической поддержки организуется Подрядчиком. Перечень действий на каждом уровне технической поддержки указан в Таблице 5: Таблица 5 – Перечень действий на каждом уровне технической поддержки Уровень технической поддержки Доступные действия Условия передачи задачи на следующий уровень Первый уровень технической поддержки (далее – 1-й уровень) – принимает обращения (заявки) пользователей Модуля СЦ и работников Заказчика; – регистрирует обращения в Модуле СЦ регистрации обращений; – присваивает уникальный идентификационный номер, классифицирует обращения; – самостоятельно решает обращения, которые связаны с недостаточной квалификацией пользователей или настройками в рамках своей компетенции; – взаимодействует с пользователями Модуля СЦ при решении проблемы Передает обращение на второй уровень поддержки в случае невозможности решения на своем уровне Второй уровень технической поддержки (далее – 2-й уровень) – принимает обращения от 1-го уровня; – уточняет классификацию обращения в результате дополнительного анализа; – самостоятельно решает обращения в рамках своей компетенции; – осуществляет техническую и консультационную поддержку Модуля СЦ; – взаимодействует с сотрудниками 1-го и 3-го уровня и пользователями Модуля СЦ; – формирует заявки для 3-го уровня и контролирует исполнение Передает обращение на третий уровень поддержки в случае невозможности решения на своем уровне Третий уровень технической поддержки (далее – 3-й уровень) – принимает обращения от 2-го уровня; – обеспечивает выполнение требований, предъявляемых Контрактом и настоящим Техническим заданием к Услугам, оказываемым Подрядчиком Все поступающие обращения должны быть исполнены Подрядчиком Для обеспечения взаимодействия с Заказчиком Подрядчик со своей стороны определяет ответственных лиц, уполномоченных в структуре Подрядчика за своевременное и качественное оказание Услуг в рамках настоящего ТЗ, а также контактную информацию ответственных лиц (телефон, электронную почту). Подрядчик должен предоставить Заказчику единый адрес электронной почты для приема обращений (заявок) в течение 3 (трех) рабочих дней после заключения Контракта. Указанный в настоящем пункте адрес электронной почты (способ направления обращений (заявок) применяется в случае сбоя в работе СРО Заказчика. Со своей стороны, Заказчик предоставляет Подрядчику перечень и контактную информацию (телефон, электронную почту) уполномоченных лиц для осуществления взаимодействия с указанием зон ответственности. О любых изменениях в контактной информации ответственных лиц Стороны должны уведомить друг друга в течение 1 (одного) рабочего дня с момента возникновения таких изменений посредством уведомления на электронную почту ответственных лиц и/или в письменной форме. В результате оказания услуг по настоящему ТЗ не должны быть изменены исходные коды, дистрибутивы и иные компоненты Модуля СЦ вне согласованных с Заказчиком изменений. Любые изменения исходных кодов, дистрибутивов и иных компонентов Модуля СЦ должны производиться только после согласования с Заказчиком уполномоченными лицами по электронной почте или иным заранее согласованным способом. Не должна быть ухудшена надежность и производительность Модуля СЦ. Оказание услуг по Контракту не должно нарушать требования к информационной безопасности, описанной в документации на Модуль СЦ 4.5.9.12. Передача Заказчику комплекта документов, материалов и сведений, предусмотренных нормативными правовыми актами Российской Федерации в сфере информационных технологий, защиты информации, правовой защиты интересов государства в области интеллектуальной собственности, включая документы, подтверждающие отказ авторов (разработчиков) от исключительных прав на передаваемые объекты интеллектуальной собственности в пользу Подрядчика, с проектами заявок на государственную регистрацию в установленном порядке прав Заказчика на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, базы данных, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, осуществляется Подрядчиком в составе отчетной документации, предусмотренной условиями Контракта. 4.5.9.13. По результатам выполнения работ по развитию системы должны быть подготовлены материалы для регистрации доработанной версии Системы (объекта учета) в НФАП в соответствии с требованиями постановления Правительства Российской Федерации от 30 января 2013?г. №?62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин» (с изменениями и дополнениями) в части обязательности размещения результатов работ в национальном фонде алгоритмов и программ для электронных вычислительных машин 4.5.10. Требования по стандартизации и унификации К Модулю СЦ предъявляются следующие требования в части стандартизации и унификации: – работы по развитию Модуля СЦ должны производиться в соответствии с действующими стандартами и нормами Российской Федерации; – при создании и модернизации элементов Модуля СЦ следует руководствоваться действующими в Российской Федерации национальными стандартами и другими нормативно-техническими документами; – используемые оборудование и материалы, подлежащие обязательной сертификации, должны иметь соответствующие сертификаты; – ПО Модуля СЦ должно проектироваться и разрабатываться с учётом обеспечения требований унификации; – применяемые при создании Модуля СЦ технические (форматы данных, протоколы передачи и прочие) и организационные (регламенты, требования, инструкции) решения должны быть доступны и документированы в виде, достаточном для независимой (без обращения к Подрядчику) реализации третьими сторонами; – термины, обозначения и наименования, используемые в ПО, должны быть стандартизованы и унифицированы, выполнены на русском языке; – взаимодействие элементов и их внешнее поведение должно быть реализовано одинаково и производиться по единым правилам Оказание услуг в рамках данного технического задания осуществляется Подрядчиком по обращению (заявке) Заказчика, направляемой посредством СРО Заказчика. Регистрация обращений, поступивших непосредственно в Модуль СЦ регистрации обращений Заказчика, производится сотрудниками Заказчика, которые обеспечивают первый уровень технической поддержки Модуля СЦ. В случае назначения приоритета «Критический» или «Высокий», информация о назначении также дублируется оповещением ответственных представителей Подрядчика посредством звонка на предоставленные номера телефонов. Обращение (заявка) должна содержать следующую информацию: – контакты пользователя/организации; – приоритет обращения, соответствующий Приложению 2 к Регламенту; – время обнаружения; – наименование компонента АСУ ТК - Модуль СЦ; Информация может быть расширена по согласованию с Заказчиком. Обращения (заявки) сотрудников Заказчика должны приниматься Подрядчиком через веб-интерфейс СРО. В процессе обработки обращений (заявок) Подрядчик должен обеспечить выполнение следующих процедур: – прием обращений(заявок) от сотрудников Заказчика; – оказание информационно-консультационной поддержки в соответствии с требованиями настоящего Технического задания; – информирование сотрудников Заказчика о статусе обработки и результатах обработки обращений(заявок). Подрядчик осуществляет обязательную регистрацию и учет всех обращений и заявок, поступивших к Подрядчику от представителей Заказчика в рамках оказания настоящих услуг Примечание: в случае приостановки работы по обращению или заявке (обращение или заявка находится в статусе «Приостановлено»), указываются причины, по которым работы по обращению или заявке приостановлены с указанием перечня действий/информации, запрошенных у инициатора обращения, а также даты, формы и адресата такого запроса. В случае отклонения обращения или заявки (заполняется в случае, если обращению или заявке присваивается статус «Отклонено»), указываются подробно причины такого отклонения, а также фиксируется дата и время перехода в статус «Отклонено». В случае, если обращение или заявка отклонены (отменены) самим Инициатором, то указывается дата и способ, которым от инициатора получено соответствующее уведомление. В случае невыполнения Подрядчиком регламентного времени реагирования или решения обращения (заявки) Заказчик вправе отозвать обращение и направить его Подрядчику повторно. При этом каждое отозванное обращение учитывается в Отчёте об оказанных услугах, как обращение с превышением времени реагирования или решения, но оплате не подлежит. В случае, если обращение (заявка) связано с некачественным выполнением Подрядчиком другой задачи, такое обращение решается в регламентное время, установленное Техническим заданием, при этом оплате такие обращения не подлежат, о чем указывается в Отчете об оказанных услугах в графе «Примечание» 4.5.11. Требования к показателям назначения 4.5.11.1. Требования к показателям назначения мероприятий по развитию Модуля СЦ В рамках выполнения работ по развитию Модуля СЦ, предусмотренных ТЗ, показатель назначения «Количество пользователей» должен соответствовать значениям, приведенным в данном разделе. Пояснения по показателям, связанным с количеством пользователей, приведены в Таблице 8. Таблица 8. Определения показателей, связанных с количеством пользователей в Модуле СЦ № Показатель Определение Расчетное количество пользователей Количество пользователей, работу которых должен обеспечить Модуль СЦ к моменту сдачи работ по Контракту с учетом достижения всех показателей назначения Расчетное количество одновременно работающих пользователей Количество одновременно работающих пользователей, работу которых должен обеспечивать Модуль СЦ к моменту сдачи работ по Контракту с учетом достижения всех показателей назначения Значения показателей количества пользователей, достижение которых необходимо обеспечить, представлено в Таблице 9 Таблица 9. Значения показателей количества пользователей № Показатель Значение 1. Расчетное количество пользователей 1 000 2. Расчетное среднее количество одновременно работающих пользователей 200 Развитие Модуля СЦ должно быть направлено на достижение следующего эффекта (показателя), подставленного в мероприятии 103.002 «Информационно-аналитическая система регулирования на транспорте (АСУ ТК)» ВПЦТ Минтранса России: Выполнение работ по развитию Модуля СЦ предусмотрено мероприятием по развитию АСУ ТК, приведенном в ВПЦТ Минтранса России на 2026-2028 гг: № 103.002 «АСУ ТК» в составе ИТ расхода 103.26.000005 «Развитие предусматривает реализацию ОКР и эффектов, приведенных в Таблице 10. Таблица 10. ОКР и эффекты, приведенные в ВПЦТ Минтранса России на 2026 г. № ОКР Дата ОКР Эффекты 1 Обеспечено информационное взаимодействие с Минобороны России о происшествиях на транспортных объектах 25.12.2026 Сокращено время сбора и передачи сведений для Минобороны России о ЧС и НС на транспорте с 120 до 10 минут 2 Обеспечена автоматизация формирования отчетов о нештатных ситуациях на транспорте, в том числе по данным внешних систем 25.12.2026 Сокращено время на подготовку отчетов о нештатных ситуациях на транспорте с 20 до 5 минут Реализация остальных ОКР не является предметом данного ТЗ и проводится в рамках отдельного технического задания. 4.5.11.2. Требования к показателям назначения мероприятий по эксплуатации Модуля СЦ. Работы по эксплуатации Модуля СЦ не должны обеспечивать режимы функционирования Модуля СЦ, приведенные в разделе 4.5.2 данного ТЗ 4.3.1.3. Требования к регламенту оказания услуг Подрядчик должен руководствоваться Регламентом оказания услуг по технической поддержке Модуля СЦ. Регламент оказания услуг содержит следующую информацию: – порядок оказания услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Модуля СЦ; – порядок оказания услуги по решению инцидентов, связанных с работой ППО; – порядок оказания услуги адаптационного, конфигурационного и коррекционного сопровождения Модуля СЦ (в рамках действующих программных модулей и функциональностей); – порядок оказания услуги по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности. – Регламент содержит следующие формы заявок на оказание услуг: – форма заявки на оказание услуги по информационно-консультационной поддержке сотрудников Заказчика; – форма заявки на оказание услуги по решению инцидентов, связанных с работой ППО; – форма заявки на оказание услуг адаптационного, конфигурационного и коррекционного сопровождения Модуля СЦ (в рамках действующих программных модулей и функциональностей) (приоритет заявки определяется Заказчиком); – форма заявки на оказание услуги по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности 4.3.2. Требования к режиму обеспечения функционирования Модуля СЦ Режим оказания услуг определен в Приложении Б к настоящему ТЗ. По согласованию с Заказчиком, в целях недопущения остановки функционирования Модуля СЦ в период интенсивной работы пользователей в Модуле СЦ, отдельные услуги могут оказываться по специальному графику (в нерабочее время Подрядчика) в соответствии с заявками Заказчика 4.3.3. Требования к качеству оказываемых услуг Качество оказываемых услуг поддерживается Подрядчиком в соответствии с определяемыми данным ТЗ условиями и правилами и контролируется Заказчиком на постоянной основе, в том числе по соблюдению сроков исполнения и подтверждениям исполнения от инициаторов обращений и другим параметрам. По результатам выполнения работ по устранению инцидента должна быть устранена корневая причина инцидента с окончательным решением, устраняющим причину возникновения проблемы и исключающим вероятность повторного возникновения проблемы (инцидента). Время устранения корневых причин проблемы (инцидента) не должно составлять более 40 рабочих часов 4.3.4. Требования к документированию результатов оказываемых услуг Для обеспечения контроля оказываемых услуг по поддержке Модуля СЦ со стороны Заказчика, по окончании каждого отчетного периода по контракту в соответствии с календарным планом, Подрядчик обязан предоставить Заказчику Отчет об оказанных услугах. Отчет должен содержать детальную информацию об оказанных услугах с указанием даты выполненных мероприятий и приложением обосновывающих документов (заявок, запросов, требований) или ссылкой на такие документы, если они содержатся в Модуле СЦ. Информация о выполненных мероприятиях по заявкам должна быть сформирована на основании соответствующих записей СРО по каждому этапу исполнения Контракта. В случае оказания услуги адаптационного, конфигурационного и коррекционного сопровождения Модуля СЦ, должны быть предоставлены документы, подтверждающие выполнение требований п. 29.3 приказа ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации». Фактическое время реагирования и время решения по всем обращениям, поступившим в СРО, формируется в СРО по итогам отчетного периода в разделе «Отчеты». Фактическое время реагирования и время решения по обращениям учитывает суммарное время, затраченное на реагирование и, соответственно, на работу по обращению с момента назначения обращения специалисту Подрядчика или группе исполнителей, ответственным за оказание услуг технической поддержки 3 уровня от начала до завершения работ Подрядчиком. При этом принимается суммарное время нахождения заявки в соответствующих статусах заявки СРО на стороне Подрядчика 4.3.5. Требования к классификации обращений и заявок Обращения и заявки Заказчика классифицируются в соответствии с приоритетами и регламентными сроками, указанными в Приложении 2 к Регламенту. Регистрация обращений и заявок предусматривает создание новой записи в СРО с присвоением поступившему обращению или заявке (новой записи) уникального идентификатора. Запись в СРО должна содержать вопрос или проблему, которую требуется решить или оказать консультацию. Состав обязательной информации, которую должно содержать обращение или заявка, зафиксирован в Регламенте оказания Услуг. Если обращение или заявка автоматически зарегистрированы в СРО при отправке представителем Заказчика, Подрядчик проверяет корректность классификации обращения или заявки и может обратиться к Заказчику с просьбой корректировки, предоставив обоснования в соответствии с настоящей классификацией (Таблица 6) Таблица 6. Категории обращений и заявок Категория Примеры Запрос на обслуживание Подготовка SQL запроса к СУБД для решения прикладной задачи и д.р. – запрос на любое действие, не являющееся запросом информации и несовершенный на основе происшествия, прямо или косвенно влияющего на работу Модуля СЦ Консультация «Где взять / куда обратиться...?», «Как сделать / выполнить…», «Как это работает…?» - запрос, имеющий своей целью получение информационной поддержки Инцидент Разбор ошибок/сбоев и подготовка материалов (корректировочных релизов, инструкций) для Заказчика для устранения ошибок/сбоев, которые приводят к частичному и полному нарушению работоспособности всех или отдельных функций ППО. Подготовка изменения и материалов, необходимых для проведения аварийно-восстановительных работ для возобновления работоспособности Модуля СЦ ЗНИ Подготовка изменений, связанных с изменением, улучшением/оптимизацией Модуля СЦ и выводом новой модифицированной функциональности в штатном режиме. Подготовка изменений, связанных с модификацией существующих и/или реализация новых интеграционных механизмов для получения/обработки данных внешних систем. Подготовка изменений графического интерфейса по требованиям Заказчика. Перечень статусов обращений (заявок) приведен в пункте 3.3. Регламента оказания Услуг. Назначение обращению (заявке) статуса «Закрыто» осуществляется Заказчиком только после получения от инициатора обращения (заявки) подтверждения о его исполнении или нахождения обращения (заявки) в статусе «Выполнено» и отсутствия повторных вопросов/запросов по данному обращению (заявки) в течение 5 рабочих дней. Категории и статусы обращений (заявок) могут быть скорректированы в процессе оказания услуг исключительно по согласованию с Заказчиком 4.3.6. Требования к услугам технической поддержки 4.3.6.1. Требования к организации третьего уровня технической поддержки Основными задачами организации третьего уровня технической поддержки в рамках оказания услуг по технической поддержке Модуля СЦ являются организация эксплуатационной службы Подрядчика, проверка готовности технических и программных средств для обеспечения непрерывного функционирования ППО Модуля СЦ. Подрядчиком должны быть проведены организационно-штатные и подготовительные мероприятия (в т. ч. технические) в рамках организации технической поддержки Модуля СЦ. Подрядчик в течение 5 (пяти) рабочих дней с даты заключения Контракта должен: – определить и направить Заказчику документ «Перечень уполномоченных специалистов», содержащий контактную информацию (ФИО, должность, адрес рабочей электронной почты) лиц, ответственных за оказание услуг со стороны Подрядчика; – обеспечить подключение специалистов Подрядчика к Системе регистрации обращений (заявок) (СРО предоставляется Заказчиком) для оказания услуг; – согласовать с Заказчиком способ доступа Подрядчика к Модулю СЦ. Результат выполнения мероприятий фиксируется в Протоколе проверки результатов организационно-штатных и подготовительных мероприятий (см. Приложение Д к настоящему ТЗ) 4.3.6.2. Требования к услугам информационно-консультационной поддержки работников Заказчика и пользователей Модуля СЦ Услуги информационно-консультационной поддержки сотрудников Заказчика включают: – обработку обращений и заявок, поступивших от сотрудников Заказчика; – консультирование сотрудников Заказчика и пользователей Модуля СЦ; – актуализацию документации, и других материалов по работе с Модулем СЦ при необходимости. – консультирование и разработку рекомендаций по настройке Модуля СЦ (без изменения программного кода), включая изменение настроек функционирования; – консультации по вопросам использования, настройки и возможностям Модуля СЦ; – консультации по проведению превентивных мер для недопущения аварийных ситуаций в Модуле СЦ; – консультации по предварительной диагностике и локализации возникшей неисправности Модуля СЦ; – консультации по вопросам обеспечения информационной безопасности Модуля СЦ и настройки функций, обеспечивающих корректную работу программного обеспечения для совершения юридически значимых действий в Модуле СЦ; – другие вопросы, связанные с работой Модуля СЦ. 4.3.6.2.1. Требования к порядку оказания услуг информационно-консультационной поддержки работников Заказчика и пользователей Модуля СЦ Подрядчик выполняет консультирование сотрудников Заказчика и пользователей Модуля СЦ. Консультация может быть предоставлена по согласованным с представителем Заказчика каналам коммуникации с регистрацией результата консультации в СРО Подрядчиком. Детальный порядок оказания консультационных услуг определен в Регламенте оказания Услуг 4.3.6.3. Требования к услугам по решению инцидентов, связанных с работой ППО Подрядчик устраняет неисправности Модуля СЦ, связанные с работой ППО, выявленные в рамках оказания услуг согласно настоящему Техническому заданию, при этом в зону ответственности Подрядчика не входит устранение неисправностей, выявленных на стороне Заказчика и на стороне третьих лиц (провайдера связи, поставщика электропитания и т.д.). Первичная диагностика выявленной неисправности проводится на 1 и 2 уровнях технической поддержки и не входит в зону ответственности Подрядчика. Если при проведении первичной диагностики и попытке устранить неисправности на 1 и 2 уровнях технической поддержки, данную неисправность устранить не удалось и в процессе диагностики было выявлено, что проблема связана с работоспособностью ППО, обращение (заявка) назначается сотруднику Подрядчика, ответственному за оказание услуг технической поддержки 3 уровня. Инцидентами вне зоны ответственности Подрядчика являются: – работоспособность функциональности, выходящая за рамки текущей реализации функций в Модуле СЦ и/или являющаяся расширением требований Заказчика к функциям Модуля СЦ; – проведение профилактических и плановых работ, согласованных с Заказчиком; – нарушение работоспособности функций Модуля СЦ, вызванное проведением работ на стороне Заказчика Работы по устранению неисправности приостанавливаются (по согласованию с Заказчиком) в следующих случаях: – если Подрядчиком в результате диагностики выявлено, что неисправность находится в зоне ответственности Заказчика. Подрядчик информирует Заказчика о выявленной неисправности в зоне его ответственности по согласованным каналам связи; – требуется действие со стороны Заказчика – до момента выполнения данного действия Заказчика. Заказчик информируется о необходимых действиях по согласованным каналам связи; – отсутствие возможности связаться со специалистами Заказчика, участие которых необходимо для устранения неисправности; – требуется доставить оборудование на объект – до момента доставки и установки оборудования. В случаях, представленных выше, время приостановки работ не входит в учет продолжительности устранения неисправности. Учет времени устранения неисправности Подрядчиком считается с момента назначения Инцидента специалисту Подрядчика, ответственному за оказание услуг технической поддержки 3 уровня. Подтверждение необходимости приостановления работ находится в зоне ответственности Подрядчика. Приостановление сроков выполнения задач в соответствии с настоящим пунктом подтверждается Заказчиком по мотивированному обращению Подрядчика в СРО, основанному на данных диагностики или на иных фактических обстоятельствах В случае непринятия Подрядчиком необходимых мер по информированию Заказчика (отсутствие надлежащего обращения от Подрядчика или отсутствие уведомления о необходимости осуществления каких-либо действий Заказчиком) не может являться основанием для приостановления работ по устранению неисправности. В отдельных случаях Подрядчику может потребоваться выполнение технологических работ для устранения причин неисправности или недопущения повторения их в будущем. Для обеспечения устранения неисправности Модуля СЦ Заказчиком проводится классификация в соответствии с приоритетами по степени срочности их устранения. Продолжительность устранения неисправности, а также периодичность информирования Подрядчиком Заказчика о ходе устранения неисправности, определены в Регламенте оказания услуг. При подаче обращения (заявки) наивысшего приоритета через СРО Заказчик должен дополнительно проинформировать службу поддержки Подрядчика о созданном обращении (заявки) по телефону уполномоченного сотрудника Подрядчика. При этом временем подачи обращения (заявки) считается время подачи обращения (заявки) через СРО 4.3.6.3.1. Требования к порядку оказания услуги по решению инцидентов, связанных с работой ППО При поступлении от Заказчика обращения (заявки), являющегося неисправностью в работе Модуля СЦ (инцидентом), Исполнитель реагирует на инцидент в СРО в срок не более 30 минут с момента поступления. В случае необходимости, для решения инцидента ответственный специалист должен связаться с инициатором обращения (заявки) для уточнения условий воспроизведения проблемы или для получения дополнительных сведений. После получения необходимых сведений от инициатора обращения (заявки) ответственный специалист производит диагностику с целью выявления причины инцидента и возможных путей устранения. В случае, если инцидент невозможно решить без получения дополнительных сведений от инициатора, и не удается связаться с инициатором в течение пяти рабочих дней, обращение (заявка) отклоняется в связи с недостатком данных для его решения, Заказчику направляется уведомление об отклонении обращения (заявки). Время, в течение которого невозможно связаться с инициатором, вычитается из общего времени обработки обращения (заявки). Все попытки связаться с инициатором должны фиксироваться с указанием даты и времени попытки, используемого способа связи (номер телефона, адрес электронной почты) и результата попытки (не удалось дозвониться, абонент недоступен, и т.д.) Факт и время решения инцидента должны быть зафиксированы и отражены в СРО. В случае, если причиной сбоя в работе Модуля СЦ является выход из строя аппаратного обеспечения или неработоспособность смежной информационной системы, время работы над инцидентом приостанавливается до момента устранения неисправности. В ходе решения инцидентов могут быть выявлены дефекты ППО Модуля СЦ. В случае обнаружения дефектов ППО, Подрядчик информирует об этом Заказчика. Исполнитель может быть привлечен к проверке результата устранения дефекта по инициативе Заказчика. Приоритеты инцидентов приведены в Приложении Б к ТЗ. Детальный порядок оказания услуги по решению инцидентов, связанных с работой ППО Модуля СЦ определен в Регламенте оказания Услуг 4.3.6.4. Требования к услугам адаптационного, конфигурационного и коррекционного сопровождения и доработки Модуля СЦ (в рамках действующих программных модулей и функциональностей) Услуги адаптационного, конфигурационного и коррекционного сопровождения и доработки Модуля СЦ включают: – управление изменениями и адаптация функций Модуля СЦ; – изменение настроек функционирования Модуля СЦ; – внесение изменений и/или модификаций Модуля СЦ (в рамках действующих программных модулей и функциональностей), направленных на улучшение их работоспособности и функциональных возможностей; – подготовка и передача Заказчику SQL запросов в СУБД для получения агрегированной информации из Модуля СЦ, которую невозможно получить с использованием графического пользовательского интерфейса; – адаптация модулей интеграций со смежными информационными системами 5. СОСТАВ И СОДЕРЖАНИЕ РАБОТ ПО РАЗВИТИЮ И ТЕХНИЧЕСКОЙ ПОДДЕРЖКЕ МОДУЛЯ СЦ (КАЛЕНДАРНЫЙ ПЛАН) Сдача-приемка результатов выполненных работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная техническая документация, а также результаты работ предоставляются Заказчику в порядке, предусмотренном Контрактом и ТЗ, до размещения Подрядчиком в ЕИС документа о приемке. Документ о приемке размещается в ЕИС по каждому этапу в соответствии с условиями Контракта. Этапы выполнения работ по развитию Модуля СЦ приведены в Таблице 11. Таблица 11. Этапы выполнения работ по развитию Модуля СЦ. № этапа Наименование этапа Результат (отчетная документация) Срок исполнения этапа Значение характеристики не может изменяться участником закупки 1 Техническое проектирование Сопроводительным письмом предоставляются Заказчику: · Технический проект, включая следующие документы: – Ведомость технического проекта; – Ведомость машинных носителей информации – Пояснительная записка; – Описание информационного обеспечения системы; – Описание автоматизируемых функций; – Схема функциональной структуры; – Описание организации информационной базы; – Описание программного обеспечения; · Макеты экранных форм компонента «Интерактивная карта»; · Руководство по безопасной разработке программного обеспечения; · Документ о приемке Начало: с даты заключения контракта Окончание: не позднее 31.07.2026 2 Услуги по технической поддержке Модуля СЦ (с даты заключения контракта по 10.09.2026) По окончании оказания Услуг сопроводительным письмом предоставляются Заказчику: – Отчет об оказанных Услугах по технической поддержке; – Актуальные на дату окончания оказания Услуг по данному этапу исходные коды прикладного ПО на электронном носителе (в случае внесения изменений); – Инструкция по сборке и развертыванию (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство пользователя (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство администратора (в случае внесения изменений); – Документ о приемке Начало: с даты заключения контракта Окончание: не позднее 10.09.2026 3 Разработка программного обеспечения (1 очередь, пп. 4.2.1, 4.2.6 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ; – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 1 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 1 очереди; – Руководство по резервному копированию; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 16.09.2026 4 Разработка программного обеспечения (2 очередь, пп. 4.2.3, 4.2.4 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ. – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 2 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 2 очереди; – Руководство по резервному копированию; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 25.09.2026 5 Разработка программного обеспечения (3 очередь, пп. 4.2.2, 4.2.5 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ; – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 3 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 3 очереди; – Руководство по резервному копированию; – Описание ролевой модели; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 09.10.2026 6 Опытная эксплуатация (1 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акт о завершении опытной эксплуатации 1 очереди; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке 17.09.2026 Окончание: не позднее 26.10.2026 7 Опытная эксплуатация (2 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акт о завершении опытной эксплуатации 2 очереди; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке 26.09.2026 Окончание: не позднее 26.10.2026 8 Опытная эксплуатация (3 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Акт о завершении опытной эксплуатации 3 очереди; – Документ о приемке Начало: с 10.10.2026 Окончание: не позднее 26.10.2026 9 Приемочные испытания Сопроводительным письмом предоставляются Заказчику: – Программа и методика приёмочных испытаний; – Протокол приемочных испытаний; – Исходные коды и дистрибутивы на электронном носителе (при условии внесения изменений, с учетом доработок по результатам опытной эксплуатации и проведенных испытаний); – Комплект рабочей документации на Модуль СЦ (при условии внесения изменений, с учетом доработок по результатам опытной эксплуатации и проведенных испытаний); – Акт приемки Системы в эксплуатацию; – Акт приемки-передачи исключительных прав на объект; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке; – Документы в соответствии с разделом 4.5.9 ТЗ; – Обеспечение гарантийных обязательств Начало: с 27.10.2026 Окончание: не позднее 10.11.2026 10 Услуги по технической поддержке Модуля СЦ (с 11.09.2026 по 15.12.2026) По окончании оказания Услуг сопроводительным письмом предоставляются Заказчику: – Отчет об оказанных Услугах по технической поддержке; – Актуальные на дату окончания оказания Услуг по данному этапу исходные коды прикладного ПО на электронном носителе (в случае внесения изменений); – Инструкция по сборке и развертыванию (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство пользователя (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство администратора (в случае внесения изменений); – Документ о приемке Начало: с 11.09.2026 Окончание: не позднее 15.12.2026 Работы по развитию Системы (за исключением этапов проведения опытной эксплуатации и услуг по технической поддержке) могут быть выполнены досрочно. При досрочном выполнении работ (этапов работ) Подрядчик в письменной форме уведомляет Заказчика о готовности представить для приемки результаты проведения работ в соответствии с требованиями Контракта. Подрядчик также вправе досрочно приступать к работам в рамках очередного этапа при наличии технической, организационной готовности - при условии получения соответствующего согласования Заказчиком. Сдача-приемка результатов выполненных работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная, техническая документация, а также результаты Работ по каждому этапу предоставляется Заказчику в порядке, предусмотренном Контрактом и настоящим Техническим заданием, до размещения Подрядчиком в Единой информационной системе в сфере закупок документа о приемке. Документ о приемке размещается в ЕИС по каждому этапу в соответствии с условиями Контракта. Согласование документов осуществляется в электронном виде посредством переписки с адресов электронной почты Заказчика и Подрядчика, указанных в контракте. 6. ПОРЯДОК РАЗРАБОТКИ МОДУЛЯ СЦ Проектирование Модуля СЦ должно включать разработку следующих документов: – Ведомость технического проекта; – Ведомость машинных носителей информации – Пояснительная записка; – Описание информационного обеспечения системы; – Описание автоматизируемых функций; – Схема функциональной структуры; – Описание организации информационной базы; – Руководство по безопасной разработке программного обеспечения; – Описание программного обеспечения; – Макеты экранных форм компонента «Интерактивная карта». Структура документов должна соответствовать ГОСТ Р 59795-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов». Разработка Модуля СЦ должна включать в себя: – разработку программного обеспечения в части новых функций Модуля СЦ; – сборка исходного кода, развертывание и настройку доработанного программного обеспечения Модуля СЦ на вычислительных мощностях Заказчика (тестовый контур); – Комплект рабочей документации на Модуль СЦ; – разработку документа «Программа и методика предварительных испытаний»; – разработку документа «Программа и методика приемочных испытаний»; – разработку документа «Программа опытной эксплуатации». Структура документов должна соответствовать ГОСТ Р 59795-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов». В ходе выполнения работ формируется правоустанавливающая, отчетная, рабочая и техническая документация в соответствии с Контрактом и Календарным планом, приведенном в разделе 5. Значение характеристики не может изменяться участником закупки 6.1. Сведения о гарантийном обслуживании Модуля СЦ Под гарантией понимается устранение Подрядчиком своими силами и за свой счет допущенных по его вине недостатков, выявленных после приемки выполненных Работ, как в работе самой Модуля СЦ, так и недостатков в отчетной документации. Если в период гарантийного срока обнаружатся недостатки, то Подрядчик обязан устранить их за свой счет, в сроки, установленные Заказчиком. Гарантийный срок в этом случае продлевается на период устранения недостатков. Срок гарантии: 1 год с даты приемки Заказчиком результатов исполнения Этапа № 9 контракта. Подрядчиком должны быть внесены соответствующие исправления в техническую и рабочую документацию (указанную в пунктах 5 и 6 настоящего ТЗ), связанные с устранением замечаний к работе Модуля СЦ или в случае выявления Заказчиком недостатков в такой документации в период гарантийного срока. Внесение изменений в документацию технического и рабочего проектирования осуществляется в соответствии с ГОСТ 2.503-2023 и ГОСТ Р 2.504-2021. 7. ПОРЯДОК КОНТРОЛЯ И ПРИЕМКИ РЕЗУЛЬТАТОВ ВЫПОЛНЕНИЯ РАБОТ ПО РАЗВИТИЮ МОДУЛЯ СЦ Испытания должны быть организованы и проведены в соответствии с ГОСТ Р 59792-2021 «Информационная технология. Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем». Должны быть проведены следующие виды испытаний: – предварительные испытания; – опытная эксплуатация; – приемочные испытания. Указанные виды испытаний проводятся в отношении не функциональных требований и функциональных возможностей, разрабатываемых в соответствии с настоящим ТЗ. Отдельные виды испытаний проводятся поэтапно в сроки, установленные Календарным планом. Предварительные испытания, опытная эксплуатация, приемочные испытания проводятся комиссией, создаваемой организационно-распорядительным документом Заказчика, который должен определять состав комиссии, порядок ее работы. Методы предварительных испытаний и порядок их проведения должны быть определены в документе «Программа и методика предварительных испытаний», который должен быть утвержден Заказчиком до начала предварительных испытаний. По результатам предварительных испытаний оформляется Протокол предварительных испытания и Акт о приемке в опытную эксплуатацию. Порядок проведения и методы испытаний во время опытной эксплуатации должны быть определены в документе «Программа опытной эксплуатации», который должен быть утвержден Заказчиком до начала опытной эксплуатации. Ход и результаты опытной эксплуатации отражаются в документе «Журнал опытной эксплуатации», и учитываются в ходе приемочных испытаний. По результатам опытной эксплуатации подписывается Акт о завершении опытной эксплуатации Значение характеристики не может изменяться участником закупки До момента подключения внешних ИС, Подрядчиком могут быть использованы эмуляторы ИС для прохождения предварительных испытаний, опытной эксплуатации и приемочных испытаний. В рамках опытной эксплуатации должны быть проведены мероприятия по нагрузочному тестированию Модуля СЦ. Документ «Программа и методика приемочных испытаний» должен быть разработан с учетом недостатков, выявленных в ходе опытной эксплуатации, утвержден Заказчиком до начала приемочных испытаний, при этом проверки Модуля СЦ в части не устраненных недостатков, выявленных в процессе опытной эксплуатации, должны быть вынесены в отдельный раздел «Программы и методики приемочных испытаний». В процессе приемочных испытаний должно быть проверено устранение недостатков, полученных в ходе опытной эксплуатации. После завершения устранения всех замечаний, препятствующих приемке Системы в эксплуатацию, перечисленных в Протоколе приемочных испытаний, Подрядчик должен письменно уведомить Заказчика о том, что все замечания устранены, после чего приемочные испытания по решению Заказчика могут быть проведены повторно. Процедура приемочных испытаний проводится до подписания Протокола приемочных испытаний, не содержащего замечаний, препятствующих приемке Системы в эксплуатацию. Приемочные испытания Системы считаются завершенными успешно, если Протокол приемочных испытаний не содержит замечаний, препятствующих приемке Системы в эксплуатацию 8. ТРЕБОВАНИЯ К СОСТАВУ И СОДЕРЖАНИЮ РАБОТ ПО ПОДГОТОВКЕ МОДУЛЯ СЦ К ВВОДУ В ЭКСПЛУАТАЦИЮ По результатам проведения приемочных испытаний оформляется Протокол приемочных испытаний и Акт приемки в эксплуатацию. В случае, если взаимодействие с внешними системами не может быть проверено на средах постоянной эксплуатации взаимодействующих систем (по причине неготовности со стороны внешней системы или иным причинам), функции взаимодействия, разработанные в соответствии с требованиями ТЗ, должны быть проверены на тестовых данных с использованием программ-имитаторов взаимодействия. По результатам выполнения этапа приемочных испытаний должны быть подготовлены материалы для регистрации доработанной версии Модуля СЦ (объекта учета) в НФАП в соответствии с требованиями постановления Правительства Российской Федерации от 30 января 2013?г. №?62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин» (с изменениями и дополнениями) в части обязательности размещения результатов работ в национальном фонде алгоритмов и программ для электронных вычислительных машин. Сдача-приемка результатов выполнения Работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная, техническая документация, а также программное обеспечение предоставляется Заказчику в порядке, предусмотренном Контрактом и ТЗ до размещения Подрядчиком в Единой информационной системе в сфере закупок документа о приемке. Результаты проведения опытной эксплуатации, предварительных и приемочных испытаний должны быть зафиксированы в соответствующих протоколах и актах. Выявленные отклонения от настоящего ТЗ, оформляются как недостатки Модуля СЦ Значение характеристики не может изменяться участником закупки Протоколы предварительных и приемочных испытаний должны содержать вывод о соответствии Модуля СЦ предъявляемым требованиям, а также сроки устранения замечаний и реализации рекомендаций, сформулированных комиссией в ходе предварительных и приемочных испытаний. Условием для передачи Модуля СЦ в промышленную эксплуатацию является устранение всех замечаний. Документация на Модуль СЦ и ее части (техническая и рабочая) должна содержать исчерпывающее описание принятых проектных решений в объеме, достаточном для ее дальнейшего развития и эксплуатации. Техническая и рабочая документация должна содержать описание разработанных результатов работ, в том числе программ для ЭВМ, прикладных программных интерфейсов, алгоритмов и протоколов информационного взаимодействия, технических требований, спецификаций и форматов обмена данными для взаимодействия с другими информационными системами, в объеме, достаточном для их установки, настройки, эксплуатации и развития в дальнейшем без привлечения Подрядчика. Исходные коды передаются в виде и составе, позволяющем провести: – сборку (компиляцию) Модуля СЦ в контролируемой Заказчиком среде; – установку полученной Модуля СЦ на специально подготовленную контролируемую Заказчиком инфраструктуру; – проверку функциональных возможностей Модуля СЦ; – оформление Модуля СЦ в качестве объекта национального фонда алгоритмов и программ для электронных вычислительных машин 8.1. Требования, предъявляемые в соответствии с Приказом Минцифры России от 17.12.2020 № 715 «Об утверждении типовых условий контрактов на выполнение работ по созданию и (или) развитию (модернизации) государственных (муниципальных) и (или) иных информационных систем» Передача исходных кодов, разработанных в ходе выполнения работ, программ для электронных вычислительных машин (далее – программа для ЭВМ) должна сопровождаться передачей всех необходимых для сборки и запуска программы для ЭВМ библиотек зависимостей, программных сценариев (скриптов) для проведения установки (развертывания) программы для ЭВМ. Подрядчик в процессе сдачи-приемки работ по Контракту должен провести демонстрацию процесса и установки (развертывания) разработанных программ для ЭВМ. Документация на Модуль СЦ должна содержать описание принятых проектных решений в объеме, достаточном для ее дальнейшего развития и эксплуатации 9. ТРЕБОВАНИЯ К ДОКУМЕНТИРОВАНИЮ 9.1. Общие требования Документация на Модуль СЦ должна быть разработана в составе, указанном в разделах 5-8 данного ТЗ, и должна удовлетворять требованиям комплекса стандартов и руководящих документов на автоматизированные системы: – ГОСТ Р 2.105-2019 в части оформления текстовых документов; – ГОСТ 34.201-2020 в части наименования и обозначения документов. Документация на Модуль СЦ должны оформляться на листах формата А4. Допускается для размещения рисунков и таблиц использование листов формата А3 с подшивкой по короткой стороне листа. Документы объемом более 25 (двадцати пяти) листов должны содержать информационную часть, состоящую из аннотации и содержания. Исходные коды должны быть представлены в 1 (одном) экземпляре на электронном носителе, отчетные материалы должны быть представлены в 2 (двух) экземплярах на бумажном носителе (по одному экземпляру для Заказчика и Подрядчика) и в 1 (одном) экземпляре на электронном носителе в формате документов DOCX и PDF. При разработке документов на Модуль СЦ допускается отклонение от требований комплекса стандартов, описанных выше. Документам на Модуль СЦ должны в обязательном порядке присваиваться уникальные децимальные номера в соответствии с порядком, установленном в ГОСТ 34.201-2020. Документ «Программа и методика предварительных испытаний» должен включать приложения с формой протокола предварительных испытаний и формой акта приемки в опытную эксплуатацию. Документ «Программа опытной эксплуатации» должен включать приложение с формой журнала опытной эксплуатации. Документ «Программа и методика приемочных испытаний» должен включать приложения с формой протокола приемочных испытаний и формой акта приемки в эксплуатацию Значение характеристики не может изменяться участником закупки 10. ИСТОЧНИКИ РАЗРАБОТКИ 10.1. Список литературы Специальная литература для разработки ТЗ не использовалась. 10.2. Нормативно-методические документы Список используемых нормативно-методических документов представлен в разделе 1.6 технического задания. ? Приложение А Эскизы визуального оформления компонента «Интерактивная карта» Значение характеристики не может изменяться участником закупки Приложение Б Параметры оказания услуг Б.1. Базовые параметры оказания Услуг Базовые параметры оказания Услуг приведены ниже: – режимы оказания Услуг (таблица Б.1.1); – сроки предоставления отчетности (таблица Б.1.2). Таблица Б.1.1 - Режимы оказания Услуг № п/п Параметр Значение Значение характеристики не может изменяться участником закупки 1 Режим работы Системы Круглосуточно (24х7) 2 Режим доступности информационно-консультационной поддержки пользователей Системы 2.1 Прием и регистрация обращений (заявок) в СРО Регистрация обращений (заявок) производится круглосуточно в режиме 24х7, без праздников и выходных дней. Обработка заявок первой линией поддержки осуществляется в рабочие дни с 9 до 18 часов 2.2 Консультирование сотрудников Заказчика и пользователей Системы в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 3 Режим доступности по решению инцидентов, связанных с работой ППО: 3.1 - приоритет «Критический» Круглосуточно (24х7) 3.2 - приоритет «Высокий» Круглосуточно (24х7) 3.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 3.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4 Режим доступности услуг по адаптации, конфигурации и коррекционному сопровождению Системы 4.1 - приоритет «Критический» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.2 - приоритет «Высокий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 5 Режим доступности по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности 5.1 - приоритет «Критический» Круглосуточно (24х7) 5.2 - приоритет «Высокий» Круглосуточно (24х7) 5.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 5.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) Таблица Б.1.2. Сроки предоставления отчетности, с момента получения запроса № п/п Параметр Значение 1 Предоставление отчета об оказанных услугах за произвольный период 10 рабочих дней 2 Предоставление подробной информации по инциденту с приоритетом «Критический» 16 рабочих часов 3 Предоставление актуализированной документации 10 рабочих дней Б.2. Приоритеты и регламентные сроки решения обращений (заявок) В зависимости от уровня сбоя в работе Системы обращению (заявке) присваивается один из следующих приоритетов, а также в зависимости от приоритета обращения (заявки) устанавливаются следующие контрольные сроки решения в соответствии с таблицей ниже (Таблица Б.2.1). Таблица Б.2.1 – Приоритеты и регламентные сроки решения обращений (заявок) № п/п Приоритет Максимальное время реагирования Время решения (срок выполнения) Описание приоритета По информационно-консультационной поддержке сотрудников Заказчика и пользователей Системы 1 - не более 1 часа не более 10 часов - По решению инцидентов, связанных с работой ППО: 1 Критический не более 30 минут не более 4 часов - полная недоступность ППО; - недоступность ключевых функций - ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО; - невозможность информационного обмена с ППО для ИС более 4 часов 2 Высокий не более 1 часа не более 8 часов - ошибки/сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; - снижение быстродействия СПО (время отклика ППО на операции превышает 30 секунд); - недоступность управления правами и ролями пользователей 3 Средний не более 4 часов не более 24 часов - невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым -недоступность функции формирования отчетов 4 Низкий не более 8 часов не более 40 часов - отклонение в работе ППО, не влияющее на корректную работу функций; - другие сбои и ошибки, затрагивающие основные функции ППО По адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) 1 Критический не более 40 минут не более 8 часов - изменения, необходимые при проведении аварийно-восстановительных работ для возобновления работоспособности Системы; - изменения, связанные с критичными ошибками, блокирующими возможность оказания государственных услуг и/или чтение и внесение данных в Систему 2 Высокий не более 1 часа не более 40 часов - изменения, относящиеся к обеспечению работоспособности основной функциональности Системы, устраняют выявленные дефекты в работе Системы, оказывающие существенное влияние на работу пользователей в Системе; - изменения, затрагивающие три и более подсистемы/модуля Системы для адаптации 3 Средний не более 4 часов не более 72 часов - изменения, связанные с развитием/улучшением/оптимизацией Системы и выводом новой функциональности в штатном режиме для одного-двух модулей/подсистем; - изменения, связанные с развитием интеграционных механизмов Системы, например обновление существующих и/или реализация новых видов сведений СМЭВ, обновление существующих и/или реализация новых API, адаптация и/или изменение механизмов импорта и экспорта данных Системы и т.д. 4 Низкий не более 8 часов не более 160 часов - изменения, связанные с ошибками/корректировкой/изменением в отображении информации в пользовательском графическом интерфейсе Системы (графика, текст, органы управления, элементы интерфейса) По устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности 1 Критический не более 30 минут не более 24 часов - критические уязвимости, влияющие на возможную полную недоступность ППО, ключевых функций Системы, ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО без возможности восстановления работоспособности Системы. - Критический уровень CVSS > 8.0 2 Высокий не более 1 часа не более 84 часов - критические уязвимости, влияющие на ошибки и сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО. - Высокий уровень CVSS 5.0 - 8.0 3 Средний не более 4 часов не более 120 часов - уязвимости, влияющие на невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым - Средний уровень CVSS 2.0 - 4.9 4 Низкий не более 8 часов не более 160 часов - уязвимости, влияющие на отклонение в работе ППО, не влияющее на корректную работу функций; - другие сбои и ошибки, затрагивающие основные функции ППО - Низкий уровень CVSS < 2.0 Взаимодействие Заказчика и Подрядчика в части регистрации и контроля времени реагирования и решения обращения (заявки) осуществляется через СРО. Заказчик предоставляет Подрядчику доступ к СРО после заключения Контракта. Поступившие от разных пользователей заявки по поводу однотипных инцидентов или имеющие общую причину должны объединяться в одну заявку. Срок выполнения включает время диагностики инцидента, в ходе которого определяется причина инцидента (проблемы) и способ его устранения. Подрядчик должен обеспечить функционирование Модуля СЦ в соответствии с требованиями и параметрами, указанными в настоящем ТЗ и Регламенте оказании услуг. Основные параметры быстродействия типовых операций в Модуле СЦ указаны в таблице ниже (таблица Б.2.2). Таблица Б.2.2 - Параметры быстродействия Модуля СЦ № п/п Наименование параметра Значение (секунд) 1 Среднее время получения сообщения из очереди сообщений 10 2 Среднее время получения ответа от Системы 5 3 Среднее время открытия карточки реестра 5 Приложение В Регламент оказания услуг Приложение Д Форма Протокола проверки результатов организационно-штатных и подготовительных мероприятий (шаблон) Протокол проверки результатов организационно-штатных и подготовительных мероприятий Настоящий Протокол содержит результаты проверки организационно-штатных и подготовительных мероприятий, проведенных Исполнителем (Таблица Д.1). Таблица Д.1. Протокол проверки результатов № Мероприятия Подготовительного этапа Результат проверки 1. Определить и направить Заказчику документ «Ответственные за взаимодействия в рамках выполнения работ по техническому сопровождению Системы со стороны Исполнителя». Документ содержит контактную информацию (ФИО, должность, адрес электронной рабочей почты, номер телефона) не менее чем о 2 лицах, ответственных за оказание услуг со стороны Подрядчика Выполнено/Не выполнено 2. Обеспечить подключение специалистов Подрядчика к Системе Выполнено/Не выполнено 3. Обеспечить подключение специалистов Подрядчика к СРО Выполнено/Не выполнено Заказчик Подрядчик /Должность/ /Должность/ ____________________ /Ф.И.О/ ___________________ /Ф.И.О/ М.П. М.П. «_____»_______________________202_г. «_____»_______________________202_г Значение характеристики не может изменяться участником закупки Термины и сокращения В настоящем регламенте используются следующие термины и сокращения на русском и английском языках: Термины/сокращения Полное наименование/описание БЗ (База знаний) База данных Системы регистрации обращений (заявок), созданная для сбора, хранения и поиска способов решения известных проблем в рамках Системы Жизненный цикл обращения (заявки) Совокупность статусов, по которым проходит обращение (заявка), и правила перехода обращения (заявки) из одного статуса в другой Заказчик ФГБУ «СИЦ Минтранса России» – Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» ЗНИ Запрос на изменение – тип заявки, предполагающий внесение изменений в прикладное программное обеспечение Системы ЗНО Запрос на обслуживание – тип заявки, предполагающий работы по предоставлению консультации, предоставление доступа к Системе или стандартизированные типовые изменения конфигураций Системы Инцидент Тип заявки, классифицируемый как нештатное событие в работе компонентов функциональных задач Системы, которое привело или может привести к нарушению или снижению качества функционирования Системы ИС Информационная система Исполнитель Организация, которая определяется по результатам конкурсных процедур Классификация Анализ и заполнение классификационных полей справочными значениями, определяющими последовательность действий и этапов жизненного цикла заявки, а также порядок рассмотрения заявок Консультация Разъяснения по алгоритму работы, требуемых настроек прикладного программного обеспечения и технологии обработки данных при работе с Системой, предоставление информации Маршрутизация Определение процесса движения обращения (заявки) в Системе управления заявками между уровнями технической поддержки и организационными структурами на уровнях поддержки путем назначения обращения (заявки) в соответствии с его классификацией и выставленным приоритетом Обращение (заявка) Устное или письменное обращение пользователя АСУ ТК с вопросом, касающимся работоспособности АСУ ТК, по одному из определённых каналов связи: электронная почта, Система регистрации обращений (заявок) Пользователь Инициатор обращения (заявки) или пользователь Системы ППО Прикладное программное обеспечение Предмет обращения Справочник, классифицирующий типовые запросы в Системе регистрации обращений (заявок), характерные для Системы, выбранное значение определяет маршрутизацию обращения (заявки) (группу ответственных сотрудников) Приоритизация Значение, определяющее время, очередность решения обращений (заявок), ресурсы, привлекаемые для решения обращений (заявок), . Приоритет устанавливается в соответствии с масштабом выявленной проблемы, которая привела или может привести к нарушению или снижению качества функционирования Системы Релиз Выпуск версии прикладного программного обеспечения Системы, от разработки до тестирования и планового обновления Системы на продуктивной среде для установки изменений, связанных с развитием/улучшением/оптимизацией Системы Система, АСУ ТК, Информационно-аналитическая система регулирования на транспорте Информационно-аналитическая система, предназначенная для автоматизации и информационно-аналитического обеспечения процессов управления развитием транспортного комплекса Российской Федерации, обеспечения публичности деятельности органов государственного управления транспортным комплексом, а также обеспечения процессов оказания государственных услуг в электронном виде в сфере транспорта СМЭВ Система межведомственного электронного взаимодействия СПО Системное программное обеспечение СРО Система регистрации обращений (заявок) Статус обращения (заявки) Текущее состояние обращения (заявки) в жизненном цикле процесса оказания технической поддержки Системы СУБД Система управления базами данных Уровень технической поддержки Организационно-структурная часть технической поддержки, имеющая определённые организационно-нормативными документами зоны ответственности, обязанности, а также временные нормативы, в течение которых эти обязательства должны выполняться либо эскалироваться на следующий уровень технической поддержки Услуги Услуги по технической поддержке Информационно-аналитической системы регулирования на транспорте АСУ ТК ФИО Фамилия, имя, отчество Эскалация Процедура повышения внимания к обращению (заявке) путем повышения его приоритета и/или передачи на следующий уровень технической поддержки, а также привлечение ролей, которые могут принимать решения без передачи на следующий уровень технической поддержки API Англ. Application Programming Interface — программный интерфейс приложения, интерфейс прикладного программирования — описание способов (набор классов, процедур, функций, структур или констант), которыми одна компьютерная программа может взаимодействовать с другой программой CVSS Англ. Common Vulnerability Scoring System - открытый стандарт, используемый для расчета количественных оценок уязвимости в безопасности компьютерной системы, обычно с целью понять приоритет ее исправления. В современном инструментарии информационной безопасности используется версия 3.0 и выше с дополнительными метриками к базовым оценкам ID Англ. Identifier – идентификатор, уникальный признак объекта, позволяющий отличать его от других объектов, то есть, идентифицировать SLA Англ. Service Level Agreement - утвержденные условия по обработке обращения (заявки) с установленными метриками времени, которые определяют пороговые значения для эскалации в зависимости от статуса обращения (заявки) (например, время реакции – время от регистрации до осуществления первичной обработки, время решения – время от регистрации обращения (заявки) до его решения и т.д.) SQL Англ. Structured Query Language — «язык структурированных запросов», — декларативный язык программирования, применяемый для создания, модификации и управления данными в реляционной базе данных, управляемой соответствующей СУБД 1 Общие сведения 1.1 Полное наименование Услуг Оказание услуг по технической поддержке Модуля СЦ АСУ ТК в 2026 году. 1.2 Предмет Регламента оказания услуг Требования Технического задания 2 Общие положения 2.1 Цель и задачи оказания услуг Целью технической поддержки Системы является обеспечение ее стабильного и безопасного функционирования и эксплуатации, предупреждение, выявление и устранение сбоев в работе Системы и минимизация их неблагоприятного влияния. Для достижения поставленной цели требуется решение следующих задач: 1. Обеспечение информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы. 2. Поддержание параметров функционирования ППО Системы, удовлетворяющих требованиям производственных процессов, включая их непрерывность. 3. Обеспечение бесперебойного функционирования ППО и своевременное устранение сбоев и аварийных ситуаций в Системе. 4. Своевременное устранение уязвимостей при выявлении таковых, в соответствии с требованиями к обеспечению информационной безопасности. 5. Адаптация, конфигурирование, коррекция программного обеспечения в соответствии с изменениями нормативно-правовой базы и запросами уполномоченных сотрудников органов государственной власти, включая выполнение процедур тестирования и участие в обновлениях ППО на стендах Заказчика. 6. Обеспечение сохранения работоспособности ППО в изменяемой среде эксплуатации. 7. Ведение документации по настоящему контракту и инициирование актуализации документации на Систему по результатам обработки запросов Заказчика и внесения соответствующих изменений в ППО 2.2 Общее описание процесса оказания сопровождения (технической поддержки) Системы Процесс оказания технической поддержки Системы включает: 1. Поступление обращений (заявок) от пользователей и их регистрацию. 2. Сопровождение обращений (заявок) в соответствии с их классификацией и приоритизацией, в том числе, с их последующей эскалацией. 3. Определение ролей и регламент их взаимодействия при осуществлении деятельности по процессу. 4. Решение обращений (заявок) в установленные настоящим Регламентом сроки. 5. Взаимодействие между 1-м, 2-м и 3-м уровнями технической поддержки, в том числе, с формированием заданий для сопровождения Системы. 6. Контроль качества выполняемых Исполнителем работ, состоящий из проверки сценария, приводящего к ошибке, зафиксированной в Инциденте, и/или к ошибке воспроизведения, а также тестирование внесенных изменений в рамках ЗНИ. 7. Обеспечение мониторинга и проведение анализа процесса обработки поступающих в техническую поддержку обращений (заявок). Техническая поддержка реализуется путем проведения ответственными сотрудниками соответствующей информационно-консультационной деятельности в соответствии с определенными ролями, а также выполнения Исполнителем конкретных действий по своевременному выявлению причин сбоев и аварийных ситуаций и их устранению, а также по адаптации, конфигурированию, корректировке Системы, включая выполнение процедур тестирования и участия в обновлениях Системы. Все роли подразделяются на уровни поддержки, взаимодействующие между собой в соответствии с блок-схемой процесса технической поддержки. Общая схема процесса рассмотрения обращений (заявок) в соответствии с видами технической поддержки представлена на рисунке 1. . Рисунок 1 - Общая схема процесса рассмотрения обращений (заявок) в соответствии с видами технической поддержки 2.3 Каналы связи Должна быть предусмотрена омниканальность в части приема обращений (заявок). Получение обращений (заявок) технической поддержкой происходит по следующим каналам связи: – СРО; – электронная почта; – телефонная линия. Исполнитель обеспечивает прием обращений (заявок) от Заказчика и предоставляет информацию в рамках оказания услуг по техническому сопровождению Системы, руководствуясь матрицей взаимодействия, приведенной в Приложении 1 к настоящему Регламенту 3 Порядок оказания Услуг 3.1 Типы обращений (заявок) Обращения и заявки Заказчика классифицируются в соответствии с приоритетами и регламентными сроками, указанными в Приложении 2 к настоящему Регламенту. Регистрация обращений и заявок предусматривает создание новой записи в СРО с присвоением поступившему обращению или заявке (новой записи) уникального идентификатора. Запись в СРО должна содержать вопрос или проблему, которую требуется решить или оказать консультацию. Если обращение или заявка автоматически зарегистрированы в СРО при отправке представителем Заказчика, Исполнитель проверяет корректность указанного типа обращения (заявки) и может обратиться к Заказчику с просьбой корректировки, предоставив обоснования в соответствии с настоящей классификацией (Таблица 1) Таблица 1 - Типы обращений (заявок) Тип обращения (заявки) Описание Запрос на обслуживание Подготовка SQL запроса к СУБД для решения прикладной задачи и д р. – запрос на любое действие, не являющееся запросом информации и несовершенный на основе происшествия, прямо или косвенно влияющего на работу Системы Консультация (входит в тип обращения (заявки) «Запрос на обслуживание») «Где взять / куда обратиться...?», «Как сделать / выполнить…», «Как это работает…?» - запрос, имеющий своей целью получение информационной поддержки Инцидент Разбор ошибок/сбоев и подготовка материалов (корректировочных релизов, инструкций) для Заказчика для устранения ошибок/сбоев, которые приводят к частичному и полному нарушению работоспособности всех или отдельных функций ППО. Подготовка изменения и материалов, необходимых для проведения аварийно-восстановительных работ для возобновления работоспособности Системы. ЗНИ Подготовка изменений, связанных с изменением, улучшением/оптимизацией Системы и выводом новой модифицированной функциональности в штатном режиме. Подготовка изменений, связанных с модификацией существующих и/или реализация новых интеграционных механизмов для получения/обработки данных внешних систем. Подготовка изменений графического интерфейса по требованиям Заказчика 3.2 Участники технической поддержки, осуществляющие сопровождение обращений (заявок) Техническая поддержка Системы должна быть организована на трех уровнях: 1. Первый и второй уровни технической поддержки организуется Заказчиком. 2. Третий уровень технической поддержки организуется Исполнителем. Зона ответственности каждого уровня технической поддержки указана в Таблице 2. Таблица 2 - Зона ответственности каждого уровня технической поддержки Участники технической поддержки Описание Первый уровень технической поддержки (далее – 1-й уровень) Группа ответственных сотрудников 1-го уровня Заказчика, осуществляющая прием и первичную обработку обращений (заявок) (описание предмета обращения, первичная классификация и приоритизация, определение назначения, маршрутизация обращений (заявок) по назначению), руководствуется в своей работе настоящим Регламентом и БЗ, наполняемой 2-м уровнем поддержки, самостоятельно решает часть обращений (заявок), связанных с недостаточной квалификацией пользователей или настройками в рамках своей компетенции. В случае невозможности решения обращений (заявок) на 1-ом уровне ответственный сотрудник передает ее на 2-й уровень Второй уровень технической поддержки (далее – 2-й уровень) Группа ответственных сотрудников 2-го уровня Заказчика по установленным компетенциям (информационная безопасность, сопровождение и эксплуатация информационно-аналитических систем, развитие информационно-аналитических систем, техническая поддержка информационно-аналитических систем) отвечает за поддержание работоспособности Системы, обработку обращений (заявок) и их решение в регламентные сроки в соответствии с установленными приоритетами. Осуществляет информационно-консультационную поддержку пользователей Системы в рамках своей компетенции. Оказывает экспертную помощь ответственным сотрудникам 1-го уровня в части формирования БЗ, содержащей ответы на часто задаваемые вопросы пользователей, с целью передачи знаний, навыков и инструментария на 1-й уровень для ускорения решения обращений (заявок). В случае невозможности решения обращения (заявки) на 2-ом уровне ответственный сотрудник передает его на 3-й уровень. При выявлении необходимости изменений в ППО Системы инициирует формирование обращения (заявки) и направляет его на группу ответственных сотрудников 3-го уровня по соответствующему классификатору (ЗНО, ЗНИ, и т.д.) Третий уровень технической поддержки (далее – 3-й уровень) Группа ответственных сотрудников Исполнителя, отвечающая за устранение сбоев и аварий, проведение информационно-консультационной поддержки пользователей Системы, проведение адаптации и конфигурирования Системы в объемах действующих контрактов на оказание технической поддержки 3.3 Перечень и описание статусов обращений (заявок) В Таблице 3 приведен перечень статусов обращений (заявок), действующий в СРО, и их описание. Таблица 3 - Перечень статусов обращений (заявок) и их описание Статус Описание Зарегистрирован Обращение (заявка) принято и зарегистрировано Направлен в группу Присваивается при назначении ответственными сотрудниками 1-го уровня группе ответственных сотрудников 2-го уровня по тематике обращения (заявки) после заполнения всей необходимой информации и полей обращения (заявки), а также при его передаче между группами 2-го уровня Передан в группу Присваивается при передаче обращения (заявки) ответственными сотрудниками 2-го уровня на группу ответственных сотрудников 3-го уровня Назначен Присваивается при назначении обращения (заявки) на ответственного сотрудника для его решения в рамках компетенции В работе Присваивается при приеме обращения (заявки) в работу ответственным сотрудником для его решения Решен Присваивается ответственным сотрудником, выполнившим работы по обращению (заявке) Закрыт Присваивается автоматически при решении запроса по обращению (заявке), а также отсутствии дополнительных запросов пользователя в соответствии с действующим SLA, или при подтверждении решения обращения (заявки) со стороны пользователя Запрос доп. информации Присваивается при необходимости запроса дополнительной информации и/или уточнения предмета обращения по обращению (заявке) у пользователя Ответ предоставлен Присваивается после ответа пользователем на запрос дополнительной информации Отклонен Присваивается, если обращение (заявка) не актуальна (по информации от пользователя), отсутствует техническая возможность решения обращения (заявки), предмет обращения не входит в компетенции технической поддержки, или существует влияние доработки на другие компоненты, что нарушает общий порядок работы Системы Согласование Присваивается при необходимости согласования направления обращения (заявки) ответственным сотрудником Заказчика на 3-й уровень Анализ Присваивается при проведении анализа на предмет возможности внесения изменений, связанных с развитием/улучшением/оптимизацией Системы и выводом новой функциональности и оценке ресурсоемкости Тестирование Присваивается Исполнителем при завершении разработки и проведенном предварительном тестировании для последующего осуществления приемочного тестирования Специалистом 2-го уровня Релиз Присваивается ответственным сотрудником Заказчика при принятии решения о возможности вывода доработки в продуктивную среду Утверждение заказчиком Присваивается при согласовании группой профильных специалистов на 2-м уровне поддержки с пользователем технического задания для внесения изменений, связанных с развитием/улучшением/оптимизацией Системы и выводом новой функциональности Доработка Присваивается в случае несогласования Заказчиком работ, проведенных Исполнителем в рамках контрактных обязательств, по внесению изменений, связанных с развитием/улучшением/оптимизацией Системы и выводом новой функциональности в штатном режиме, и необходимости последующего направления Исполнителю для ее доработки Отложен Присваивается в случае невозможности выполнения запроса, изложенного в обращении (заявке), в связи с необходимостью запроса дополнительной информации у третьих сторон 3.4 Порядок регистрации и сопровождения Заявок Порядок регистрации и сопровождения обращений (заявок) в рамках оказываемых услуг по технической поддержке Системы зависит от типа обращения (заявки): 1. Услуга по решению инцидентов, связанных с работой ППО – тип обращения (заявки) «Инцидент». 2. Услуга по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности – тип обращения (заявки) «Инцидент». 3. Услуга информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы – тип обращения (заявки) «Запрос на обслуживание» (в том числе, консультационный запрос). 4. Услуга адаптационного, конфигурационного и коррекционного сопровождения Системы (в рамках действующих программных модулей и функциональностей) – тип обращения (заявки) «Запрос на изменение». В случае недоступности СРО взаимодействие и информирование Исполнителем о ходе оказания услуги по обращению (заявке), изменению статусов обращений (заявок) осуществляется по согласованию с Заказчиком в соответствии с матрицей взаимодействия, представленной в Приложении 1 к настоящему Регламенту. 3.4.1 Инцидент На рисунке 2 представлена функциональная схема регистрации и сопровождения обращений (заявок) типа «Инцидент». Рисунок 2 - Функциональная схема регистрации и сопровождения обращений (заявок) типа «Инцидент» 3.4.2 Запрос на обслуживание На рисунке 3 представлена функциональная схема регистрации и сопровождения обращения (заявки) типа «ЗНО». Рисунок 3 - Функциональная схема регистрации и сопровождения обращения (заявки) типа «ЗНО» 3.4.3 Запрос на изменение На рисунке 4 представлена функциональная схема регистрации и сопровождения обращений (заявок) типа «ЗНИ». Рисунок 4 - Функциональная схема регистрации и сопровождения обращений (заявок) типа «ЗНИ» 3.5 Порядок классификации и приоритизации обращений (заявок) Классификация является начальной стадией процесса оказания технической поддержки, необходимой для идентификации обращения (заявки) и определения соответствующих действий для его обработки. Для проведения первичной классификации необходимо получить от пользователя и зафиксировать в описании обращения (заявки) подробные сведения о сути запроса, в том числе, для Инцидентов зафиксировать сценарий воспроизведения обнаруженной ошибки. Для проведения вторичной классификации необходимо провести анализ и диагностику для определения корневой причины и затронутой Инцидентом функциональной области (инфраструктура, сеть, ППО). В процессе классификации осуществляется первичная диагностика и оценка проблемы, описанной пользователем Системы в обращении (заявке), в части функционирования и/или удобства использования Системы. Корректная классификация позволяет увеличить скорость обработки обращения (заявки) и решения описанной в обращении (заявке) проблемы при минимальном привлечении ресурсов, в частности, за счет использования известных решений для типовых обращений (заявок), которые должны описываться в БЗ СРО. Классификация позволяет произвести первоначальное назначение обращения (заявки) на ответственного сотрудника и выставить приоритет с учетом приоритизации. Приоритизация применяется для определения критичности описанной в обращении (заявке) проблемы для функционирования ППО Системы. Приоритет рассмотрения обращения (заявки) определяется в процессе ее классификации на основании ряда параметров, вводимых при заполнении обращения (заявки). Приоритизация используется для того, чтобы при одновременном наличии нескольких обращений (заявок) в первую очередь рассматривалась обращения (заявки) с наивысшим приоритетом и не позднее установленных для данного приоритета сроков Изменение приоритета уже зарегистрированного обращения (заявки) используется в случае появления новых обстоятельств, которые ведут к изменению влияния и/или срочности существующего обращения (заявки). При регистрации обращения (заявки) необходимо провести его приоритизацию. В процессе управления обращениями (заявками) каждому обращению (заявке) присваивается приоритет, принимающий одно из значений: Низкий, Средний, Высокий или Критический. В соответствии с приоритетом определяется время, очередность устранения, , ресурсы, привлекаемые для работ по обращению (заявке), а также может определяться порядок/процедура действий при работе с обращением (заявкой). Заказчиком в зависимости от уровня сбоя в работе Системы обращению (заявке) присваивается приоритет с указанием максимального времени реакции и решения в соответствии с требованиями, указанными в Приложении 2 к настоящему Регламенту 4 Формы обращений (заявок) на оказание услуг по технической поддержке Системы, заполняемые в СРО 4.1. Форма обращения (заявки) на оказание услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы При подаче обращения (заявки) типа «ЗНО» в СРО указывается (Таблица 5): Таблица 5 – Описание атрибутов формы обращения (заявки) на оказание услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 5) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 5) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 5) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 5) Категория обращения: информационно-консультационная поддержка Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 5) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 5) Текст запроса на оказание услуги по информационно-консультационной поддержке сотрудников Заказчика Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 5) На рисунке 5 приведена форма обращения (заявки) типа «ЗНО» в СРО. Рисунок 5 - Форма обращения (заявки) типа «ЗНО» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы, заполненную в свободной форме. 4.2. Форма обращения (заявки) на оказание услуги по решению инцидентов, связанных с работой ППО При подаче обращения (заявки) типа «Инцидент» в СРО указывается (Таблица 6): Таблица 6 – Описание атрибутов формы обращения (заявки) на оказание услуги по решению инцидентов, связанных с работой ППО Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 6) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 6) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 6,) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 6) Категория обращения (заявки): инцидент Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 6) Приоритет изменения Время - одно из значений: Низкий, Средний, Высокий или Критический. Определяет, очередность решения обращения (заявки), ресурсы, привлекаемые для решения обращения (заявки), порядок/процедура действий при решении обращения (заявки) – поле СРО «Приоритет» (см. рисунок 6,) Тип изменения Справочник, классифицирующий типовые запросы характерные для Системы – поле СРО «Предмет обращения» (см. рисунок 6) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 6) Полное описание инцидента, включая скриншоты и описание шагов, приведших к неисправности Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 6) Однократность/неоднократность Круг пользователей или компьютеров, затронутых данным инцидентом Действия, предпринятые для самостоятельного решения инцидента (при наличии) Версии используемого программного обеспечения на клиентской рабочей станции, где воспроизводится ошибка (операционная система, прикладное программное обеспечение) Дополнительная информация На рисунке 6 приведена форма обращения (заявки) типа «Инцидент» в СРО. Рисунок 6 - Форма обращения (заявки) типа «Инцидент» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуги по решению инцидентов, связанных с работой ППО, заполненную в свободной форме 4.3. Форма обращения (заявки) на оказание услуг по адаптационному конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) При подаче обращения (заявки) типа «ЗНИ» в СРО указывается (Таблица 7): Таблица 7 – Описание атрибутов формы обращения (заявки) на оказание услуг по адаптационному, конфигурационному и коррекционному сопровождению Системы Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 10) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 9) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 10) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 10) Категория обращения (заявки): запрос на изменение Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 7) Приоритет изменения Время, очередность решения обращения (заявки), ресурсы, привлекаемые для решения обращения (заявки), порядок/процедура действий при решении обращения (заявки) – поле СРО «Приоритет» (см. рисунок 7) Тип изменения Справочник, классифицирующий типовые запросы характерные для Системы – поле СРО «Предмет обращения» (см. рисунок 7) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 7) Текст запроса на оказание услуги по адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 7) На рисунке 7 приведена форма обращения (заявки) типа «ЗНИ» в СРО. Рисунок 7 - Форма обращения (заявки) типа «ЗНИ» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуг по адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей), заполненную в свободной форме 4.4. Форма обращения (заявки) на оказание услуги по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности При подаче обращения (заявки) типа «Инцидент» в СРО указывается (Таблица 8): Таблица 8 – Описание атрибутов формы обращения (заявки) на оказание услуг по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 8) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 8) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 8) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 8) Категория обращения (заявки): инцидент Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 8) Приоритет Время, очередность решения обращения (заявки), ресурсы, привлекаемые для решения обращения (заявки), порядок/процедура действий при решении обращения (заявки) – поле СРО «Приоритет» (см. рисунок 8) Тип изменения Справочник, классифицирующий типовые запросы характерные для Системы – поле СРО «Предмет обращения» (см. рисунок 8) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 8) Текст запроса на оказание услуги по обновлению или удалению уязвимых компонентов (библиотек) ППО в соответствии с требованиями к обеспечению информационной безопасности Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 8) На рисунке 8 приведена форма обращения (заявки) типа «Инцидент» в СРО. Рисунок 8 - Форма обращения (заявки) типа «Инцидент» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуги по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности, заполненную в свободной форме Приложение 1 к Регламенту Матрица ответственных за взаимодействия в рамках выполнения работ по техническому сопровождению Системы Таблица 1 – Ответственные за взаимодействия в рамках выполнения работ по техническому сопровождению Системы со стороны Исполнителя ФИО Должность Адрес электронной почты Телефон — — — Общий контакт Приложение 2 к Регламенту Приоритеты и регламентные сроки решения обращений (заявок) Приоритеты и регламентные сроки решения обращений (заявок) приведены в таблице 1. Таблица 1 – Приоритеты и регламентные сроки решения обращений (заявок) № п/п Приоритет Максимальное время реагирования Время решения (срок выполнения) Описание приоритета По информационно-консультационной поддержке сотрудников Заказчика и пользователей Системы 1 – не более 1 часа не более 10 часов – По решению инцидентов, связанных с работой ППО 1 Критический не более 30 минут не более 4 часов – полная недоступность ППО; – недоступность ключевых функций; – ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО; – невозможность информационного обмена с ППО для ИС более 4 часов 2 Высокий не более 1 часа не более 8 часов – ошибки/сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; – снижение быстродействия СПО (время отклика ППО на операции превышает 30 секунд); – невозможность управления правами и ролями пользователей 3 Средний не более 4 часов не более 24 часов – невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым недоступность функции формирования отчетов 4 Низкий не более 8 часов не более 40 часов – отклонение в работе ППО, не влияющее на корректную работу функций; – другие сбои и ошибки, затрагивающие основные функции ППО По адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) 1 Критический не более 40 минут не более 8 часов – изменения необходимые при проведении аварийно-восстановительных работ для возобновления работоспособности Системы; – изменения, связанные с критичными ошибками, блокирующими возможность оказания государственных услуг и/или чтение и внесение данных в Систему 2 Высокий не более 1 часа не более 40 часов – изменения относящиеся к обеспечению работоспособности основной функциональности Системы, устраняют выявленные дефекты в работе Системы, оказывающие существенное влияние на процесс оказания государственных услуг и работу пользователей в Системе; – изменения, затрагивающие три и более подсистемы/модуля Системы для адаптации 3 Средний не более 4 часов не более 72 часов – изменения, связанные с развитием/улучшением/оптимизацией Системы и выводом новой функциональности в штатном режиме для одного-двух модулей/подсистем; – изменения, связанные с развитием интеграционных механизмов Системы, например, обновление существующих и/или реализация новых видов сведений СМЭВ, обновление существующих и/или реализация новых API, адаптация и/или изменение механизмов импорта и экспорта данных Системы и т.д. 4 Низкий не более 8 часов не более 160 часов – изменения, связанные с ошибками/ корректировкой/изменение в отображении информации в пользовательском графическом интерфейсе Системы (графика, текст, органы управления, элементы интерфейса) По устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности 1 Критический не более 30 минут не более 24 часов – критические уязвимости, влияющие на возможную полную недоступность ППО, ключевых функций Системы, ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО без возможности восстановления работоспособности Системы; – Критический уровень CVSS > 8.0 2 Высокий не более 1 часа не более 84 часов – критические уязвимости, влияющие на ошибки и сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; – Высокий уровень CVSS 5.0 - 8.0 3 Средний не более 4 часов не более 120 часов – уязвимости, влияющие на невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым; – Средний уровень CVSS 2.0 - 4.9 4 Низкий не более 8 часов не более 160 часов – уязвимости, влияющие на отклонение в работе ППО, не влияющее на корректную работу функций; – другие сбои и ошибки, затрагивающие основные функции ППО; – Низкий уровень CVSS < 2.0 Приложение Г Форма Отчета об оказанных услугах Отчет об оказанных услугах за этап «наименование этапа» в период с «__» _________ по «__» _________. № п/п Наименование услуги Общее количество Номер ОРС Краткое Описание Время реагирования по ТЗ Время реагирования фактическое Время решения по ТЗ Время решения фактическое Результат соблюдения времени реагирования Результат соблюдения времени решения Примечание 1 Услуги по информационно-консультационной поддержке работников Заказчика 2 546782 Консультация по работе Модуля СЦ 1 2 10 часов 11 часов Нет Нет 567123 Консультация по схеме БД 1 1 10 часов 1 час Да Да 2 … … Заказчик Подрядчик /Должность/ /Должность/ ____________________ /Ф.И.О/ ___________________ /Ф.И.О/ М.П. М.П. «_____»_______________________202_г. «_____»_______________________202_г Приложение 1 к Отчету об оказанных услугах Журнал обращений (заявок) на оказание услуги по информационно-консультационной поддержке пользователей Системы (шаблон) Наименование Исполнителя в этапе «наименование этапа» в период с ________________ по _______________ оказал(о) Услугу по поддержке пользователей Системы в объеме, указанном в Таблице 1 Таблица 1 - Журнал обращений (заявок) пользователей Системы № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. ИТОГО зарегистрировано: Всего обращений (заявок): ________ ИТОГО решено: Всего обращений (заявок): ________ Приложение 2 к Отчету об оказанных услугах Журнал обращений (заявок) по решению инцидентов, связанных с работой ППО (шаблон) Наименование Исполнителя в этапе «наименование этапа» в период с ________________ по _______________ оказал(о) Услугу по решению инцидентов в объеме, указанном в Таблице 1. Таблица 1 - Журнал по решению инцидентов № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. ИТОГО зарегистрировано: Всего инцидентов: ________ ИТОГО решено: Всего инцидентов: ________ Приложение 3 к Отчету об оказанных услугах Журнал обращений (заявок) выполнения адаптационного, конфигурационного и коррекционного сопровождения Системы (шаблон) Журнал выполнения адаптации, конфигурации и коррекции Системы сформирован за этап «наименование этапа» в период с «__» _________ по «__» ____________ и представлен в таблице ниже (Таблица 1). Таблица 1 - Журнал выполнения адаптации, конфигурации и коррекции сопровождения Системы № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. Количество выполненных заявок за этап: ________ Приложение 4 к Отчету об оказанных услугах Журнал обращений (заявок) по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности (шаблон) Журнал обращений (заявок) по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности сформирован за этап «наименование этапа» в период с «__» _________ по «__» ____________ и представлен в таблице ниже (Таблица 1). Таблица 1 - Журнал выполнения заявок по устранению уязвимостей в ППО № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. Количество выполненных заявок за этап: ________ - Наименование характеристики - Значение характеристики - Единица измерения характеристики - Инструкция по заполнению характеристик в заявке - ОПРЕДЕЛЕНИЯ, ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ - Автоматизированная система (АС) Система, состоящая из комплекса средств автоматизации, реализующего информационную технологию выполнения установленных функций, и персонала, обеспечивающего его функционирование (ГОСТ Р 59853-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения») АРМ Автоматизированное рабочее место АСУ ТК, Система Информационно-аналитическая система регулирования на транспорте АТС Автоматическая телефонная станция БД База данных ГИС Государственная информационная система ГОСТ Государственный стандарт ГЦОД СИЦ Минтранса России, ГЦОД Головной центр обработки данных ФГБУ «СИЦ Минтранса России» Дашборд Интерактивная аналитическая панель, графический интерфейс. ЕИС Единая информационная система в сфере закупок ЕСИА Единая система идентификации и аутентификации Заказчик Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» КИИ Критическая информационная инфраструктура Кластер Кла?стер (англ. cluster) – объединение нескольких однородных элементов, которое может рассматриваться как самостоятельная единица, обладающая определёнными свойствами Компонент Часть АС, выделенная по определенному признаку или совокупности признаков и рассматриваемая как единое целое (ГОСТ Р 59853-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения») Контракт Контракт на выполнение работ по развитию и оказанию услуг по технической поддержке Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК в 2026 году, заключаемый по результатам проведения конкурентной процедуры закупки в соответствии с требованиями Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» - - Значение характеристики не может изменяться участником закупки - Модуль iМинтранс Модуль сбора данных и представления показателей деятельности Министерства транспорта Российской Федерации iМинтранс АСУ ТК Модуль СЦ Модуль сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК НС Нештатная ситуация НСИ Нормативно-справочная информация ОТИ Объект транспортной инфраструктуры П-ГИС Геоинформационная подсистема П-ИВ Подсистема информационного взаимодействия П-НСИ Подсистема ведения нормативно-справочной информации и метаданных ПО Программное обеспечение Подрядчик, Исполнитель Организация, с которой будет заключен контракт на выполнение работ по развитию Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК П-СД Подсистема сбора данных Работы Работы по развитию Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК СЗИ Средство защиты информации СМЭВ Система межведомственного электронного взаимодействия СУБД Система управления базами данных ТЗ Техническое задание (настоящий документ) ТС Транспортное средство ТК Транспортный комплекс Учреждение Учреждения в области информационной безопасности - ФГБУ «СИЦ Минтранса России» Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации», Заказчик Федеральный закон № 44-ФЗ Федеральный закон от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» ФЗ Функциональная задача ФЗ «Реестр объектов» Функциональная задача «Формирование и ведение единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации» ФСБ России Федеральная служба безопасности Российской Федерации ФСТЭК России Федеральная служба по техническому и экспортному контролю ЧС Чрезвычайная ситуация ЭВМ Электронно-вычислительная машина API От англ. Application Programming Interface – интерфейс прикладного программирования – совокупность инструментов и функций в виде интерфейса для взаимодействия с программой CSS От англ. Cascading Style Sheets — каскадные таблицы стилей FPS От англ. frame per second - количество кадров в секунду HTML От англ. HyperText Markup Language - стандартный язык разметки документов, создающий основу и структуру всех веб-страниц JSON От англ. JavaScript Object Notation – текстовый формат обмена данными, основанный на JavaScript WebAssembly (Wasm) Открытый стандарт, представляющий собой низкоуровневый бинарный формат инструкций, который позволяет выполнять код, написанный на языках C++, Rust или Go, в браузерах с производительностью, близкой к нативной - 1. ОБЩИЕ СВЕДЕНИЯ - 1.1. Наименование Системы Полное наименование системы: Информационно-аналитическая система регулирования на транспорте. Условное обозначение системы: АСУ ТК. Полное наименование модуля: Модуль сбора, ведения и анализа информации о нештатных ситуациях на транспорте. Условное обозначение модуля: Модуль СЦ. Модуль СЦ создан в рамках контракта от 05.08.2024 № ОК/24_04 на выполнение работ по развитию АСУ ТК в части создания модуля «Сбора, ведения и анализа информации о нештатных ситуациях на транспорте». Развитие Модуля СЦ осуществлено в рамках контракта от 19.05.2025 № ОК/25_09 на выполнение работ по развитию Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК - - Значение характеристики не может изменяться участником закупки - 1.2. Шифр темы или номер контракта Присваивается Заказчиком по результатам организации закупочных процедур. 1.2.1. Предмет контракта Выполнение работ по развитию Модуля СЦ. Код по ОКПД2: 62.01.11.000 – услуги по проектированию и разработке информационных технологий для прикладных задач и тестированию программного обеспечения. Оказание услуг по технической поддержке Модуля СЦ. Код по ОКПД2: 62.02.30.000 – услуги по технической поддержке информационных технологий. Выполнение работ по развитию Модуля СЦ предусмотрено с учетом ключевых результатов (ОКР) Ведомственной программы цифровой трансформации Минтранса России на 2026-2028 (далее - ВПЦТ Минтранса России) в составе мероприятия № 103.002 «АСУ ТК» ИТ расхода 103.26.000005 «Развитие Информационно-аналитической системы регулирования на транспорте (АСУ ТК)»: · «Обеспечено информационное взаимодействие с Минобороны о происшествиях на транспортных объектах»; · «Обеспечена автоматизация формирования отчетов о нештатных ситуациях на транспорте, в том числе по данным внешних систем». Выполнение работ по технической поддержке АСУ ТК предусмотрено ВПЦТ Минтранса России в составе мероприятия № 103.002 «АСУ ТК» ИТ расхода 103.26.000021 «Эксплуатация Информационно-аналитической системы регулирования на транспорте (АСУ ТК)» - 1.3. Заказчик Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» (ФГБУ «СИЦ Минтранса России»). Адрес: 107078, Москва, Садовая-Спасская ул., д.18, стр. 1. Оператором Системы является Заказчик - Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» (ФГБУ «СИЦ Минтранса России) - 1.4. Подрядчик Определяется по результатам проведения конкурентной процедуры закупки в соответствии с требованиями Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (далее – Федеральный закон № 44-ФЗ) - 1.5. Основания для выполнения работ Работы осуществляются на основании следующих документов: – постановление Правительства Российской Федерации от 30.12.2003 № 794 «О единой государственной системе предупреждения и ликвидации чрезвычайных ситуаций»; – постановление Правительства Российской Федерации от 08.11.2013 № 1007 «О силах и средствах единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций»; – распоряжение Правительства Российской Федерации от 27.11.2021 № 3363-р «О Транспортной стратегии Российской Федерации до 2030 года с прогнозом на период до 2035 года»; – Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 26.08.2025 №ЕФ-3; – Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 27.11.2025 №ЕФ-23; - – Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 19.02.2026 №ЕФ-1; – План мероприятий по профилактике случаев непроизводственного травматизма граждан на железнодорожном транспорте, являющийся приложением к постановлению коллегии Министерства транспорта Российской Федерации от 11.03.2026 № 2 - 1.6. Перечень документов, требования которых должны быть учтены при выполнении работ – Федеральный закон Российской Федерации от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации»; – Федеральный закон Российской Федерации от 27.07.2006 № 152-ФЗ «О персональных данных»; – Федеральный закон Российской Федерации от 06.04.2011 № 63-ФЗ «Об электронной подписи»; – Федеральный закон Российской Федерации от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации»; – Указ Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации»; – Указ Президента Российской Федерации от 01.05.2022 № 250 «О дополнительных мерах по обеспечению информационной безопасности Российской Федерации»; – Указ Президента Российской Федерации от 31.03.2010 № 403 «О создании комплексной системы обеспечения безопасности населения на транспорте»; – постановление Правительства Российской Федерации от 30.07.2004 № 395 «Об утверждении Положения о Министерстве транспорта Российской Федерации»; – постановление Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации»; – постановление Правительства Российской Федерации от 16.11.2015 № 1236 «Об установлении запрета на допуск программного обеспечения, происходящего из иностранных государств, для целей осуществления закупок для обеспечения государственных и муниципальных нужд»; – постановление Правительства Российской Федерации от 23.12.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 Федерального закона «Об электронной подписи»; - – постановление Правительства Российской Федерации от 08.06.2011 № 451 «Об инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг и исполнения государственных и муниципальных функций в электронной форме»; – постановление Правительства Российской Федерации от 30.01.2013 № 62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин»; – приказ ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации»; – приказ ФСТЭК России от 11.04.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений»; – приказ ФСБ России от 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.7. Сроки начала и окончания работ Начало работ: с даты заключения Контракта. Окончание работ: не позднее 15.12.2026. Работы выполняются в соответствии с этапами. Сроки выполнения этапов работ по развитию и технической поддержке Модуля СЦ определяются Календарным планом. Календарный план, приведен в разделе 5 настоящего ТЗ - 1.8. Общие сведения об источниках и порядке финансирования работ Источником финансирования являются средства субсидии федерального бюджета Российской Федерации, предоставленной в соответствии с абзацем вторым пункта 1 статьи 78.1 Бюджетного кодекса Российской Федерации (код цели 08-01) - 1.9. Порядок оформления и предъявления результатов работ Подрядчик должен передать Заказчику результаты работ в порядке, определенном Контрактом в сроки, установленные п. 5 настоящего ТЗ, в соответствии с Календарным планом - 1.10. Место выполнения Работ Работы выполняются удаленно на комплексе технических средств Заказчика. Адрес размещения комплекса технических средств Заказчика: Московская обл., Богородский район, пос. Горбуша, Радиоцентр. Техническая возможность удаленного подключения обеспечивается Заказчиком (в части предоставления параметров доступа). Оплата телематических и иных услуг, технических и программных средств, необходимых Подрядчику для удаленного подключения и для выполнения требований по информационной безопасности, осуществляется Подрядчиком самостоятельно за свой счет - 2. ЦЕЛИ И НАЗНАЧЕНИЕ ВЫПОЛНЕНИЯ РАБОТ - 2.1. Назначение АСУ ТК АСУ ТК предназначена для автоматизации и информационно-аналитического обеспечения процессов управления развитием транспортного комплекса Российской Федерации, обеспечения публичности деятельности органов государственного управления транспортным комплексом. Основными целями АСУ ТК являются: – повышение эффективности процессов управления функционированием и развитием транспортного комплекса на основе создания единой информационной среды и комплекса информационно-аналитических услуг на уровне органов государственного управления ТК; – повышение уровня безопасности ТК на базе получения полной, достоверной и оперативной информации о происходящих изменениях, своевременного выявления негативных тенденций и для принятия соответствующих мер по их устранению и ликвидации последствий - - Значение характеристики не может изменяться участником закупки - Основными задачами АСУ ТК являются: – автоматизация процессов прогнозирования развития транспортного комплекса и поддержки принятия управленческих решений; – автоматизация процессов мониторинга безопасности и устойчивости транспортного комплекса, управления в чрезвычайных и нештатных ситуациях; – автоматизация процессов управления программами и проектами развития и модернизации транспортного комплекса; – автоматизация процессов мониторинга состояния транспортного комплекса, в том числе с использованием набора ключевых показателей эффективности деятельности транспортного комплекса; – информационно-технологическая поддержка взаимодействия субъектов транспортного комплекса Российской Федерации, органов государственного управления и контроля, международных организаций на основе создания единой технологической среды взаимодействия и управления движением данных (и связанных с ними документов) в транспортном комплексе; – использование в процессах управления транспортным комплексом РФ современных технологий электронного документооборота и электронного обмена данными; – организация межведомственного электронного взаимодействия подразделений Министерства транспорта Российской Федерации, подведомственных агентств и службы с другими организациями - 2.2. Назначение и цели развития и технической поддержки Модуля СЦ Назначение Модуля СЦ: – оперативный мониторинг нештатных и чрезвычайных ситуаций на транспорте ; – оповещение заинтересованных лиц и структур о нештатных и чрезвычайных ситуациях; – сбор, обработка и хранение данных о нештатных и чрезвычайных ситуациях. Целями развития Модуля СЦ являются: – расширение состава данных об оперативной обстановке на транспорте; – оптимизация процесса сбора данных об оперативной обстановке на транспорте; – повышение информированности пользователей за счет визуализация данных Модуля СЦ; – автоматизация процесса формирования отчетов о ЧС и нештатной ситуации на транспорте; – обеспечение информационного взаимодействия с заинтересованными организациями по вопросам ведения. - Целями оказания услуг по технической поддержке являются: – обеспечение информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы; – поддержание параметров функционирования ППО Системы, удовлетворяющих требованиям производственных процессов, включая их непрерывность; – обеспечение бесперебойного функционирования ППО и своевременное устранение сбоев и аварийных ситуаций в Системе; – своевременное устранение уязвимостей при выявлении таковых, в соответствии с требованиями к обеспечению информационной безопасности; – адаптация, конфигурирование, коррекция программного обеспечения в соответствии с изменениями нормативно-правовой базы и запросами уполномоченных сотрудников органов государственной власти, включая выполнение процедур тестирования и участие в обновлениях ППО на стендах Заказчика; – обеспечение сохранения работоспособности ППО в изменяемой среде эксплуатации; – ведение документации по настоящему ТЗ, инициирование и актуализация документации на Систему по результатам обработки запросов Заказчика и внесении соответствующих изменений в ППО. Модуль СЦ применяется в деятельности Министерства транспорта Российской Федерации, подведомственных агентств и службы и другими организациями в соответствии с соглашениями об информационном обмене - 3. ХАРАКТЕРИСТИКА ОБЪЕКТА АВТОМАТИЗАЦИИ - 17 Модуль ГЭТ Модуль предназначен для получения, хранения данных инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по отдельно взятому предприятию-перевозчику. Формирования отчетов об инвентаризации с детальными данными по каждому разделу инвентаризации с маршрутизацией в муниципалитет / регион / Минтранс. Содержит агрегированные данные инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по всем перевозчикам, относящихся к данному муниципалитету. Формирует сводный отчет по муниципалитету по каждому разделу инвентаризации с маршрутизацией в регион / Минтранс. Формирует агрегированные данные инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по всем перевозчикам, относящиеся к данному региону и по всем муниципалитетам, относящимся к данному региону. Аналитические и статистические данные о состоянии ГЭТ региона. Содержит данные о видах транспорта, цифровых транспортных сервисах и платежных инструментах Региона. Формирует сводный отчет по каждому разделу инвентаризации с маршрутизацией в Минтранс. Формирует агрегированную статистику и аналитику по всем регионам страны в разрезе транспортных средств, маршрутов, пассажиропотоков, инфраструктуры ГЭТ. Данные о рейтинге регионов и перевозчиков на основании выбранных параметров, документооборот с участниками Системы: получение подписанных печатных форм, их утверждение, возврат на доработку. 18 Модуль iМинтранс Модуль создан для отчета по ключевым показателям транспортного комплекса России (Отраслевые и статистические показатели, исполнение бюджета, исполнение поручений, аналитика СМИ, происшествия по видам транспорта). 19 Модуль СЦ Модуль СЦ предназначен для оперативного мониторинга нештатных ситуаций транспортной отрасли, оповещения заинтересованных лиц и структур и предоставления данных о нештатных ситуациях - - Значение характеристики не может изменяться участником закупки - АСУ ТК осуществляет идентификацию и авторизацию посредством Единой системы идентификации и аутентификации (ЕСИА). Информационный обмен с внешними информационными системами осуществляется посредством СМЭВ 3 и СМЭВ 4. АСУ ТК развернута на вычислительных мощностях ГЦОД СИЦ Минтранса России - 3.2. Описание и текущее состояние объекта автоматизации Модуля СЦ Объектом автоматизации является процесс организации мониторинга информации о НС и ЧС на транспорте. Предметом деятельности Учреждения являются следующие функции: – информационное обеспечение в области транспортной безопасности, защиты населения и территорий от чрезвычайных ситуаций природного и техногенного характера в транспортном комплексе; – подготовка справочных материалов при угрозе возникновения и возникновении чрезвычайных ситуаций и иных происшествий в транспортном комплексе; – взаимодействие и обмен оперативной информацией с органами управления Единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций; – организация оперативного мониторинга обстановки на объектах транспорта при угрозе и возникновении чрезвычайных ситуаций и иных происшествий. Перечень компонентов Модуля СЦ и выполняемые ими функции представлены в Таблице 2 - Таблица 2. Перечень компонентов Модуля СЦ и их функции № п/п Компонент Выполняемые функции 1 Регистрация событий – ведение карточки события; – удаление комментария; – динамическое отображение существующих событий в заданном радиусе и за заданный период; – возможность автоматической проверки вводимых данных в части количества пострадавших; – отображение карточки ОТИ, ТС в соответствии с ФЗ Реестр объектов; – сохранение и отображение версии карточки события; – привязка события к координатам по картографической основе; – указание признака выполнения действия по отработке события; – перевод статуса события; – закрытие карточки события; – публикация информации о событии в канале мессенджера; – возможность перехода из карточки события на картографическую основу для просмотра местоположения события 2 Визуализация – отображение событий на картографической основе в виде пиктограмм; – масштабирование карты; – отображение краткой карточки события при выборе события на картографической основе; – отображение списка событий; – отображение карточки события; – отображение журнала действий пользователя; – отображение дополнительной информации (текстовая информация и приложенные файлы); – отображение справки о событиях и отчета о событиях; – отображение фильтров и количества отфильтрованных объектов; – отображение результатов поиска; – отображение статистики по событиям на экране; – возможность создания события с картографической основы; – отображения картографических слоев в зависимости от примененных фильтров; – возможность настройки шага картографической сети; – возможность настройки географической точки центра карты; – отображение количества непрочитанных сообщений; – возможность перехода к детальной карточке события из краткой карточки события при выборе события на картографической основе - 3 Информирование – ведение справочника способов оповещения (веб-интерфейс, мессенджер); – формирование сценария выполнения оповещения (настройка условий, способа, параметров оповещения); – выполнение оповещений пользователей 4 Отчетность – формирование отчета и справки о событиях; – фильтрация событий для выгрузки в справку о событиях или в отчет о событиях 5 Администрирование – ведение ролей пользователей; – ведение учетных данных пользователей; – ведение справочника организаций; – ведение справочника групп системы мгновенного обмена сообщениями; – выполнение исходящего звонка на контактный телефонный номер организации; – формирование матрицы эскалации событий Архитектура Модуля СЦ представлена на рисунке 1. Рисунок 1. Архитектура Модуля СЦ - 3.3. Состав используемого ПО Модуля СЦ Программная архитектура Модуля СЦ разработана как трехуровневая клиент-серверная архитектура. Архитектура включает в себя следующие уровни: • уровень представления – презентационный уровень, обеспечивающий взаимодействие с пользователя с клиентскими приложениями с использованием веб-браузера («тонкий» клиент); • уровень приложений – реализован в виде сервисов, обеспечивает обработку запросов, поступающих от клиентских приложений, формирование ответов на запрос в доступном пользователю виде (формирование пользовательских интерфейсов); • уровень хранения данных – реализуется как сервер БД и обеспечивает хранение и целостность хранимых данных, создание резервных копий, ведение журнала транзакций, восстановление данных после сбоев. Программная архитектура Модуля СЦ включает в себя сервисы и интерфейсы, указанные в Таблице 3. Таблица 3. Программная архитектура Модуля СЦ Программный сервис/интерфейс Технологии реализации Уровень представления Интерфейс пользователя и администратора (front-end) Javascript Уровень приложений Сервис (GateWay) Kotlin Сервис геокодирования (geocoding-service) Kotlin Сервис уведомлений (notifiсation-service) Kotlin Сервис работы с файлами (file-service) Kotlin Сервис отчетности (report-service) Kotlin Сервис управления событиями (event-service) Kotlin Сервис информирования через мессенджер (messenger-notifier) Python Сервис внешних интеграций (integration-service) Сбор информации из внешних систем и сервисов Брокер сообщений Kafka Уровень хранения данных Файловое хранилище MinIO S3 СУБД Postgres Pro Enterprise - 3.4. Информационное взаимодействие программных сервисов и интерфейсов Модуля СЦ Объект автоматизации функционирует в распределенной информационной среде. Обмен данными осуществляется по защищенным каналам связи (в том числе ведомственным сетям передачи данных). Источники информации включают: · внешние автоматизированные системы (органов государственной власти); · внутренние базы данных (реестры объектов транспортной инфраструктуры, паспорта регионов и пр.); · оперативная информация от персонала, поступающая через автоматизированные рабочие места (АРМ) и мобильные устройства. 3.4.1. Взаимодействие Модуля СЦ со смежными подсистемами АСУ ТК Модуль СЦ входит в состав АСУ ТК и взаимодействует со следующими ее функциональными задачами и подсистемами: · Функциональной задачей «Формирование и ведение единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации» (ФЗ «Реестр объектов»); · Геоинформационной подсистемой АСУ ТК (П-ГИС); · Подсистемой ведения нормативно-справочной информации и метаданных (П-НСИ); · Подсистемой сбора данных и централизованное хранилище данных (П-СД); · Подсистемой информационного взаимодействия (П-ИВ). 3.4.2. Взаимодействие с внешними информационными системами Список внешних информационных систем, с которыми осуществляется взаимодействие Модуля СЦ: · ЕСИА; · мессенджер; · Яндекс Геокодер; · Информационная система «Централизованная система сбора информации систем-112»; · ПВК «Поиск-Море», АИС РПТ; · облачная АТС - 3.5. Требования к эксплуатации Применяемое в Системе программное обеспечение, программно-аппаратные и аппаратные комплексы должны соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации» - 3.1. Описание объекта автоматизации АСУ ТК Объектом автоматизации являются процессы основной и обеспечивающей деятельности, направленные на управление транспортным комплексом, в том числе, процессы информационного взаимодействия с другими организациями и субъектами транспортного комплекса. АСУ ТК относится к государственным информационным системам, а также к информационным системам персональных данных и значимым объектам критической информационной инфраструктуры Российской Федерации. АСУ ТК соответствует требованиям, предъявляемым к: – ГИС второго класса защищенности в соответствии с приказом ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах»; – ИС персональных данных при обеспечении третьего уровня защищенности персональных данных в соответствии с требованиями постановления Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»; – значимым объектам КИИ Российской Федерации второй категории значимости с постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении Правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений». Модуль СЦ является подсистемой АСУ ТК. Перечень платформенных решений и функциональных задач АСУ ТК представлен в Таблице 1 - Таблица 1 – Перечень платформенных решений и функциональных задач АСУ ТК № Наименование подсистемы/ функциональной задачи/ модуля Назначение 1 Подсистема сбора данных и централизованного хранилища данных Подсистема обеспечивает выполнение сбора данных в АСУ ТК, и в т. ч., в рамках функциональных задач «Формирование и ведение межрегионального транспортного баланса пассажирских перевозок в дальнем (межрегиональном) сообщении» и «Формирование и ведение транспортного паспорта региона» 2 Подсистема информационного взаимодействия Подсистема информационного предназначена для обеспечения информационного взаимодействия подсистем АСУ ТК, а также, взаимодействия АСУ ТК с АС федеральных органов исполнительной власти 3 Подсистема ведения нормативно-справочной информации и метаданных Подсистема предназначена для автоматизации функций формирования и актуализации справочников, классификаторов, реестров и регистров, необходимых для обеспечения информационной поддержки пользователей НСИ и интеграции подсистем АСУ ТК в части применения НСИ 4 Модуль СМЭВ Модуль взаимодействия со СМЭВ представляет собой набор сервисов взаимодействия: сервис синхронного взаимодействия и сервис отправки, осуществляющих дополнительную обработку сообщений, отправляемых в СМЭВ и принимаемых из СМЭВ 5 Геоинформационная подсистема Программное обеспечение геоинформационной подсистемы предназначено для обеспечения смежных подсистем АСУ ТК возможностью работы с картографической информацией, в том числе, отображения на электронных картах объектов транспортной инфраструктуры и получения информации о местоположении, характеристиках контролируемых транспортных объектов 6 Подсистема информационного портала АСУ ТК Подсистема информационного портала предназначена для отображения и входа в функциональные задачи АСУ ТК 7 Подсистема технического портала АСУ ТК Подсистема технического портала АСУ ТК предназначена для управления заявками пользователей и технологического документооборота заявок - 8 Подсистема проектного архива АСУ ТК Подсистема проектного архива АСУ ТК предназначена для автоматизации деловых процессов должностных лиц Министерства транспорта Российской Федерации, подведомственных агентств и службы, в том числе, и процессов информационного взаимодействия внутреннего и внешнего характера 9 ФЗ «Реестр объектов» Функциональная задача предназначена для формирования и ведения единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации 10 ФЗ «СТП» Функциональная задача предназначена для организации информационно-аналитической поддержки процессов территориального планирования Российской Федерации в области федерального транспорта 11 ФЗ «МРТБ ПП» Функциональная задача предназначена для формирования и ведения межрегионального транспортного баланса пассажирских перевозок в дальнем (межрегиональном) сообщении 12 ФЗ «МДД» Функциональная задача предназначена для осуществления мониторинга дорожного движения 13 ФЗ «ТПР» Функциональная задача предназначена для формирования и ведения транспортного паспорта региона 14 ФЗ «Данные по грузообороту» Функциональная задача предназначена для обеспечения подсистем и пользователей АСУ ТК данными по грузообороту между Российской Федерацией и зарубежными странами 15 ФЗ «МЖТ» Функциональная задача предназначена для осуществления мониторинга железнодорожного транспорта 16 ФЗ «МГМП» Функциональная задача предназначена для осуществления мониторинга грузопотоков в морских портах с целью формирования единой цифровой среды мониторинга и планирования перевозок в/из портов Дальнего Востока - 4. ТРЕБОВАНИЯ К МОДУЛЮ СЦ - 4.3.6.4.1. Требования к проведению изменений Основанием для внесения изменений является запрос от Заказчика. Все активности по внесению изменений должны быть согласованы с Заказчиком, а действия Подрядчика при оказании данной услуги должны быть зафиксированы. В рамках данного Технического задания изменениями считаются локальные доработки функционала Модуля СЦ, которые не должны приводить к необходимости выполнения дополнительных аттестационных испытаний или переаттестации АСУ ТК в соответствии с п. 33 приказа от 29.04.2021 № 77 «Об утверждении Порядка организации и проведения работ по аттестации объектов информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну». При необходимости внесения изменений в Модуль СЦ, не связанных с критичным инцидентом, существенно нарушающим работоспособность Модуля СЦ, Заказчик направляет Подрядчику обращение (заявку), в котором излагает суть изменения, которое требуется внести в Модуль СЦ. Исполнитель, в течение 3 (трех) рабочих дней с момента поступления соответствующего обращения (заявки), оценивает техническую возможность реализации запрашиваемого изменения и варианты реализации. По итогу проведения оценки Подрядчик направляет Заказчику заключение о возможности реализации данного изменения с описанием возможных вариантов реализации и согласует с Заказчиком проведение данного изменения - - Значение характеристики не может изменяться участником закупки - При проведении работ по изменению и адаптации Подрядчик должен: – обеспечить выполнение требований безопасной разработки программного обеспечения; – обеспечить предварительное проектирование технических решений и согласование с Заказчиком проекта реализации изменения; – использовать семантическое версионирование (SemVer) в работе, передать Заказчику все артефакты разработки (исходный код и сторонние библиотеки, конфигурации, сборочные и собранные образы и др.); – подготовить полноценное описание функционала, включенного в релиз, с необходимыми схемами и пояснениями к обновлению на стендах Заказчика; – обеспечить тестирование разработанного функционала на стендах Заказчика силами Подрядчика; – решение о переносе измененного ППО на продуктивный стенд принимается Заказчиком по итогу результатов проведенного тестирования; – обеспечить техническое сопровождение процедуры тестирования ППО и переноса измененного ППО на продуктивный стенд Заказчика; – обеспечить экстренное внесение соответствующих изменений в случае выявления некорректной работы продуктивного стенда Заказчика после проведения обновления по итогам разработанного изменения в кратчайшие сроки; – актуализировать при необходимости комплект эксплуатационной документации: o руководство пользователя; o руководство администратора; o иные документы (при необходимости). Результат выполнения изменений должен быть отражен в Отчете по оказанию услуг. Типы и приоритеты изменений могут быть скорректированы в процессе оказания услуг исключительно по согласованию с Заказчиком - 4.3.6.4.2. Требования к изменению настроек функционирования Изменение настроек функционирования может проводиться в рамках допустимых пределов изменения функционирования, заложенных в архитектуру Модуля СЦ. Изменение настроек функционирования включает в себя изменение данных и справочников, изменение форм документов, формируемых Модулем СЦ, изменение и настройку форматов и версий передачи данных в смежные системы. Доработка программного кода Модуля СЦ может допускаться (в случае необходимости) при выполнении работ по адаптации функций Модуля СЦ в части изменения формата передачи данных в смежные информационные системы при условии соблюдения требований пункта 29.3 приказа ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации» - 4.3.6.5. Требования к услугам по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности По запросу Заказчика Подрядчик должен провести работу по приведению ППО в соответствие с требованиями по обеспечению информационной безопасности. Критичность уязвимости оценивается в соответствии в соответствии с Методическим документом ФСТЭК России «Методика оценки уровня критичности уязвимостей программных, программно-аппаратных средств» (утвержден ФСТЭК России 30.06.2025), а также с учетом ГОСТ 56545-2015 и международными стандартами (CVSS 3.0 и выше), и задает необходимый срок устранения. В процессе проведения Заказчиком обследования Модуля СЦ и выявления уязвимостей в ППО, связанных с исходным кодом Модуля СЦ и/или используемыми компонентами (библиотеками), Заказчик направляет Подрядчику обращение (заявку) на устранение, с указанием критичности и срочности принятия мер по устранению в СРО. - Подрядчик при оказании услуг по обновлению или устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности должен: – провести анализ уязвимостей и связанных с ними исходным кодом и/или используемыми компонентами (библиотеками); – выработать варианты устранения указанных уязвимостей и согласовать с Заказчиком их реализацию; – своевременно внести изменения в исходный код Модуля СЦ и/или используемые компоненты (библиотеки) и подготовить соответствующее обновление; – провести обновление Модуля СЦ в тестовом контуре Заказчика и проинформировать Заказчика о готовности проведения тестирования; – протестировать успешность обновления или устранения уязвимостей в ППО и корректность функционирования Модуля СЦ на тестовом контуре, совместно с Заказчиком; – при невозможности незамедлительного устранения уязвимости приоритетов «Критический» и «Высокий» Подрядчик обязан предоставить исчерпывающий список причин и согласовать план достаточных компенсирующих мер с ответственными сотрудниками Заказчика. Результат внесения изменений отображается в соответствующей записи в СРО и в составе Отчета об оказанных услугах - 4.3.6.5.1. Требования к порядку оказания услуг по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности Подрядчик в соответствии с приоритетами обращений и контрольными сроками исполнения (см. Приложение Б к ТЗ) оценивает техническую возможность и сроки устранения уязвимостей, и реализацию обновления Модуля СЦ. По итогу проведения оценки Подрядчик направляет в заявке СРО Заказчику заключение о возможности устранения уязвимостей и/или обновления в ППО и согласует с Заказчиком проведение данных работ - При проведении работ по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности необходимо выполнить следующее: – Заказчику сформировать заявку на устранение (обновление) в СРО с полным списком обнаруженных уязвимостей и планируемыми работами; – согласовать в рабочем порядке время начала и завершения работ, перечень работ, выполняемых в рамках обновления или устранения уязвимостей в ППО с Заказчиком; – оповестить Заказчика о начале проведения работ на тестовом контуре; – провести работы по обновлению или устранению уязвимостей в ППО на тестовом контуре Модуля СЦ в установленные сроки; – протестировать выполнение работ в тестовом контуре и проинформировать Заказчика о готовности переноса ППО на продуктивный контур; – силами Заказчика обновить продуктивный контур Модуля СЦ, в соответствии с планом устранения и выполненными работами; – совместно с Заказчиком проверить корректность функционирования Модуля СЦ и устранения уязвимостей в продуктивном контуре Модуля СЦ по результатам обновления; – при необходимости актуализировать документацию (описание архитектуры, анкеты постановки на мониторинг и иные документы). Любые изменения в части обновления или устранения уязвимостей в ППО на промышленном контуре Модуля СЦ должны применяться только в случае успешного проведения аналогичных работ на тестовом контуре. Детальный порядок оказания услуги по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности определен в Регламенте оказания Услуг - 4.4. Требования к видам обеспечения 4.4.1. Требования к лингвистическому обеспечению Документация на Модуль СЦ должна разрабатываться на русском языке. Взаимодействие пользователей с Модулем СЦ посредством графического интерфейса должно происходить на русском языке за исключением сообщений, зависящих от настроек системного программного обеспечения, установленного на рабочих местах пользователей. При разработке программных решений Модуля СЦ должно быть предусмотрено использование языков программирования высокого уровня, приведенных в Таблице 7. Таблица 7. Языки и средства разработки, специального программного обеспечения Модуля СЦ Категория Наименование Назначение Языки программирования Kotlin Разработка серверной логики и сервисов (backend) JavaScript / TypeScript Разработка клиентской части (frontend) Python Разработка скриптов интеграции, обработки данных и автоматизации Фреймворки и библиотеки Vue.JS Разработка пользовательских интерфейсов (веб-интерфейсы компонентов визуализации и отчетности) React Разработка пользовательских интерфейсов (при необходимости создания сложных интерактивных компонентов) Решения по лингвистическому обеспечению, включая перечень используемых языков программирования, должны быть согласованы с Заказчиком на этапе технического проектирования - 4.4.2. Требования к математическому обеспечению Требования к математическому обеспечению не предъявляются. 4.4.3. Требования к метрологическому обеспечению Требования к метрологическому обеспечению не предъявляются. 4.4.4. Требования к организационному обеспечению Требования к организационному обеспечению не предъявляются. 4.4.5. Требования к методическому обеспечению Задачи методического обеспечения Модуля СЦ должны быть обеспечены за счет использования технологических и методических документов касающихся вопросов функционирования транспортного комплекса и разработки и эксплуатации ПО. 4.4.6. Требования к информационному обеспечению Состав, структура и способы организации информационного обеспечения в Модуле СЦ должны быть определены на этапе технического проектирования. Факты информационного обмена с внешними системами должны фиксироваться в соответствующем журнале - Технические меры по обеспечению надежности должны предусматривать: – резервирование критически важных компонентов и данных Системы и отсутствие единой точки отказа; – использование программного резервирования (программной избыточности); – изменение конфигурации используемых средств и применение специализированного ПО, обеспечивающего высокую надёжность. Организационные меры по обеспечению надежности должны быть направлены на минимизацию ошибок пользователей (а также обслуживающего персонала при эксплуатации и проведении работ по обслуживанию), минимизацию времени ремонта или замены вышедших из строя компонентов за счёт: – обеспечения для обслуживающего персонала требуемого уровня квалификации; – регламентации и нормативного обеспечения выполнения работ обслуживающим персоналом; – своевременной диагностики неисправностей. Расчетное значение коэффициента доступности Модуля СЦ должно составлять не менее 0,95. - 4.5.3. Требования по диагностированию Модуля СЦ Диагностирование Модуля СЦ должно осуществляться путем анализа записей в системных журналах СУБД, операционных систем серверов, а также с помощью встроенных средств диагностирования общего программного обеспечения Модуля СЦ. Диагностированию подлежат: – сбои и нарушения функционирования технического обеспечения (серверов) Модуля СЦ; – сбои и нарушения функционирования системного программного обеспечения серверов, используемых для работы Модуля СЦ; – сбои и нарушения функционирования прикладного программного обеспечения серверов, используемых для работы Модуля СЦ; – случаи недоступности (отсутствия ответа) или некорректные ответы внешних систем; – сбои и нарушения функционирования СУБД; – сбои при выполнении регламентных операций резервного копирования. При возникновении аварийных ситуаций либо ошибок в программном обеспечении диагностические инструменты должны позволять сохранять набор информации, необходимой для идентификации и устранения проблемы. Модуль СЦ и ее компоненты должны обеспечивать возможность диагностики своей работоспособности с возможностью интеграции с модулем мониторинга АСУ ТК. Набор передаваемых журналов и метрик должен быть определен на этапе технического проектирования - 4.5.4. Требования к надежности Должно быть предусмотрено сохранение работоспособности Модуля СЦ при некорректных действиях пользователя и сохранение целостности данных при нештатном завершении работы Модуля СЦ (отказ рабочей станции, потеря сетевого доступа и т.п.). Модуль СЦ должен предоставлять механизмы обеспечения сохранности данных через применение процедур резервного копирования и восстановления, описанных в документации на Систему. Ключевые показатели надежности информационной системы — допустимое время на восстановление работоспособности Модуля СЦ (RTO - recovery time objective) и/или допустимый интервал времени потери изменений в данных при сбоях/отказах (RPO – recovery point objective) должны быть определены Подрядчиком и согласованы с Заказчиком на этапе технического проектирования - 4.1. Требования к структуре Модуля СЦ В процессе работ по развитию Системы должны сохраниться основные требования к построению архитектуры Системы в соответствии с принципами трехуровневой архитектуры: 1. уровень хранения данных или уровень базы данных (сервер СУБД); 2. уровень сервера приложений (сервер аналитической обработки); 3. презентационный уровень, обеспечивающий взаимодействие с клиентскими приложениями. В состав Системы должны входить следующие основные компоненты: 4. сервер баз данных; 5. сервер приложений; 6. веб-сервер. Сервер баз данных должен обеспечивать хранение и целостность хранимых данных, создание резервных копий, ведение журнала транзакций, восстановление данных после сбоев. Сервер приложений должен обеспечивать обработку запросов, поступающих от клиентских приложений (через веб-сервер), формирование ответов на запрос в доступном пользователю виде (формирование пользовательских интерфейсов). Веб-сервер должен обеспечивать взаимодействие с оператором и внешними системами по HTTP / HTTPS протоколу в режиме «запрос-ответ» (получения запросов от пользователя и передачи ответа в виде соответствующей информации, обработанной серверами приложений). Взаимодействие Системы с пользователем должно отвечать требованиям модели «тонкого клиента» (т.е. представлять на стороне клиента (пользователя) лишь графический пользовательский интерфейс). Все составляющие Системы должны использовать единую методологию и отвечать единым принципам взаимодействия, надежности и управления. Перечень компонентов Модуля СЦ представлен в Таблице 4. Таблица 4. Перечень компонентов Модуля СЦ, в отношении которых выполняются работы по развитию № п.п. Наименование компонента Модуля СЦ Раздел ТЗ 1 Компонент регистрации событий 4.2.1. 2 Компонент отчетности 4.2.2 3 Компонент визуализации 4.2.3 4 «Интерактивная карта» (компонент создается) 4.2.4 5 Компонент администрирования 4.2.5 - 4.2. Требования к дорабатываемым функциям модуля СЦ 4.2.1. Развитие компонента регистрации событий (1 очередь) Должны быть выполнены следующие доработки: – обеспечение логирования действий пользователя, связанных с карточкой события; – доработка объектной модели в части создания новых типов сущностей (карточек) с учетом реализуемых интеграций с информационными ресурсами (силы и средства предупреждения и ликвидации ЧС и нештатных ситуаций на транспорте, ТС, ограничения воздушного пространства, неблагоприятные и опасные природные явления); – реализация механизма установления связи между сущностями в Модуле СЦ автоматизированным и ручным способами (события, природные явления, силы и средства предупреждения и ликвидации ЧС и нештатных ситуаций на транспорте, ограничения воздушного пространства, ОТИ, ТС и др.); – отображение в карточке установленных связей между сущностями. - 4.4.7. Требования к программному обеспечению Общесистемное ПО, используемое в составе Модуля СЦ, должно быть зарегистрировано в Едином реестре российских программ для электронных вычислительных машин и баз данных и соответствовать рекомендованным показателям эффективности и соответствующим им значениям индикаторов эффективности перехода подведомственных организаций на использование российского ПО, заданных Приказом Минцифры России от 18.01.2023 № 21 «Об утверждении методических рекомендаций по переходу на использование российского программного обеспечения, в том числе на значимых объектах критической информационной инфраструктуры Российской Федерации, и о реализации мер, направленных на ускоренный переход органов государственной власти и организаций на использование российского программного обеспечения в Российской Федерации». Применяемое в системе программное обеспечение должно соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации, постановления Правительства Российской Федерации от 23 декабря 2024 г. № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц» - Прикладное программное обеспечение должно отвечать следующим требованиям: – совместимость программных продуктов в части используемых технических средств, системного программного обеспечения и общесистемной инфраструктуры в пределах требований к техническому обеспечению, а также их информационная совместимость в пределах требований к информационному обмену; – обеспечение трехуровневой архитектуры с разделением на уровень хранения данных (сервер БД), уровень бизнес-логики (сервер приложений) и уровень представления ( - 4.4.7.1. Требования к инструментам разработки и процессу контроля версий программного обеспечения 4.4.7.1.1. Система контроля версий Для управления исходным кодом должна использоваться система контроля версий кода, развернутая в инфраструктуре Заказчика. 4.4.7.1.2. Правила именования веток Имя ветки должно соответствовать следующему формату: / / Категории веток: ? feature/ — разработка новой функциональности, а также рефакторинг или удаление существующей; ? fix/ — исправление ошибок; ? hotfix/ — срочные исправления, применяемые в обход стандартного процесса разработки; ? test/ — для проведения экспериментов, не влияющих на основную разработку. Идентификатор задачи: после категории указывается ссылка на задачу (issue) в системе контроля версий кода. Описание: добавляется краткое описание решаемой задачи в формате kebab-case (слова разделяются дефисами, например, add-user-auth). Примеры именования веток: ? feature/#123/add-payment-integration; ? fix/#45/correct-calculation-logic; ? hotfix/#67/urgent-database-connection-patch. 4.4.7.1.3. Правила именования коммитов Сообщение коммита должно соответствовать соглашению Conventional Commits и состоять из категории и описания: : ? fix — исправление ошибки. Примеры сообщений коммитов: ? feat: добавление формы регистрации пользователя; ? fix: исправление ошибки валидации email-адреса; ? refactor: оптимизация алгоритма сортировки данных; ? chore: обновление версий в файле dependencies. 4.4.7.1.4. Модель ветвления В процессе разработки используются следующие основные ветви: ? main / master — стабильная ветка, содержит только код, прошедший полное тестирование и развернутый в продуктивных контурах; ? dev — ветка для интеграции завершенных задач, предназначенная для сборки и тестирования в тестовых средах. Попадание кода в main осуществляется только через Merge Request (MR) из dev - 4.5.5. Требования к информационной безопасности Работы по защите информации/информационной безопасности, не включенные в состав настоящего раздела, требуемые в соответствии с требованиями постановления Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации», а также нормативно правовых актов в области защиты персональных данных и обеспечения безопасности объектов критической информационной инфраструктуры, будут проведены в рамках исполнения отдельного контракта, заключенного по результатам отдельной закупочной процедуры (не является частью данного ТЗ), включающего: – определение актуальных угроз безопасности информации и актуализация модели угроз безопасности информации (при необходимости); – выполнение требований о согласовании технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России в установленном порядке; – выполнение требований по устранению Подрядчиком замечаний и недостатков, в случае их выявления при согласовании Заказчиком технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России; – выполнение требований к классу защищенности ГИС, уровню защищенности персональных данных и категории значимости объекта КИИ РФ, установленных для Головного центра обработки данных ФГБУ «СИЦ Минтранса России» (далее – ГЦОД); - – определение перечня объектов защиты информационной системы; – описание (актуализированных) требований к системе защиты информации, а также к мерам защиты информации информационной системы в зависимости от установленных классов защищенности, уровня защищенности персональных данных и категории значимости объектов КИИ РФ (приказы ФСТЭК России № 21, 117, 239); – выполнение требований к мерам по защите ГИС от атак, направленных на отказ в обслуживании, в соответствии с пунктами 30, 34, 59, 63 Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений, утвержденных приказом ФСТЭК России от 11.04.2025 № 117; – описание (актуализированных) требований по защите информации, подлежащих реализации в информационно телекоммуникационной инфраструктуре ГЦОД; – выполнение требований о применении сертифицированных средств защиты информации, включая их классы защиты и уровни доверия; – выполнение требований о запрете использования с 01.01.2025 органами (организациями) средств защиты информации странами происхождения, которых являются иностранные государства в соответствии с пунктом 6 Указа Президента Российской Федерации от 01.05.2022 № 250; – выполнение требований по обеспечению непрерывного взаимодействия с ГосСОПКА в установленном порядке; - 4.2.2. Развитие компонента отчетности (3 очередь) Должна быть обеспечена автоматизация процессов формирования отчетов о ЧС и нештатных ситуациях на транспорте, в т.ч. на основе данных из внешних систем. Включает следующие доработки: – разработка шаблонов отчетов в различных форматах (табличный, текстовый); – реализация выбора фотоматериалов для включения в справку; – форматирование содержимого справок с учетом правил русского языка в отношении окончаний слов (в зависимости от падежа, склонения, числа и рода); – автоматизированное формирование выводов к содержимому справки на основе настраиваемых критериев; – создание интерфейса выбора параметров (фильтрации) для формирования отчетов: o состав полей для включения в отчёт; o настройка диапазонов значений характеристик и дат; o порядок отображения полей; o настройка заголовка. – реализация способа подготовки отчётов в асинхронном режиме (очереди); – реализация интерфейса компонента формирования отчетности для отображения очереди формирования отчетов и статусов их подготовки; – экспорт отчётов в форматы xlsx, csv и справок в форматы pdf, docx. Необходимо разработать не менее 10 шаблонов отчетов и/или справок. Перечень, структура и содержание шаблонов должны быть согласованы с Заказчиком на этапе технического проектирования. - 4.2.3. Развитие компонента визуализации (2 очередь) В рамках развития компонента визуализации должны быть выполнены следующие доработки, обеспечивающие: – вывод перечней (списков) сил и средств предупреждения и ликвидации ЧС и нештатных ситуаций на транспорте с отображением мест их постоянного размещения (дислокации) на карте, включая: o отображение зон ответственности на карте; o возможность их фильтрации (по видам транспорта, регионам и пр.); o реализацию инструмента расчета расстояния (с использованием сети автомобильных и железных дорог) между местом события и местами дислокации сил и средств, а также вывода маршрутов на карте; – отображение зон (полигонов) с установленными ограничениями движения в воздушном пространстве на карте; – отображение термических точек; – реализация возможности отображения данных из паспорта региона, отображаемого в модуле iМинтранс (модуль АСУ ТК); – отображение краткой карточки сущностей и ОТИ (краткой информации и/или динамических характеристик объекта) при выборе объекта на карте с возможностью перехода в полную карточку сущности и ОТИ; – отображение данных от Росгидромета, предусматривающих: o отображение неблагоприятных и опасных природных явлений на карте (с заданным периодом обновления данных); o управление отображением явлений на карте, включая настройку состава отображаемых объектов, поиск, фильтрацию, с использованием соответствующей панели управления; o выведение краткой карточки явления при выборе объекта, с возможностью перехода в полную карточку объекта - – отображение на карте связанных сущностей и ОТИ; – реализация функции выбора темного и светлого стилей отображения элементов интерфейса, карточек сущностей, картографической основы и объектов, отображаемых на карте; – реализация механизма для выбора картографической основы в одном из распространенных форматов WMTS, TMS, MVT и др. Должна быть предусмотрена возможность настройки перечня картографических основ и параметров доступа к ним; – настройка базового набора дашбордов, содержащих преднастроенные виджеты о количестве событий в разрезе видов транспорта с возможностью перехода к исходным данным (карточкам событий, ОТИ и т.д.), с фильтрацией по параметрам. Параметры фильтрации должны быть определены на этапе технического проектирования. Должно быть обеспечено автоматическое и принудительное обновление данных, отображаемых на дашбордах - 4.4.7.1.5. Требования к используемым зависимостям (библиотекам) Все внешние зависимости проекта должны быть зафиксированы с указанием точных версий. Для контроля версий зависимостей в репозиторий обязательно должны быть включены следующие файлы: · Для JavaScript: package-lock.json или yarn.lock; · Для Python: requirements.txt (с зафиксированными версиями) или Pipfile.lock; · Для Go: go.mod и go.sum; Загрузка всех зависимостей должна производиться исключительно через внутренний прокси-репозиторий Заказчика, настроенный в соответствующем системе менеджере пакетов. Запрещается: · Использование плавающих версий (например, ^1.2.3, ~4.5.0, latest); · Использование библиотек, содержащих критические уязвимости, в том числе зарегистрированные в реестре CVE (Common Vulnerabilities and Exposures). 4.4.7.1.6. Требования к процессу непрерывной интеграции (CI) Сборка программного обеспечения, включая этапы компиляции, тестирования и анализа кода, должна выполняться исключительно в инфраструктуре непрерывной интеграции Заказчика. 4.4.7.1.7. Требования к хранению артефактов сборки Все артефакты сборки (результирующие пакеты, Docker-образы и т.д.) подлежат обязательному хранению в предназначенной для этого инфраструктуре Заказчика (артефакторий). Запрещается размещение финальных артефактов сборки на сторонних ресурсах - 4.4.8. Требования к техническому обеспечению Количество серверов, подключаемых и настраиваемых сервисов, их параметров, схемы соединений и настройки межсетевого взаимодействия должны быть согласованы с Заказчиком на этапе № 1 Техническое проектирование. Доступ к комплексу технических средств предоставляется Заказчиком по письменному запросу Подрядчика. Применяемые в Системе программно-аппаратные и аппаратные комплексы должны соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации», требованиям Постановления Правительства Российской Федерации от 23 декабря 2024 г. № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц». Модуль СЦ, работающий в составе АСУ ТК, развернут на вычислительных мощностях ГЦОД СИЦ Минтранса России - 4.5. Общие технические требования 4.5.1. Требования к численности и квалификации персонала и пользователей Модуля СЦ Программное обеспечение Модуля СЦ не должно требовать изменения штатной численности персонала Заказчика. Программное обеспечение Модуля СЦ не должно требовать наличия у пользователей дополнительной квалификации в сфере информационных технологий, кроме базовых знаний в обращении с персональным компьютером, базовых навыков работы в интернет-обозревателях и знаний о Модуле СЦ в объеме документов Руководство пользователя, Руководство администратора - – выполнение требований по обеспечению в автоматизированном режиме с Национальной системой противодействия DDoS-атакам (НСПА) Центра мониторинга и управления сетью связи общего пользования ФГУП «ГРЧЦ» в рамках реализации мер по защите ГИС от атак, направленных на отказ в обслуживании; – детализированные требования к составу и содержанию работ по аттестации, а также к их результатам в соответствии с пунктами 13, 15 и 16 требований приказа ФСТЭК России от 29.04.2021 № 77 «Об утверждении Порядка организации и проведения работ по аттестации объектов информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну» - 4.5.5.1. Требования к безопасности исходного кода Процесс разработки исходного кода должен соответствовать требованиям законодательства, нормативным правовым актам Российской Федерации, приказу ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по безопасности значимых объектов критической информационной инфраструктуры Российской Федерации», а также учитывать отраслевые практики безопасной разработки. Подрядчик должен предоставить Заказчику Руководство по безопасной разработке программного обеспечения (далее – Руководство), применяемое при разработке исходного кода Модуля СЦ. Руководство должно содержать: · описание процесса безопасной разработки и ролевой модели, отражающей зоны ответственности сотрудников Подрядчика; · описание процессов моделирования, оценки и формирования мер предотвращения угроз, применяемых Подрядчиком; · описание методик, применяемых Подрядчиком при разработке исходного кода (правила написания кода); · описание методик, периодичности проведения и инструментария статического, динамического, композитного и фаззинг тестирования исходного кода, включающего критерии отбора релизных версий ПО, применяемые Подрядчиком в процессе разработки; · описание механизмов безопасности в процессе сборки и доставки (безопасность образов, безопасность секретов, безопасность окружения и сборочной среды), применяемые Подрядчиком; · утвержденные шаблоны отчетной документации (в том числе акты), в соответствии с которыми Заказчик принимает результаты проверок (артефакты сборочного процесса), проведенных Подрядчиком; · описание процедур отслеживания и исправления обнаруженных ошибок и уязвимостей программного обеспечения; · описание способов и сроков доведения Подрядчиком до Заказчика информации об уязвимостях программного обеспечения, о компенсирующих мерах по защите информации или ограничениях по применению программного обеспечения, способов получения пользователями программного обеспечения его обновлений, проверки их целостности и подлинности - Подрядчик должен обеспечить реализацию и проведение внутренних проверок мер по разработке безопасного ПО, приведенных в Руководстве. Подрядчик должен провести анализ угроз безопасности информации программного обеспечения в соответствии с ГОСТ 58412-2019 «Защита информации. Разработка безопасного программного обеспечения. Угрозы безопасности информации при разработке программного обеспечения». Подрядчик должен провести испытания по выявлению уязвимостей в программном обеспечении Системы: · проведение статического анализа исходного кода программы; · проведение динамического анализа исходного кода программы; · проведение композитного анализа исходного кода и образов программы; · проведение фаззинг-тестирования программы, направленного на выявление в ней уязвимостей. Испытания по выявлению уязвимостей в программном обеспечении Системы должны быть проведены в рамках: · предварительных испытаний; · опытной эксплуатации; · приемочных испытаний - 4.2.4. Создание компонента «Интерактивная карта» (2 очередь) В составе создаваемого компонента должны отображаться данные, доступные в компоненте визуализации. Требования к интерфейсу интерактивной карты: – интерактивная карта должна быть представлена в виде объемной карты с учетом макетов, представленных в Приложении А к ТЗ; – интерфейс должен корректно отображаться на экранах мониторов (разрешение Full HD 1920?1080), телевизоров (разрешение 4К 3840?2160), жидкокристаллических панелей для видеостены, используемой Заказчиком, с параметрами каждой панели: диагональ 55 дюймов, разрешение 1920x1080; – интерфейс должен корректно отображаться на планшетных устройствах с диагональю экрана 10-12 дюймов, конкретные требования должны быть уточнены на этапе технического проектирования; – должна быть обеспечена кластеризация и генерализация отображения объектов на карте при изменении масштаба; – должно быть обеспечено отображение основных характеристик объектов при выборе их на карте; – должно быть обеспечено управление отображением слоев на карте; – должна быть обеспечена настройка цветовой индикации отображаемых объектов транспортной инфраструктуры; – должно быть обеспечено отображение легенды карты, содержащей отображаемые объекты на карте; – должна быть обеспечена возможность одновременного отображения не менее 5 000 ОТИ и ТС на карте. - На интерактивной карте должны быть отображены подвижные объекты совместно с объектами транспортной инфраструктуры (ОТИ), включая следующие возможности: § отображение местоположения транспортных средств (воздушный, водный и автомобильный транспорт) на карте в режиме реального времени (с заданным периодом обновления данных); § отображение маршрутов движения всех ТС за выбранный период времени, в том числе с использованием эффектов анимации; § отображение маршрутов движения ТС, связанных с карточкой события: ТС, являющихся участниками события, и ТС, находящиеся в заданном радиусе от события; § управление отображением сущностей и ОТИ на карте, включая настройку состава отображаемых объектов, поиск, фильтрацию, с использованием соответствующей панели управления и наглядным представлением результатов; § автоматическое изменение вида отображения объектов (цветовая индикация) по заданным условиям (например, при достижении критических значений параметров, характеризующих функционирование объекта); Должна обеспечиваться производительность обновления изображения на экране в 30 кадров в секунду на тестовой конфигурации пользовательского устройства (модель Бештау AIO2402/B560, входящая в Реестр российской промышленной продукции под номером 10394100 или аналог) при одновременном отображении не менее 5 000 объектов и 200 уникальных моделей объектов. Макеты интерфейсов Модуля СЦ должны быть предварительно согласованы с Заказчиком и разработаны с учетом требований ГОСТ Р ИСО 9241-161-2016 «Элементы графического пользовательского интерфейса» - 4.5.2. Требования к режимам функционирования Модуля СЦ Модуль СЦ должен предусматривать наличие следующих режимов работы: – штатный; – регламентный (профилактический); – аварийный. Основным режимом функционирования является штатный. В штатном режиме все компоненты корректно и полностью выполняют свои функции. Перерывов в работе как Модуля СЦ в целом, так и одного, либо нескольких компонентов не предусмотрено. Режим регламентного (профилактического) обслуживания предназначен для проведения работ по обновлению и техническому обслуживанию компонентов Модуля СЦ, а также резервному копированию данных. При работе в данном режиме допускаются перерывы в работе Модуля СЦ с предварительным информированием пользователей. Состав процедур по регламентному обслуживанию Модуля СЦ и их периодичность определяются Подрядчиком в процессе выполнения работ по созданию Модуля СЦ. В режиме регламентного (профилактического) обслуживания Модуль СЦ может функционировать с частичным ограничением своих функциональных возможностей, либо без ограничения, но со снижением показателей надежности и производительности. Перевод в данный режим работы должен осуществляться сразу после начала выполнения любой операции, отнесенной к этому режиму, с последующим возвратом в штатный режим функционирования сразу после ее завершения. Перевод в указанный режим должен осуществляться при возникновении необходимости проведения работ по обновлению и техническому обслуживанию компонентов Модуля СЦ, а также резервному копированию данных с условием предварительного оповещения пользователей. Аварийный режим функционирования характеризуется отказом одной или нескольких подсистем, вызванных выходом из строя аппаратного и/или программного обеспечения, а также в случае временной неработоспособности каналов связи между серверами. - В аварийном режиме осуществляется поиск неисправностей и проведение работ по их устранению. Перевод в аварийный режим должен осуществляться при возникновении сбоев, аварий и прочих незапланированных воздействий, сразу после наступления одной или нескольких аварийных ситуаций, с последующим возвратом в штатный режим функционирования сразу после окончания восстановительных работ. ПО Модуля СЦ должно обладать надежностью, обеспечивающей работу пользователей в произвольном режиме и оперативное восстановление работоспособности при сбоях. В целях обеспечения надежного функционирования ПО должно предусматривать: – сохранение целостности данных при нештатном завершении работы компонентов Модуля СЦ; – сохранение работоспособности программного обеспечения при некорректных действиях пользователя; – резервное копирование базы данных Модуля СЦ. – время восстановления работоспособности Модуля СЦ после отказа не более 4 часов. – отказоустойчивость на уровне 99% при единовременной количестве не менее 200 пользовательских сессий в Модуле СЦ. Указанные характеристики приведены без учета характеристик надежности инфраструктуры и времени передачи информации по каналам связи. При возникновении сбоев в аппаратном обеспечении, включая аварийное отключение электропитания, Модуль СЦ должен автоматически восстанавливать свою работоспособность (не требовать перенастройки) после устранения сбоев и корректного перезапуска аппаратного обеспечения - По результатам анализа угроз безопасности информации программного обеспечения и испытаний по выявлению уязвимостей в программном обеспечении Системы должна быть предоставлена отчетная документация по формам, утвержденным в Руководстве, и артефакты сборочной среды, подтверждающие проведение испытаний по выявлению уязвимостей в программном обеспечении Систем. Уязвимости подлежат устранению в сроки, обозначенные Заказчиком. В случае обнаружения уязвимого компонента Подрядчик должен заменить/обновить библиотеки. В случае, если уязвимость не подлежит исправлению на программном уровне, Подрядчик должен разработать меры предотвращения угроз безопасности, в том числе правила безопасности для наложенных средств защиты, рекомендации по безопасной настройке конфигурации для устранения потенциальных уязвимостей и снижения рисков информационной безопасности. Уязвимости, найденные ФСБ России, ФСТЭК России, Минцифры России, Роскомнадзором в ходе исполнения Контракта, а также в течение гарантийного периода, должны быть устранены Подрядчиком за свой счет в сроки, согласованные с Заказчиком - 4.5.6. Требования к эргономике и технической эстетике Взаимодействие пользователей с Модулем СЦ должно осуществляться посредством визуального графического интерфейса. Ввод-вывод данных, прием управляющих команд и отображение результатов их исполнения должны выполняться в интерактивном режиме. Интерфейс должен быть рассчитан на преимущественное использование манипулятора типа «мышь», то есть управление Модулем СЦ должно осуществляться с помощью набора экранных меню, кнопок, значков и т. п. элементов. Клавиатурный режим ввода должен использоваться главным образом при заполнении и/или редактировании текстовых и числовых полей экранных форм. Все надписи экранных форм, а также сообщения, выдаваемые пользователю (кроме системных сообщений), должны быть на русском языке. Модуль СЦ должен обеспечивать проверку вводимых пользователем данных и предупреждать о некорректно введённых значениях - Экранные формы должны проектироваться с учетом требований унификации: – все экранные формы пользовательского интерфейса должны быть выполнены в едином графическом дизайне, с одинаковым расположением основных элементов управления и навигации; – для обозначения сходных операций должны использоваться сходные графические элементы, кнопки и другие управляющие (навигационные) элементы. Термины, используемые для обозначения типовых операций, а также последовательности действий пользователя при их выполнении должны быть унифицированы; – внешнее поведение сходных элементов интерфейса (реакция на наведение указателя «мыши», переключение фокуса, нажатие кнопки) должно реализовываться одинаково. Структура размещения информации и представление этой структуры в Модуле СЦ должны соответствовать следующим требованиям: – пункты меню в пользовательском веб-интерфейсе должны быть сгруппированы в соответствии с тематикой информации, функциональными задачами и технологией работы; – каждому пункту меню должна соответствовать только одна выполняемая функция; – при совершении пользователями ошибочных действий должны выдаваться сообщения об ошибках. Эскизы визуального оформления компонента «Интерактивная карта» представлены в Приложении А. - 4.2.4.1. Требования к технической реализации компонента «Интерактивная карта» При реализации компонента «Интерактивная карта» должны учитываться требования, указанные ниже. 4.2.4.1.1. Требования к отображению элементов Повторяющихся элементы карты (ТС, ОТИ, события и пр.) должны отрисовываться с использованием аппаратного создания экземпляров объектов на пользовательском устройстве (WebGL/WebGPU)). Отрисовка каждого объекта отдельным запросом не допускается, должна обеспечиваться возможность одновременного отображения не менее 5 000 объектов без снижения производительности (30 кадров в секунду на тестовой конфигурации). 4.2.4.1.2. Уровни детализации объектов Для управления отображением сложных объектов должно быть создано не менее 3-х уровней детализации, отображаемых при изменении масштаба с возможностью автоматического переключения между уровнями. Все отображаемые объекты должны масштабироваться с учетом разрешения экрана пользователя с сохранением качества детализации. 4.2.4.1.3. Полигональная оптимизация и текстурирование При реализации компонента «Интерактивная карта» должна обеспечиваться технология рельефного тестурирования объектов. Не должны использоваться высокополигональные трехмерные модели. Все повторяющиеся элементы должны генерироваться единоразово и повторно использоваться при последующих отображениях. 4.2.4.1.4. Управление памятью Требуется реализовать потоковую загрузку на устройство пользователя элементов карты и текстур. Загрузка данных целиком при старте приложения не допускается. Необходимо реализовать механизм очистки памяти от элементов, которые находятся вне области видимости камеры в течение заданного времени. 4.2.4.1.5. Требования к взаимодействию пользователя с интерфейсом компонента «Интерактивная карта» Программная реализация механизмов управление камерой (масштабирование и навигация) должна быть выполнена с поддержкой технологии WebAssembly (WASM). Элементы управления должны являться неотъемлемой частью интерактивной карты. - 4.2.5. Развитие компонента администрирования (3 очередь) Должна быть выполнена доработка ролевой модели. Ролевая модель должна обеспечивать управление доступом к отдельным объектам Модуля СЦ и их элементам (атрибутам) с разграничением по видам транспорта, регионам и пр., в частности: – определение набора конкретных действий, доступных пользователям (выполняемых над объектом доступа, например, удаление записи, редактирование записи, формирование отчета и др.); – реализация возможности объединения пользователей в группы; – определение прав доступа для групп пользователей; – реализация интерфейса визуальной настройки прав доступа пользователей к объектам Модуля СЦ - 4.5.7. Требования по сохранности информации при авариях В случае возникновения аварии или сбоя в процессе выполнения пользовательских задач должно быть обеспечено восстановление баз данных до состояния на момент последней завершенной Модулем СЦ транзакции, и структуры файлового хранилища. Все аварийные ситуации должны обрабатываться программно с выдачей соответствующих сообщений, с корректной обработкой ситуации (завершение транзакций, закрытие файлов и т.п.), без потери обрабатываемой информации. В Модуле СЦ должны быть предусмотрены меры, обеспечивающие целостность данных в случае отказа программного обеспечения или аппаратных средств, исключая случаи физического уничтожения носителя или нарушения функциональности носителя, операционной системы или СУБД по вине их производителя либо обслуживающего персонала. Используемые аппаратные и системные платформы должны обеспечивать сохранность и целостность информации в Модуле СЦ при полном или частичном отключении электропитания, аварии сетей телекоммуникации, полном или частичном отказе технических средств Модуля СЦ. Технические решения должны обеспечивать сохранность информации в случае возникновения следующих событий (аварий, отказов и т.п.): – отказ аппаратного обеспечения на сервере; – отключение питания на сервере; – отказ аппаратного обеспечения на рабочей станции; – отключение питания на рабочей станции администратора; – отказ линий связи, в том числе при осуществлении обмена данными - 4.5.8. Требования к защите от влияния внешних воздействий Требования к защите от влияния внешних воздействий не предъявляются - 4.5.9. Требования к патентной чистоте и патентоспособности 4.5.9.1. Исключительные права на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, базы данных, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, принадлежат Российской Федерации в лице Заказчика. Право собственности на результаты работ, отчетные документы и материалы, полученные в ходе выполнения работ по Контракту, принадлежат Российской Федерации в лице Заказчика и считаются переданными с момента подписания Сторонами Акта сдачи-приемки выполненных работ. Разработанное программное обеспечение поставляется вместе с исходными кодами. 4.5.9.2. Все проектные и технические решения должны отвечать требованиям четвертой части Гражданского кодекса Российской Федерации. Результаты Работ должны быть свободными от возможности предъявления любых прав и притязаний третьих лиц, основанных на промышленной, интеллектуальной или другой собственности. 4.5.9.3 Результаты выполненных Работ не должны повлечь необходимость осуществления Заказчиком закупок программного обеспечения (как исключительных, так и неисключительных прав) для обеспечения функциональности Системы в соответствии с Техническим заданием. При выполнении работ Подрядчик должен использовать только объекты интеллектуальной собственности, права на которые приобретены (получены) и используются без нарушений прав на интеллектуальную собственность третьих лиц или предоставлены Заказчиком - 4.2.6. Взаимосвязи с внешними автоматизированными системами (1 очередь) Способы взаимодействия с внешними информационными системами должны быть определены на этапе технического проектирования. Должны быть выполнены следующие доработки: – интеграции с информационными ресурсами в целях получения данных о движении подвижных ТС (воздушные суда, суда водного транспорта); – интеграция с информационным ресурсом в целях получения данных о событиях на железнодорожном транспорте. Реализация интеграций должна включать проектирование и реализацию интеграционных механизмов обмена данными с учетом доступных вариантов реализации, обеспечение защищенных способов взаимодействия, настройку отображения отдельных данных на карте (настройка слоев). Взаимодействия, имеющие каналы связи, выходящие за пределы контролируемой зоны взаимодействующих систем, считаются защищенными, если для их защиты используются программные и/или программно-аппаратные шифровальные (криптографические) средства, сертифицированные ФСБ России (далее – СКЗИ). Выбор СКЗИ, схемы подключения и требуемого класса криптостойкости должен производиться в соответствии с Техническими условиями на подключение к информационным ресурсам ФГБУ «СИЦ Минтранса России» и инструкциями по подключению пользователей к ресурсам инфраструктуры Головного центра обработки данных, утвержденных приказом директора ФБГУ «СИЦ Минтранса России» от 24.05.2024 № 21-ОД - 4.3. Требования к оказанию услуг по технической поддержке Модуля СЦ 4.3.1. Общие требования к оказанию Услуг Техническая поддержка Модуля СЦ должна осуществляться с учетом требований постановления Правительства Российской Федерации от 06.07.2015 N 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации». Подрядчик обязан выполнять требования законодательства в сфере защиты информации, требования по защите информации, информационной безопасности, указанные в локальных нормативных актах ФГБУ «СИЦ Минтранса России», регламентирующих условия информационного взаимодействия, защиты информации и подключения к информационным ресурсам ФГБУ «СИЦ Минтранса России», участвующих в информационном взаимодействии в рамках оказания услуг по технической поддержке АСУ ТК в 2026 году - 4.3.1.1. Требования к составу и содержанию услуг третьего уровня технической поддержки Оказание услуг по технической поддержке Системы осуществляется в рамках этапов в соответствии с календарным планом. Подрядчик в течение 5 рабочих дней с даты заключения Контракта должен предоставить со своей стороны, а Заказчик со своей стороны Матрицу ответственных за взаимодействия в соответствии с Приложением 1 к Регламенту оказания услуг по третьему уровню технической поддержки Модуля СЦ (далее – Регламент, Приложение В). Подрядчик в течение 10 рабочих дней с даты заключения Контракта должен провести мероприятия по организации третьего уровня технической поддержки в соответствии с Регламентом. Услуги по третьему уровню технической поддержки Модуля СЦ должны включать: – организацию Подрядчиком третьего уровня технической поддержки; – информационно-консультационную поддержку работников Заказчика; – решение инцидентов, связанных с работой ППО; – адаптационное, конфигурационное и коррекционное сопровождение Модуля СЦ (в рамках действующих программных модулей и функциональности); – устранение уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности - 4.5.9.4. Подрядчик подтверждает, что обладает всеми правами на передачу Заказчику исключительных прав в соответствии с требованиями настоящего раздела Технического задания. В случае, если к Заказчику по вине Подрядчика будут предъявлены претензии в этой части, иски третьих лиц, связанные с нарушением их прав, Подрядчик принимает на себя такие претензии и иски и возмещает Заказчику все расходы и весь ущерб, понесенный в связи с ними. 4.5.9.5. Подрядчик обязан согласовать с Заказчиком необходимость использования при выполнении работ охраняемых результатов интеллектуальной деятельности, права на которые принадлежат Подрядчику или третьим лицам. 4.5.9.6. В случае, если при выполнении Работ используется готовое программное обеспечение (платформа, подсистема, СУБД и т.д.), которое становится частью (компонентом) Системы, Заказчику передаются полные исключительные права, или неисключительные права (путем заключения лицензионного/сублицензионного договора/соглашения) на такое программное обеспечение со следующими возможностями: – права передаются бессрочно (на весь срок действия исключительных прав); – территория действия Российская Федерация; – должно быть обеспечено право Российской Федерации (в лице Заказчика) передавать, дорабатывать, распространять, развивать результаты работ, созданные в процессе исполнения Контракта, а также перерабатывать такое программное обеспечение. Лицензионное (сублицензионное) соглашение (договор), Акт передачи прав, подписанные Подрядчиком, согласие правообладателя, оформленное в соответствии с положениями Гражданского кодекса Российской Федерации (в случае, если Подрядчик не является правообладателем такого программного обеспечения), инструкция по инсталляции, руководство администратора, руководство пользователя передаются Заказчику в сроки, установленные Техническим заданием для соответствующего функционала Системы - Лицензионное (сублицензионное) соглашение (договор) не может возлагать на Заказчика какие-либо обязанности (в т.ч. в части конфиденциальности, предоставления отчетности), не предусмотренные Контрактом. 4.5.9.7. Передача Заказчику исключительных прав, или простых (неисключительных) прав не может повлечь увеличение стоимости Контракта и/или изменение иных существенных условий Контракта. 4.5.9.8. Функциональность Модуля СЦ передается в объеме и в сроки, установленные Техническим заданием. 4.5.9.9. Нарушение условий настоящего раздела Технического задания, в т.ч. отсутствие соответствующего лицензионного (сублицензионного) соглашения (или договора), либо предоставление лицензионного (сублицензионного) соглашения (или договора), не соответствующего требованиям действующего законодательства Российской Федерации или требованиям Контракта, является нарушением существенных условий Контракта. 4.5.9.10. В случае, если в соответствии с пунктом 4.5.9.6 Заказчику передается исключительное право, такая передача осуществляется в порядке, установленном Гражданским кодексом Российской Федерации. 4.5.9.11. В случае, если при выполнении Работ положения пунктов 4.5.9.5-4.5.9.6 не применялись, Подрядчик в составе отчетной документации предоставляет об этом декларацию в свободной форме. Декларация должна содержать сведения о полном соответствии результата Работ требованиям Контракта, а также о неприменении при выполнении работ готового программного обеспечения (платформ, подсистем, СУБД и т.д.), которое стало частью (компонентом) Системы - 4.3.1.2. Требования к общему порядку оказания услуг Техническая поддержка Модуля СЦ должна быть организована на трех уровнях: – первый и второй уровни технической поддержки организуется Заказчиком; – третий уровень технической поддержки организуется Подрядчиком. Перечень действий на каждом уровне технической поддержки указан в Таблице 5: Таблица 5 – Перечень действий на каждом уровне технической поддержки Уровень технической поддержки Доступные действия Условия передачи задачи на следующий уровень Первый уровень технической поддержки (далее – 1-й уровень) – принимает обращения (заявки) пользователей Модуля СЦ и работников Заказчика; – регистрирует обращения в Модуле СЦ регистрации обращений; – присваивает уникальный идентификационный номер, классифицирует обращения; – самостоятельно решает обращения, которые связаны с недостаточной квалификацией пользователей или настройками в рамках своей компетенции; – взаимодействует с пользователями Модуля СЦ при решении проблемы Передает обращение на второй уровень поддержки в случае невозможности решения на своем уровне Второй уровень технической поддержки (далее – 2-й уровень) – принимает обращения от 1-го уровня; – уточняет классификацию обращения в результате дополнительного анализа; – самостоятельно решает обращения в рамках своей компетенции; – осуществляет техническую и консультационную поддержку Модуля СЦ; – взаимодействует с сотрудниками 1-го и 3-го уровня и пользователями Модуля СЦ; – формирует заявки для 3-го уровня и контролирует исполнение Передает обращение на третий уровень поддержки в случае невозможности решения на своем уровне Третий уровень технической поддержки (далее – 3-й уровень) – принимает обращения от 2-го уровня; – обеспечивает выполнение требований, предъявляемых Контрактом и настоящим Техническим заданием к Услугам, оказываемым Подрядчиком Все поступающие обращения должны быть исполнены Подрядчиком - Для обеспечения взаимодействия с Заказчиком Подрядчик со своей стороны определяет ответственных лиц, уполномоченных в структуре Подрядчика за своевременное и качественное оказание Услуг в рамках настоящего ТЗ, а также контактную информацию ответственных лиц (телефон, электронную почту). Подрядчик должен предоставить Заказчику единый адрес электронной почты для приема обращений (заявок) в течение 3 (трех) рабочих дней после заключения Контракта. Указанный в настоящем пункте адрес электронной почты (способ направления обращений (заявок) применяется в случае сбоя в работе СРО Заказчика. Со своей стороны, Заказчик предоставляет Подрядчику перечень и контактную информацию (телефон, электронную почту) уполномоченных лиц для осуществления взаимодействия с указанием зон ответственности. О любых изменениях в контактной информации ответственных лиц Стороны должны уведомить друг друга в течение 1 (одного) рабочего дня с момента возникновения таких изменений посредством уведомления на электронную почту ответственных лиц и/или в письменной форме. В результате оказания услуг по настоящему ТЗ не должны быть изменены исходные коды, дистрибутивы и иные компоненты Модуля СЦ вне согласованных с Заказчиком изменений. Любые изменения исходных кодов, дистрибутивов и иных компонентов Модуля СЦ должны производиться только после согласования с Заказчиком уполномоченными лицами по электронной почте или иным заранее согласованным способом. Не должна быть ухудшена надежность и производительность Модуля СЦ. Оказание услуг по Контракту не должно нарушать требования к информационной безопасности, описанной в документации на Модуль СЦ - 4.5.9.12. Передача Заказчику комплекта документов, материалов и сведений, предусмотренных нормативными правовыми актами Российской Федерации в сфере информационных технологий, защиты информации, правовой защиты интересов государства в области интеллектуальной собственности, включая документы, подтверждающие отказ авторов (разработчиков) от исключительных прав на передаваемые объекты интеллектуальной собственности в пользу Подрядчика, с проектами заявок на государственную регистрацию в установленном порядке прав Заказчика на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, базы данных, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, осуществляется Подрядчиком в составе отчетной документации, предусмотренной условиями Контракта. 4.5.9.13. По результатам выполнения работ по развитию системы должны быть подготовлены материалы для регистрации доработанной версии Системы (объекта учета) в НФАП в соответствии с требованиями постановления Правительства Российской Федерации от 30 января 2013?г. №?62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин» (с изменениями и дополнениями) в части обязательности размещения результатов работ в национальном фонде алгоритмов и программ для электронных вычислительных машин - 4.5.10. Требования по стандартизации и унификации К Модулю СЦ предъявляются следующие требования в части стандартизации и унификации: – работы по развитию Модуля СЦ должны производиться в соответствии с действующими стандартами и нормами Российской Федерации; – при создании и модернизации элементов Модуля СЦ следует руководствоваться действующими в Российской Федерации национальными стандартами и другими нормативно-техническими документами; – используемые оборудование и материалы, подлежащие обязательной сертификации, должны иметь соответствующие сертификаты; – ПО Модуля СЦ должно проектироваться и разрабатываться с учётом обеспечения требований унификации; – применяемые при создании Модуля СЦ технические (форматы данных, протоколы передачи и прочие) и организационные (регламенты, требования, инструкции) решения должны быть доступны и документированы в виде, достаточном для независимой (без обращения к Подрядчику) реализации третьими сторонами; – термины, обозначения и наименования, используемые в ПО, должны быть стандартизованы и унифицированы, выполнены на русском языке; – взаимодействие элементов и их внешнее поведение должно быть реализовано одинаково и производиться по единым правилам - Оказание услуг в рамках данного технического задания осуществляется Подрядчиком по обращению (заявке) Заказчика, направляемой посредством СРО Заказчика. Регистрация обращений, поступивших непосредственно в Модуль СЦ регистрации обращений Заказчика, производится сотрудниками Заказчика, которые обеспечивают первый уровень технической поддержки Модуля СЦ. В случае назначения приоритета «Критический» или «Высокий», информация о назначении также дублируется оповещением ответственных представителей Подрядчика посредством звонка на предоставленные номера телефонов. Обращение (заявка) должна содержать следующую информацию: – контакты пользователя/организации; – приоритет обращения, соответствующий Приложению 2 к Регламенту; – время обнаружения; – наименование компонента АСУ ТК - Модуль СЦ; Информация может быть расширена по согласованию с Заказчиком. Обращения (заявки) сотрудников Заказчика должны приниматься Подрядчиком через веб-интерфейс СРО. В процессе обработки обращений (заявок) Подрядчик должен обеспечить выполнение следующих процедур: – прием обращений(заявок) от сотрудников Заказчика; – оказание информационно-консультационной поддержки в соответствии с требованиями настоящего Технического задания; – информирование сотрудников Заказчика о статусе обработки и результатах обработки обращений(заявок). Подрядчик осуществляет обязательную регистрацию и учет всех обращений и заявок, поступивших к Подрядчику от представителей Заказчика в рамках оказания настоящих услуг - Примечание: в случае приостановки работы по обращению или заявке (обращение или заявка находится в статусе «Приостановлено»), указываются причины, по которым работы по обращению или заявке приостановлены с указанием перечня действий/информации, запрошенных у инициатора обращения, а также даты, формы и адресата такого запроса. В случае отклонения обращения или заявки (заполняется в случае, если обращению или заявке присваивается статус «Отклонено»), указываются подробно причины такого отклонения, а также фиксируется дата и время перехода в статус «Отклонено». В случае, если обращение или заявка отклонены (отменены) самим Инициатором, то указывается дата и способ, которым от инициатора получено соответствующее уведомление. В случае невыполнения Подрядчиком регламентного времени реагирования или решения обращения (заявки) Заказчик вправе отозвать обращение и направить его Подрядчику повторно. При этом каждое отозванное обращение учитывается в Отчёте об оказанных услугах, как обращение с превышением времени реагирования или решения, но оплате не подлежит. В случае, если обращение (заявка) связано с некачественным выполнением Подрядчиком другой задачи, такое обращение решается в регламентное время, установленное Техническим заданием, при этом оплате такие обращения не подлежат, о чем указывается в Отчете об оказанных услугах в графе «Примечание» - 4.5.11. Требования к показателям назначения 4.5.11.1. Требования к показателям назначения мероприятий по развитию Модуля СЦ В рамках выполнения работ по развитию Модуля СЦ, предусмотренных ТЗ, показатель назначения «Количество пользователей» должен соответствовать значениям, приведенным в данном разделе. Пояснения по показателям, связанным с количеством пользователей, приведены в Таблице 8. Таблица 8. Определения показателей, связанных с количеством пользователей в Модуле СЦ № Показатель Определение Расчетное количество пользователей Количество пользователей, работу которых должен обеспечить Модуль СЦ к моменту сдачи работ по Контракту с учетом достижения всех показателей назначения Расчетное количество одновременно работающих пользователей Количество одновременно работающих пользователей, работу которых должен обеспечивать Модуль СЦ к моменту сдачи работ по Контракту с учетом достижения всех показателей назначения Значения показателей количества пользователей, достижение которых необходимо обеспечить, представлено в Таблице 9 - Таблица 9. Значения показателей количества пользователей № Показатель Значение 1. Расчетное количество пользователей 1 000 2. Расчетное среднее количество одновременно работающих пользователей 200 Развитие Модуля СЦ должно быть направлено на достижение следующего эффекта (показателя), подставленного в мероприятии 103.002 «Информационно-аналитическая система регулирования на транспорте (АСУ ТК)» ВПЦТ Минтранса России: Выполнение работ по развитию Модуля СЦ предусмотрено мероприятием по развитию АСУ ТК, приведенном в ВПЦТ Минтранса России на 2026-2028 гг: № 103.002 «АСУ ТК» в составе ИТ расхода 103.26.000005 «Развитие предусматривает реализацию ОКР и эффектов, приведенных в Таблице 10. Таблица 10. ОКР и эффекты, приведенные в ВПЦТ Минтранса России на 2026 г. № ОКР Дата ОКР Эффекты 1 Обеспечено информационное взаимодействие с Минобороны России о происшествиях на транспортных объектах 25.12.2026 Сокращено время сбора и передачи сведений для Минобороны России о ЧС и НС на транспорте с 120 до 10 минут 2 Обеспечена автоматизация формирования отчетов о нештатных ситуациях на транспорте, в том числе по данным внешних систем 25.12.2026 Сокращено время на подготовку отчетов о нештатных ситуациях на транспорте с 20 до 5 минут Реализация остальных ОКР не является предметом данного ТЗ и проводится в рамках отдельного технического задания. - 4.5.11.2. Требования к показателям назначения мероприятий по эксплуатации Модуля СЦ. Работы по эксплуатации Модуля СЦ не должны обеспечивать режимы функционирования Модуля СЦ, приведенные в разделе 4.5.2 данного ТЗ - 4.3.1.3. Требования к регламенту оказания услуг Подрядчик должен руководствоваться Регламентом оказания услуг по технической поддержке Модуля СЦ. Регламент оказания услуг содержит следующую информацию: – порядок оказания услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Модуля СЦ; – порядок оказания услуги по решению инцидентов, связанных с работой ППО; – порядок оказания услуги адаптационного, конфигурационного и коррекционного сопровождения Модуля СЦ (в рамках действующих программных модулей и функциональностей); – порядок оказания услуги по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности. – Регламент содержит следующие формы заявок на оказание услуг: – форма заявки на оказание услуги по информационно-консультационной поддержке сотрудников Заказчика; – форма заявки на оказание услуги по решению инцидентов, связанных с работой ППО; – форма заявки на оказание услуг адаптационного, конфигурационного и коррекционного сопровождения Модуля СЦ (в рамках действующих программных модулей и функциональностей) (приоритет заявки определяется Заказчиком); – форма заявки на оказание услуги по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности - 4.3.2. Требования к режиму обеспечения функционирования Модуля СЦ Режим оказания услуг определен в Приложении Б к настоящему ТЗ. По согласованию с Заказчиком, в целях недопущения остановки функционирования Модуля СЦ в период интенсивной работы пользователей в Модуле СЦ, отдельные услуги могут оказываться по специальному графику (в нерабочее время Подрядчика) в соответствии с заявками Заказчика - 4.3.3. Требования к качеству оказываемых услуг Качество оказываемых услуг поддерживается Подрядчиком в соответствии с определяемыми данным ТЗ условиями и правилами и контролируется Заказчиком на постоянной основе, в том числе по соблюдению сроков исполнения и подтверждениям исполнения от инициаторов обращений и другим параметрам. По результатам выполнения работ по устранению инцидента должна быть устранена корневая причина инцидента с окончательным решением, устраняющим причину возникновения проблемы и исключающим вероятность повторного возникновения проблемы (инцидента). Время устранения корневых причин проблемы (инцидента) не должно составлять более 40 рабочих часов - 4.3.4. Требования к документированию результатов оказываемых услуг Для обеспечения контроля оказываемых услуг по поддержке Модуля СЦ со стороны Заказчика, по окончании каждого отчетного периода по контракту в соответствии с календарным планом, Подрядчик обязан предоставить Заказчику Отчет об оказанных услугах. Отчет должен содержать детальную информацию об оказанных услугах с указанием даты выполненных мероприятий и приложением обосновывающих документов (заявок, запросов, требований) или ссылкой на такие документы, если они содержатся в Модуле СЦ. Информация о выполненных мероприятиях по заявкам должна быть сформирована на основании соответствующих записей СРО по каждому этапу исполнения Контракта. В случае оказания услуги адаптационного, конфигурационного и коррекционного сопровождения Модуля СЦ, должны быть предоставлены документы, подтверждающие выполнение требований п. 29.3 приказа ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации». Фактическое время реагирования и время решения по всем обращениям, поступившим в СРО, формируется в СРО по итогам отчетного периода в разделе «Отчеты». Фактическое время реагирования и время решения по обращениям учитывает суммарное время, затраченное на реагирование и, соответственно, на работу по обращению с момента назначения обращения специалисту Подрядчика или группе исполнителей, ответственным за оказание услуг технической поддержки 3 уровня от начала до завершения работ Подрядчиком. При этом принимается суммарное время нахождения заявки в соответствующих статусах заявки СРО на стороне Подрядчика - 4.3.5. Требования к классификации обращений и заявок Обращения и заявки Заказчика классифицируются в соответствии с приоритетами и регламентными сроками, указанными в Приложении 2 к Регламенту. Регистрация обращений и заявок предусматривает создание новой записи в СРО с присвоением поступившему обращению или заявке (новой записи) уникального идентификатора. Запись в СРО должна содержать вопрос или проблему, которую требуется решить или оказать консультацию. Состав обязательной информации, которую должно содержать обращение или заявка, зафиксирован в Регламенте оказания Услуг. Если обращение или заявка автоматически зарегистрированы в СРО при отправке представителем Заказчика, Подрядчик проверяет корректность классификации обращения или заявки и может обратиться к Заказчику с просьбой корректировки, предоставив обоснования в соответствии с настоящей классификацией (Таблица 6) - Таблица 6. Категории обращений и заявок Категория Примеры Запрос на обслуживание Подготовка SQL запроса к СУБД для решения прикладной задачи и д.р. – запрос на любое действие, не являющееся запросом информации и несовершенный на основе происшествия, прямо или косвенно влияющего на работу Модуля СЦ Консультация «Где взять / куда обратиться...?», «Как сделать / выполнить…», «Как это работает…?» - запрос, имеющий своей целью получение информационной поддержки Инцидент Разбор ошибок/сбоев и подготовка материалов (корректировочных релизов, инструкций) для Заказчика для устранения ошибок/сбоев, которые приводят к частичному и полному нарушению работоспособности всех или отдельных функций ППО. Подготовка изменения и материалов, необходимых для проведения аварийно-восстановительных работ для возобновления работоспособности Модуля СЦ ЗНИ Подготовка изменений, связанных с изменением, улучшением/оптимизацией Модуля СЦ и выводом новой модифицированной функциональности в штатном режиме. Подготовка изменений, связанных с модификацией существующих и/или реализация новых интеграционных механизмов для получения/обработки данных внешних систем. Подготовка изменений графического интерфейса по требованиям Заказчика. Перечень статусов обращений (заявок) приведен в пункте 3.3. Регламента оказания Услуг. Назначение обращению (заявке) статуса «Закрыто» осуществляется Заказчиком только после получения от инициатора обращения (заявки) подтверждения о его исполнении или нахождения обращения (заявки) в статусе «Выполнено» и отсутствия повторных вопросов/запросов по данному обращению (заявки) в течение 5 рабочих дней. Категории и статусы обращений (заявок) могут быть скорректированы в процессе оказания услуг исключительно по согласованию с Заказчиком - 4.3.6. Требования к услугам технической поддержки 4.3.6.1. Требования к организации третьего уровня технической поддержки Основными задачами организации третьего уровня технической поддержки в рамках оказания услуг по технической поддержке Модуля СЦ являются организация эксплуатационной службы Подрядчика, проверка готовности технических и программных средств для обеспечения непрерывного функционирования ППО Модуля СЦ. Подрядчиком должны быть проведены организационно-штатные и подготовительные мероприятия (в т. ч. технические) в рамках организации технической поддержки Модуля СЦ. Подрядчик в течение 5 (пяти) рабочих дней с даты заключения Контракта должен: – определить и направить Заказчику документ «Перечень уполномоченных специалистов», содержащий контактную информацию (ФИО, должность, адрес рабочей электронной почты) лиц, ответственных за оказание услуг со стороны Подрядчика; – обеспечить подключение специалистов Подрядчика к Системе регистрации обращений (заявок) (СРО предоставляется Заказчиком) для оказания услуг; – согласовать с Заказчиком способ доступа Подрядчика к Модулю СЦ. Результат выполнения мероприятий фиксируется в Протоколе проверки результатов организационно-штатных и подготовительных мероприятий (см. Приложение Д к настоящему ТЗ) - 4.3.6.2. Требования к услугам информационно-консультационной поддержки работников Заказчика и пользователей Модуля СЦ Услуги информационно-консультационной поддержки сотрудников Заказчика включают: – обработку обращений и заявок, поступивших от сотрудников Заказчика; – консультирование сотрудников Заказчика и пользователей Модуля СЦ; – актуализацию документации, и других материалов по работе с Модулем СЦ при необходимости. – консультирование и разработку рекомендаций по настройке Модуля СЦ (без изменения программного кода), включая изменение настроек функционирования; – консультации по вопросам использования, настройки и возможностям Модуля СЦ; – консультации по проведению превентивных мер для недопущения аварийных ситуаций в Модуле СЦ; – консультации по предварительной диагностике и локализации возникшей неисправности Модуля СЦ; – консультации по вопросам обеспечения информационной безопасности Модуля СЦ и настройки функций, обеспечивающих корректную работу программного обеспечения для совершения юридически значимых действий в Модуле СЦ; – другие вопросы, связанные с работой Модуля СЦ. 4.3.6.2.1. Требования к порядку оказания услуг информационно-консультационной поддержки работников Заказчика и пользователей Модуля СЦ Подрядчик выполняет консультирование сотрудников Заказчика и пользователей Модуля СЦ. Консультация может быть предоставлена по согласованным с представителем Заказчика каналам коммуникации с регистрацией результата консультации в СРО Подрядчиком. Детальный порядок оказания консультационных услуг определен в Регламенте оказания Услуг - 4.3.6.3. Требования к услугам по решению инцидентов, связанных с работой ППО Подрядчик устраняет неисправности Модуля СЦ, связанные с работой ППО, выявленные в рамках оказания услуг согласно настоящему Техническому заданию, при этом в зону ответственности Подрядчика не входит устранение неисправностей, выявленных на стороне Заказчика и на стороне третьих лиц (провайдера связи, поставщика электропитания и т.д.). Первичная диагностика выявленной неисправности проводится на 1 и 2 уровнях технической поддержки и не входит в зону ответственности Подрядчика. Если при проведении первичной диагностики и попытке устранить неисправности на 1 и 2 уровнях технической поддержки, данную неисправность устранить не удалось и в процессе диагностики было выявлено, что проблема связана с работоспособностью ППО, обращение (заявка) назначается сотруднику Подрядчика, ответственному за оказание услуг технической поддержки 3 уровня. Инцидентами вне зоны ответственности Подрядчика являются: – работоспособность функциональности, выходящая за рамки текущей реализации функций в Модуле СЦ и/или являющаяся расширением требований Заказчика к функциям Модуля СЦ; – проведение профилактических и плановых работ, согласованных с Заказчиком; – нарушение работоспособности функций Модуля СЦ, вызванное проведением работ на стороне Заказчика - Работы по устранению неисправности приостанавливаются (по согласованию с Заказчиком) в следующих случаях: – если Подрядчиком в результате диагностики выявлено, что неисправность находится в зоне ответственности Заказчика. Подрядчик информирует Заказчика о выявленной неисправности в зоне его ответственности по согласованным каналам связи; – требуется действие со стороны Заказчика – до момента выполнения данного действия Заказчика. Заказчик информируется о необходимых действиях по согласованным каналам связи; – отсутствие возможности связаться со специалистами Заказчика, участие которых необходимо для устранения неисправности; – требуется доставить оборудование на объект – до момента доставки и установки оборудования. В случаях, представленных выше, время приостановки работ не входит в учет продолжительности устранения неисправности. Учет времени устранения неисправности Подрядчиком считается с момента назначения Инцидента специалисту Подрядчика, ответственному за оказание услуг технической поддержки 3 уровня. Подтверждение необходимости приостановления работ находится в зоне ответственности Подрядчика. Приостановление сроков выполнения задач в соответствии с настоящим пунктом подтверждается Заказчиком по мотивированному обращению Подрядчика в СРО, основанному на данных диагностики или на иных фактических обстоятельствах - В случае непринятия Подрядчиком необходимых мер по информированию Заказчика (отсутствие надлежащего обращения от Подрядчика или отсутствие уведомления о необходимости осуществления каких-либо действий Заказчиком) не может являться основанием для приостановления работ по устранению неисправности. В отдельных случаях Подрядчику может потребоваться выполнение технологических работ для устранения причин неисправности или недопущения повторения их в будущем. Для обеспечения устранения неисправности Модуля СЦ Заказчиком проводится классификация в соответствии с приоритетами по степени срочности их устранения. Продолжительность устранения неисправности, а также периодичность информирования Подрядчиком Заказчика о ходе устранения неисправности, определены в Регламенте оказания услуг. При подаче обращения (заявки) наивысшего приоритета через СРО Заказчик должен дополнительно проинформировать службу поддержки Подрядчика о созданном обращении (заявки) по телефону уполномоченного сотрудника Подрядчика. При этом временем подачи обращения (заявки) считается время подачи обращения (заявки) через СРО - 4.3.6.3.1. Требования к порядку оказания услуги по решению инцидентов, связанных с работой ППО При поступлении от Заказчика обращения (заявки), являющегося неисправностью в работе Модуля СЦ (инцидентом), Исполнитель реагирует на инцидент в СРО в срок не более 30 минут с момента поступления. В случае необходимости, для решения инцидента ответственный специалист должен связаться с инициатором обращения (заявки) для уточнения условий воспроизведения проблемы или для получения дополнительных сведений. После получения необходимых сведений от инициатора обращения (заявки) ответственный специалист производит диагностику с целью выявления причины инцидента и возможных путей устранения. В случае, если инцидент невозможно решить без получения дополнительных сведений от инициатора, и не удается связаться с инициатором в течение пяти рабочих дней, обращение (заявка) отклоняется в связи с недостатком данных для его решения, Заказчику направляется уведомление об отклонении обращения (заявки). Время, в течение которого невозможно связаться с инициатором, вычитается из общего времени обработки обращения (заявки). Все попытки связаться с инициатором должны фиксироваться с указанием даты и времени попытки, используемого способа связи (номер телефона, адрес электронной почты) и результата попытки (не удалось дозвониться, абонент недоступен, и т.д.) - Факт и время решения инцидента должны быть зафиксированы и отражены в СРО. В случае, если причиной сбоя в работе Модуля СЦ является выход из строя аппаратного обеспечения или неработоспособность смежной информационной системы, время работы над инцидентом приостанавливается до момента устранения неисправности. В ходе решения инцидентов могут быть выявлены дефекты ППО Модуля СЦ. В случае обнаружения дефектов ППО, Подрядчик информирует об этом Заказчика. Исполнитель может быть привлечен к проверке результата устранения дефекта по инициативе Заказчика. Приоритеты инцидентов приведены в Приложении Б к ТЗ. Детальный порядок оказания услуги по решению инцидентов, связанных с работой ППО Модуля СЦ определен в Регламенте оказания Услуг - 4.3.6.4. Требования к услугам адаптационного, конфигурационного и коррекционного сопровождения и доработки Модуля СЦ (в рамках действующих программных модулей и функциональностей) Услуги адаптационного, конфигурационного и коррекционного сопровождения и доработки Модуля СЦ включают: – управление изменениями и адаптация функций Модуля СЦ; – изменение настроек функционирования Модуля СЦ; – внесение изменений и/или модификаций Модуля СЦ (в рамках действующих программных модулей и функциональностей), направленных на улучшение их работоспособности и функциональных возможностей; – подготовка и передача Заказчику SQL запросов в СУБД для получения агрегированной информации из Модуля СЦ, которую невозможно получить с использованием графического пользовательского интерфейса; – адаптация модулей интеграций со смежными информационными системами - 5. СОСТАВ И СОДЕРЖАНИЕ РАБОТ ПО РАЗВИТИЮ И ТЕХНИЧЕСКОЙ ПОДДЕРЖКЕ МОДУЛЯ СЦ (КАЛЕНДАРНЫЙ ПЛАН) - Сдача-приемка результатов выполненных работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная техническая документация, а также результаты работ предоставляются Заказчику в порядке, предусмотренном Контрактом и ТЗ, до размещения Подрядчиком в ЕИС документа о приемке. Документ о приемке размещается в ЕИС по каждому этапу в соответствии с условиями Контракта. Этапы выполнения работ по развитию Модуля СЦ приведены в Таблице 11. Таблица 11. Этапы выполнения работ по развитию Модуля СЦ. № этапа Наименование этапа Результат (отчетная документация) Срок исполнения этапа - - Значение характеристики не может изменяться участником закупки - 1 Техническое проектирование Сопроводительным письмом предоставляются Заказчику: · Технический проект, включая следующие документы: – Ведомость технического проекта; – Ведомость машинных носителей информации – Пояснительная записка; – Описание информационного обеспечения системы; – Описание автоматизируемых функций; – Схема функциональной структуры; – Описание организации информационной базы; – Описание программного обеспечения; · Макеты экранных форм компонента «Интерактивная карта»; · Руководство по безопасной разработке программного обеспечения; · Документ о приемке Начало: с даты заключения контракта Окончание: не позднее 31.07.2026 - 2 Услуги по технической поддержке Модуля СЦ (с даты заключения контракта по 10.09.2026) По окончании оказания Услуг сопроводительным письмом предоставляются Заказчику: – Отчет об оказанных Услугах по технической поддержке; – Актуальные на дату окончания оказания Услуг по данному этапу исходные коды прикладного ПО на электронном носителе (в случае внесения изменений); – Инструкция по сборке и развертыванию (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство пользователя (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство администратора (в случае внесения изменений); – Документ о приемке Начало: с даты заключения контракта Окончание: не позднее 10.09.2026 - 3 Разработка программного обеспечения (1 очередь, пп. 4.2.1, 4.2.6 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ; – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 1 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 1 очереди; – Руководство по резервному копированию; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 16.09.2026 - 4 Разработка программного обеспечения (2 очередь, пп. 4.2.3, 4.2.4 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ. – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 2 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 2 очереди; – Руководство по резервному копированию; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 25.09.2026 - 5 Разработка программного обеспечения (3 очередь, пп. 4.2.2, 4.2.5 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ; – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 3 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 3 очереди; – Руководство по резервному копированию; – Описание ролевой модели; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 09.10.2026 - 6 Опытная эксплуатация (1 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акт о завершении опытной эксплуатации 1 очереди; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке 17.09.2026 Окончание: не позднее 26.10.2026 - 7 Опытная эксплуатация (2 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акт о завершении опытной эксплуатации 2 очереди; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке 26.09.2026 Окончание: не позднее 26.10.2026 - 8 Опытная эксплуатация (3 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Акт о завершении опытной эксплуатации 3 очереди; – Документ о приемке Начало: с 10.10.2026 Окончание: не позднее 26.10.2026 - 9 Приемочные испытания Сопроводительным письмом предоставляются Заказчику: – Программа и методика приёмочных испытаний; – Протокол приемочных испытаний; – Исходные коды и дистрибутивы на электронном носителе (при условии внесения изменений, с учетом доработок по результатам опытной эксплуатации и проведенных испытаний); – Комплект рабочей документации на Модуль СЦ (при условии внесения изменений, с учетом доработок по результатам опытной эксплуатации и проведенных испытаний); – Акт приемки Системы в эксплуатацию; – Акт приемки-передачи исключительных прав на объект; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке; – Документы в соответствии с разделом 4.5.9 ТЗ; – Обеспечение гарантийных обязательств Начало: с 27.10.2026 Окончание: не позднее 10.11.2026 - 10 Услуги по технической поддержке Модуля СЦ (с 11.09.2026 по 15.12.2026) По окончании оказания Услуг сопроводительным письмом предоставляются Заказчику: – Отчет об оказанных Услугах по технической поддержке; – Актуальные на дату окончания оказания Услуг по данному этапу исходные коды прикладного ПО на электронном носителе (в случае внесения изменений); – Инструкция по сборке и развертыванию (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство пользователя (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство администратора (в случае внесения изменений); – Документ о приемке Начало: с 11.09.2026 Окончание: не позднее 15.12.2026 - Работы по развитию Системы (за исключением этапов проведения опытной эксплуатации и услуг по технической поддержке) могут быть выполнены досрочно. При досрочном выполнении работ (этапов работ) Подрядчик в письменной форме уведомляет Заказчика о готовности представить для приемки результаты проведения работ в соответствии с требованиями Контракта. Подрядчик также вправе досрочно приступать к работам в рамках очередного этапа при наличии технической, организационной готовности - при условии получения соответствующего согласования Заказчиком. Сдача-приемка результатов выполненных работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная, техническая документация, а также результаты Работ по каждому этапу предоставляется Заказчику в порядке, предусмотренном Контрактом и настоящим Техническим заданием, до размещения Подрядчиком в Единой информационной системе в сфере закупок документа о приемке. Документ о приемке размещается в ЕИС по каждому этапу в соответствии с условиями Контракта. Согласование документов осуществляется в электронном виде посредством переписки с адресов электронной почты Заказчика и Подрядчика, указанных в контракте. - 6. ПОРЯДОК РАЗРАБОТКИ МОДУЛЯ СЦ - Проектирование Модуля СЦ должно включать разработку следующих документов: – Ведомость технического проекта; – Ведомость машинных носителей информации – Пояснительная записка; – Описание информационного обеспечения системы; – Описание автоматизируемых функций; – Схема функциональной структуры; – Описание организации информационной базы; – Руководство по безопасной разработке программного обеспечения; – Описание программного обеспечения; – Макеты экранных форм компонента «Интерактивная карта». Структура документов должна соответствовать ГОСТ Р 59795-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов». Разработка Модуля СЦ должна включать в себя: – разработку программного обеспечения в части новых функций Модуля СЦ; – сборка исходного кода, развертывание и настройку доработанного программного обеспечения Модуля СЦ на вычислительных мощностях Заказчика (тестовый контур); – Комплект рабочей документации на Модуль СЦ; – разработку документа «Программа и методика предварительных испытаний»; – разработку документа «Программа и методика приемочных испытаний»; – разработку документа «Программа опытной эксплуатации». Структура документов должна соответствовать ГОСТ Р 59795-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов». В ходе выполнения работ формируется правоустанавливающая, отчетная, рабочая и техническая документация в соответствии с Контрактом и Календарным планом, приведенном в разделе 5. - - Значение характеристики не может изменяться участником закупки - 6.1. Сведения о гарантийном обслуживании Модуля СЦ Под гарантией понимается устранение Подрядчиком своими силами и за свой счет допущенных по его вине недостатков, выявленных после приемки выполненных Работ, как в работе самой Модуля СЦ, так и недостатков в отчетной документации. Если в период гарантийного срока обнаружатся недостатки, то Подрядчик обязан устранить их за свой счет, в сроки, установленные Заказчиком. Гарантийный срок в этом случае продлевается на период устранения недостатков. Срок гарантии: 1 год с даты приемки Заказчиком результатов исполнения Этапа № 9 контракта. Подрядчиком должны быть внесены соответствующие исправления в техническую и рабочую документацию (указанную в пунктах 5 и 6 настоящего ТЗ), связанные с устранением замечаний к работе Модуля СЦ или в случае выявления Заказчиком недостатков в такой документации в период гарантийного срока. Внесение изменений в документацию технического и рабочего проектирования осуществляется в соответствии с ГОСТ 2.503-2023 и ГОСТ Р 2.504-2021. - 7. ПОРЯДОК КОНТРОЛЯ И ПРИЕМКИ РЕЗУЛЬТАТОВ ВЫПОЛНЕНИЯ РАБОТ ПО РАЗВИТИЮ МОДУЛЯ СЦ - Испытания должны быть организованы и проведены в соответствии с ГОСТ Р 59792-2021 «Информационная технология. Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем». Должны быть проведены следующие виды испытаний: – предварительные испытания; – опытная эксплуатация; – приемочные испытания. Указанные виды испытаний проводятся в отношении не функциональных требований и функциональных возможностей, разрабатываемых в соответствии с настоящим ТЗ. Отдельные виды испытаний проводятся поэтапно в сроки, установленные Календарным планом. Предварительные испытания, опытная эксплуатация, приемочные испытания проводятся комиссией, создаваемой организационно-распорядительным документом Заказчика, который должен определять состав комиссии, порядок ее работы. Методы предварительных испытаний и порядок их проведения должны быть определены в документе «Программа и методика предварительных испытаний», который должен быть утвержден Заказчиком до начала предварительных испытаний. По результатам предварительных испытаний оформляется Протокол предварительных испытания и Акт о приемке в опытную эксплуатацию. Порядок проведения и методы испытаний во время опытной эксплуатации должны быть определены в документе «Программа опытной эксплуатации», который должен быть утвержден Заказчиком до начала опытной эксплуатации. Ход и результаты опытной эксплуатации отражаются в документе «Журнал опытной эксплуатации», и учитываются в ходе приемочных испытаний. По результатам опытной эксплуатации подписывается Акт о завершении опытной эксплуатации - - Значение характеристики не может изменяться участником закупки - До момента подключения внешних ИС, Подрядчиком могут быть использованы эмуляторы ИС для прохождения предварительных испытаний, опытной эксплуатации и приемочных испытаний. В рамках опытной эксплуатации должны быть проведены мероприятия по нагрузочному тестированию Модуля СЦ. Документ «Программа и методика приемочных испытаний» должен быть разработан с учетом недостатков, выявленных в ходе опытной эксплуатации, утвержден Заказчиком до начала приемочных испытаний, при этом проверки Модуля СЦ в части не устраненных недостатков, выявленных в процессе опытной эксплуатации, должны быть вынесены в отдельный раздел «Программы и методики приемочных испытаний». В процессе приемочных испытаний должно быть проверено устранение недостатков, полученных в ходе опытной эксплуатации. После завершения устранения всех замечаний, препятствующих приемке Системы в эксплуатацию, перечисленных в Протоколе приемочных испытаний, Подрядчик должен письменно уведомить Заказчика о том, что все замечания устранены, после чего приемочные испытания по решению Заказчика могут быть проведены повторно. Процедура приемочных испытаний проводится до подписания Протокола приемочных испытаний, не содержащего замечаний, препятствующих приемке Системы в эксплуатацию. Приемочные испытания Системы считаются завершенными успешно, если Протокол приемочных испытаний не содержит замечаний, препятствующих приемке Системы в эксплуатацию - 8. ТРЕБОВАНИЯ К СОСТАВУ И СОДЕРЖАНИЮ РАБОТ ПО ПОДГОТОВКЕ МОДУЛЯ СЦ К ВВОДУ В ЭКСПЛУАТАЦИЮ - По результатам проведения приемочных испытаний оформляется Протокол приемочных испытаний и Акт приемки в эксплуатацию. В случае, если взаимодействие с внешними системами не может быть проверено на средах постоянной эксплуатации взаимодействующих систем (по причине неготовности со стороны внешней системы или иным причинам), функции взаимодействия, разработанные в соответствии с требованиями ТЗ, должны быть проверены на тестовых данных с использованием программ-имитаторов взаимодействия. По результатам выполнения этапа приемочных испытаний должны быть подготовлены материалы для регистрации доработанной версии Модуля СЦ (объекта учета) в НФАП в соответствии с требованиями постановления Правительства Российской Федерации от 30 января 2013?г. №?62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин» (с изменениями и дополнениями) в части обязательности размещения результатов работ в национальном фонде алгоритмов и программ для электронных вычислительных машин. Сдача-приемка результатов выполнения Работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная, техническая документация, а также программное обеспечение предоставляется Заказчику в порядке, предусмотренном Контрактом и ТЗ до размещения Подрядчиком в Единой информационной системе в сфере закупок документа о приемке. Результаты проведения опытной эксплуатации, предварительных и приемочных испытаний должны быть зафиксированы в соответствующих протоколах и актах. Выявленные отклонения от настоящего ТЗ, оформляются как недостатки Модуля СЦ - - Значение характеристики не может изменяться участником закупки - Протоколы предварительных и приемочных испытаний должны содержать вывод о соответствии Модуля СЦ предъявляемым требованиям, а также сроки устранения замечаний и реализации рекомендаций, сформулированных комиссией в ходе предварительных и приемочных испытаний. Условием для передачи Модуля СЦ в промышленную эксплуатацию является устранение всех замечаний. Документация на Модуль СЦ и ее части (техническая и рабочая) должна содержать исчерпывающее описание принятых проектных решений в объеме, достаточном для ее дальнейшего развития и эксплуатации. Техническая и рабочая документация должна содержать описание разработанных результатов работ, в том числе программ для ЭВМ, прикладных программных интерфейсов, алгоритмов и протоколов информационного взаимодействия, технических требований, спецификаций и форматов обмена данными для взаимодействия с другими информационными системами, в объеме, достаточном для их установки, настройки, эксплуатации и развития в дальнейшем без привлечения Подрядчика. Исходные коды передаются в виде и составе, позволяющем провести: – сборку (компиляцию) Модуля СЦ в контролируемой Заказчиком среде; – установку полученной Модуля СЦ на специально подготовленную контролируемую Заказчиком инфраструктуру; – проверку функциональных возможностей Модуля СЦ; – оформление Модуля СЦ в качестве объекта национального фонда алгоритмов и программ для электронных вычислительных машин - 8.1. Требования, предъявляемые в соответствии с Приказом Минцифры России от 17.12.2020 № 715 «Об утверждении типовых условий контрактов на выполнение работ по созданию и (или) развитию (модернизации) государственных (муниципальных) и (или) иных информационных систем» Передача исходных кодов, разработанных в ходе выполнения работ, программ для электронных вычислительных машин (далее – программа для ЭВМ) должна сопровождаться передачей всех необходимых для сборки и запуска программы для ЭВМ библиотек зависимостей, программных сценариев (скриптов) для проведения установки (развертывания) программы для ЭВМ. Подрядчик в процессе сдачи-приемки работ по Контракту должен провести демонстрацию процесса и установки (развертывания) разработанных программ для ЭВМ. Документация на Модуль СЦ должна содержать описание принятых проектных решений в объеме, достаточном для ее дальнейшего развития и эксплуатации - 9. ТРЕБОВАНИЯ К ДОКУМЕНТИРОВАНИЮ - 9.1. Общие требования Документация на Модуль СЦ должна быть разработана в составе, указанном в разделах 5-8 данного ТЗ, и должна удовлетворять требованиям комплекса стандартов и руководящих документов на автоматизированные системы: – ГОСТ Р 2.105-2019 в части оформления текстовых документов; – ГОСТ 34.201-2020 в части наименования и обозначения документов. Документация на Модуль СЦ должны оформляться на листах формата А4. Допускается для размещения рисунков и таблиц использование листов формата А3 с подшивкой по короткой стороне листа. Документы объемом более 25 (двадцати пяти) листов должны содержать информационную часть, состоящую из аннотации и содержания. Исходные коды должны быть представлены в 1 (одном) экземпляре на электронном носителе, отчетные материалы должны быть представлены в 2 (двух) экземплярах на бумажном носителе (по одному экземпляру для Заказчика и Подрядчика) и в 1 (одном) экземпляре на электронном носителе в формате документов DOCX и PDF. При разработке документов на Модуль СЦ допускается отклонение от требований комплекса стандартов, описанных выше. Документам на Модуль СЦ должны в обязательном порядке присваиваться уникальные децимальные номера в соответствии с порядком, установленном в ГОСТ 34.201-2020. Документ «Программа и методика предварительных испытаний» должен включать приложения с формой протокола предварительных испытаний и формой акта приемки в опытную эксплуатацию. Документ «Программа опытной эксплуатации» должен включать приложение с формой журнала опытной эксплуатации. Документ «Программа и методика приемочных испытаний» должен включать приложения с формой протокола приемочных испытаний и формой акта приемки в эксплуатацию - - Значение характеристики не может изменяться участником закупки - 10. ИСТОЧНИКИ РАЗРАБОТКИ - 10.1. Список литературы Специальная литература для разработки ТЗ не использовалась. 10.2. Нормативно-методические документы Список используемых нормативно-методических документов представлен в разделе 1.6 технического задания. ? Приложение А Эскизы визуального оформления компонента «Интерактивная карта» - - Значение характеристики не может изменяться участником закупки - Приложение Б Параметры оказания услуг - Б.1. Базовые параметры оказания Услуг Базовые параметры оказания Услуг приведены ниже: – режимы оказания Услуг (таблица Б.1.1); – сроки предоставления отчетности (таблица Б.1.2). Таблица Б.1.1 - Режимы оказания Услуг № п/п Параметр Значение - - Значение характеристики не может изменяться участником закупки - 1 Режим работы Системы Круглосуточно (24х7) 2 Режим доступности информационно-консультационной поддержки пользователей Системы 2.1 Прием и регистрация обращений (заявок) в СРО Регистрация обращений (заявок) производится круглосуточно в режиме 24х7, без праздников и выходных дней. Обработка заявок первой линией поддержки осуществляется в рабочие дни с 9 до 18 часов 2.2 Консультирование сотрудников Заказчика и пользователей Системы в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 3 Режим доступности по решению инцидентов, связанных с работой ППО: 3.1 - приоритет «Критический» Круглосуточно (24х7) 3.2 - приоритет «Высокий» Круглосуточно (24х7) 3.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 3.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4 Режим доступности услуг по адаптации, конфигурации и коррекционному сопровождению Системы 4.1 - приоритет «Критический» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.2 - приоритет «Высокий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 5 Режим доступности по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности 5.1 - приоритет «Критический» Круглосуточно (24х7) 5.2 - приоритет «Высокий» Круглосуточно (24х7) 5.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 5.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) - Таблица Б.1.2. Сроки предоставления отчетности, с момента получения запроса № п/п Параметр Значение 1 Предоставление отчета об оказанных услугах за произвольный период 10 рабочих дней 2 Предоставление подробной информации по инциденту с приоритетом «Критический» 16 рабочих часов 3 Предоставление актуализированной документации 10 рабочих дней - Б.2. Приоритеты и регламентные сроки решения обращений (заявок) В зависимости от уровня сбоя в работе Системы обращению (заявке) присваивается один из следующих приоритетов, а также в зависимости от приоритета обращения (заявки) устанавливаются следующие контрольные сроки решения в соответствии с таблицей ниже (Таблица Б.2.1). Таблица Б.2.1 – Приоритеты и регламентные сроки решения обращений (заявок) № п/п Приоритет Максимальное время реагирования Время решения (срок выполнения) Описание приоритета По информационно-консультационной поддержке сотрудников Заказчика и пользователей Системы 1 - не более 1 часа не более 10 часов - По решению инцидентов, связанных с работой ППО: 1 Критический не более 30 минут не более 4 часов - полная недоступность ППО; - недоступность ключевых функций - ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО; - невозможность информационного обмена с ППО для ИС более 4 часов 2 Высокий не более 1 часа не более 8 часов - ошибки/сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; - снижение быстродействия СПО (время отклика ППО на операции превышает 30 секунд); - недоступность управления правами и ролями пользователей 3 Средний не более 4 часов не более 24 часов - невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым -недоступность функции формирования отчетов 4 Низкий не более 8 часов не более 40 часов - отклонение в работе ППО, не влияющее на корректную работу функций; - другие сбои и ошибки, затрагивающие основные функции ППО - По адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) 1 Критический не более 40 минут не более 8 часов - изменения, необходимые при проведении аварийно-восстановительных работ для возобновления работоспособности Системы; - изменения, связанные с критичными ошибками, блокирующими возможность оказания государственных услуг и/или чтение и внесение данных в Систему 2 Высокий не более 1 часа не более 40 часов - изменения, относящиеся к обеспечению работоспособности основной функциональности Системы, устраняют выявленные дефекты в работе Системы, оказывающие существенное влияние на работу пользователей в Системе; - изменения, затрагивающие три и более подсистемы/модуля Системы для адаптации 3 Средний не более 4 часов не более 72 часов - изменения, связанные с развитием/улучшением/оптимизацией Системы и выводом новой функциональности в штатном режиме для одного-двух модулей/подсистем; - изменения, связанные с развитием интеграционных механизмов Системы, например обновление существующих и/или реализация новых видов сведений СМЭВ, обновление существующих и/или реализация новых API, адаптация и/или изменение механизмов импорта и экспорта данных Системы и т.д. 4 Низкий не более 8 часов не более 160 часов - изменения, связанные с ошибками/корректировкой/изменением в отображении информации в пользовательском графическом интерфейсе Системы (графика, текст, органы управления, элементы интерфейса) - По устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности 1 Критический не более 30 минут не более 24 часов - критические уязвимости, влияющие на возможную полную недоступность ППО, ключевых функций Системы, ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО без возможности восстановления работоспособности Системы. - Критический уровень CVSS > 8.0 2 Высокий не более 1 часа не более 84 часов - критические уязвимости, влияющие на ошибки и сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО. - Высокий уровень CVSS 5.0 - 8.0 3 Средний не более 4 часов не более 120 часов - уязвимости, влияющие на невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым - Средний уровень CVSS 2.0 - 4.9 4 Низкий не более 8 часов не более 160 часов - уязвимости, влияющие на отклонение в работе ППО, не влияющее на корректную работу функций; - другие сбои и ошибки, затрагивающие основные функции ППО - Низкий уровень CVSS < 2.0 - Взаимодействие Заказчика и Подрядчика в части регистрации и контроля времени реагирования и решения обращения (заявки) осуществляется через СРО. Заказчик предоставляет Подрядчику доступ к СРО после заключения Контракта. Поступившие от разных пользователей заявки по поводу однотипных инцидентов или имеющие общую причину должны объединяться в одну заявку. Срок выполнения включает время диагностики инцидента, в ходе которого определяется причина инцидента (проблемы) и способ его устранения. Подрядчик должен обеспечить функционирование Модуля СЦ в соответствии с требованиями и параметрами, указанными в настоящем ТЗ и Регламенте оказании услуг. Основные параметры быстродействия типовых операций в Модуле СЦ указаны в таблице ниже (таблица Б.2.2). Таблица Б.2.2 - Параметры быстродействия Модуля СЦ № п/п Наименование параметра Значение (секунд) 1 Среднее время получения сообщения из очереди сообщений 10 2 Среднее время получения ответа от Системы 5 3 Среднее время открытия карточки реестра 5 - Приложение В Регламент оказания услуг - Приложение Д Форма Протокола проверки результатов организационно-штатных и подготовительных мероприятий (шаблон) Протокол проверки результатов организационно-штатных и подготовительных мероприятий Настоящий Протокол содержит результаты проверки организационно-штатных и подготовительных мероприятий, проведенных Исполнителем (Таблица Д.1). Таблица Д.1. Протокол проверки результатов № Мероприятия Подготовительного этапа Результат проверки 1. Определить и направить Заказчику документ «Ответственные за взаимодействия в рамках выполнения работ по техническому сопровождению Системы со стороны Исполнителя». Документ содержит контактную информацию (ФИО, должность, адрес электронной рабочей почты, номер телефона) не менее чем о 2 лицах, ответственных за оказание услуг со стороны Подрядчика Выполнено/Не выполнено 2. Обеспечить подключение специалистов Подрядчика к Системе Выполнено/Не выполнено 3. Обеспечить подключение специалистов Подрядчика к СРО Выполнено/Не выполнено Заказчик Подрядчик /Должность/ /Должность/ ____________________ /Ф.И.О/ ___________________ /Ф.И.О/ М.П. М.П. «_____»_______________________202_г. «_____»_______________________202_г - - Значение характеристики не может изменяться участником закупки - Термины и сокращения В настоящем регламенте используются следующие термины и сокращения на русском и английском языках: Термины/сокращения Полное наименование/описание БЗ (База знаний) База данных Системы регистрации обращений (заявок), созданная для сбора, хранения и поиска способов решения известных проблем в рамках Системы Жизненный цикл обращения (заявки) Совокупность статусов, по которым проходит обращение (заявка), и правила перехода обращения (заявки) из одного статуса в другой Заказчик ФГБУ «СИЦ Минтранса России» – Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» ЗНИ Запрос на изменение – тип заявки, предполагающий внесение изменений в прикладное программное обеспечение Системы ЗНО Запрос на обслуживание – тип заявки, предполагающий работы по предоставлению консультации, предоставление доступа к Системе или стандартизированные типовые изменения конфигураций Системы Инцидент Тип заявки, классифицируемый как нештатное событие в работе компонентов функциональных задач Системы, которое привело или может привести к нарушению или снижению качества функционирования Системы ИС Информационная система Исполнитель Организация, которая определяется по результатам конкурсных процедур Классификация Анализ и заполнение классификационных полей справочными значениями, определяющими последовательность действий и этапов жизненного цикла заявки, а также порядок рассмотрения заявок Консультация Разъяснения по алгоритму работы, требуемых настроек прикладного программного обеспечения и технологии обработки данных при работе с Системой, предоставление информации Маршрутизация Определение процесса движения обращения (заявки) в Системе управления заявками между уровнями технической поддержки и организационными структурами на уровнях поддержки путем назначения обращения (заявки) в соответствии с его классификацией и выставленным приоритетом - Обращение (заявка) Устное или письменное обращение пользователя АСУ ТК с вопросом, касающимся работоспособности АСУ ТК, по одному из определённых каналов связи: электронная почта, Система регистрации обращений (заявок) Пользователь Инициатор обращения (заявки) или пользователь Системы ППО Прикладное программное обеспечение Предмет обращения Справочник, классифицирующий типовые запросы в Системе регистрации обращений (заявок), характерные для Системы, выбранное значение определяет маршрутизацию обращения (заявки) (группу ответственных сотрудников) Приоритизация Значение, определяющее время, очередность решения обращений (заявок), ресурсы, привлекаемые для решения обращений (заявок), . Приоритет устанавливается в соответствии с масштабом выявленной проблемы, которая привела или может привести к нарушению или снижению качества функционирования Системы Релиз Выпуск версии прикладного программного обеспечения Системы, от разработки до тестирования и планового обновления Системы на продуктивной среде для установки изменений, связанных с развитием/улучшением/оптимизацией Системы Система, АСУ ТК, Информационно-аналитическая система регулирования на транспорте Информационно-аналитическая система, предназначенная для автоматизации и информационно-аналитического обеспечения процессов управления развитием транспортного комплекса Российской Федерации, обеспечения публичности деятельности органов государственного управления транспортным комплексом, а также обеспечения процессов оказания государственных услуг в электронном виде в сфере транспорта СМЭВ Система межведомственного электронного взаимодействия СПО Системное программное обеспечение СРО Система регистрации обращений (заявок) Статус обращения (заявки) Текущее состояние обращения (заявки) в жизненном цикле процесса оказания технической поддержки Системы СУБД Система управления базами данных - Уровень технической поддержки Организационно-структурная часть технической поддержки, имеющая определённые организационно-нормативными документами зоны ответственности, обязанности, а также временные нормативы, в течение которых эти обязательства должны выполняться либо эскалироваться на следующий уровень технической поддержки Услуги Услуги по технической поддержке Информационно-аналитической системы регулирования на транспорте АСУ ТК ФИО Фамилия, имя, отчество Эскалация Процедура повышения внимания к обращению (заявке) путем повышения его приоритета и/или передачи на следующий уровень технической поддержки, а также привлечение ролей, которые могут принимать решения без передачи на следующий уровень технической поддержки API Англ. Application Programming Interface — программный интерфейс приложения, интерфейс прикладного программирования — описание способов (набор классов, процедур, функций, структур или констант), которыми одна компьютерная программа может взаимодействовать с другой программой - CVSS Англ. Common Vulnerability Scoring System - открытый стандарт, используемый для расчета количественных оценок уязвимости в безопасности компьютерной системы, обычно с целью понять приоритет ее исправления. В современном инструментарии информационной безопасности используется версия 3.0 и выше с дополнительными метриками к базовым оценкам ID Англ. Identifier – идентификатор, уникальный признак объекта, позволяющий отличать его от других объектов, то есть, идентифицировать SLA Англ. Service Level Agreement - утвержденные условия по обработке обращения (заявки) с установленными метриками времени, которые определяют пороговые значения для эскалации в зависимости от статуса обращения (заявки) (например, время реакции – время от регистрации до осуществления первичной обработки, время решения – время от регистрации обращения (заявки) до его решения и т.д.) SQL Англ. Structured Query Language — «язык структурированных запросов», — декларативный язык программирования, применяемый для создания, модификации и управления данными в реляционной базе данных, управляемой соответствующей СУБД - 1 Общие сведения 1.1 Полное наименование Услуг Оказание услуг по технической поддержке Модуля СЦ АСУ ТК в 2026 году. 1.2 Предмет Регламента оказания услуг Требования Технического задания - 2 Общие положения 2.1 Цель и задачи оказания услуг Целью технической поддержки Системы является обеспечение ее стабильного и безопасного функционирования и эксплуатации, предупреждение, выявление и устранение сбоев в работе Системы и минимизация их неблагоприятного влияния. Для достижения поставленной цели требуется решение следующих задач: 1. Обеспечение информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы. 2. Поддержание параметров функционирования ППО Системы, удовлетворяющих требованиям производственных процессов, включая их непрерывность. 3. Обеспечение бесперебойного функционирования ППО и своевременное устранение сбоев и аварийных ситуаций в Системе. 4. Своевременное устранение уязвимостей при выявлении таковых, в соответствии с требованиями к обеспечению информационной безопасности. 5. Адаптация, конфигурирование, коррекция программного обеспечения в соответствии с изменениями нормативно-правовой базы и запросами уполномоченных сотрудников органов государственной власти, включая выполнение процедур тестирования и участие в обновлениях ППО на стендах Заказчика. 6. Обеспечение сохранения работоспособности ППО в изменяемой среде эксплуатации. 7. Ведение документации по настоящему контракту и инициирование актуализации документации на Систему по результатам обработки запросов Заказчика и внесения соответствующих изменений в ППО - 2.2 Общее описание процесса оказания сопровождения (технической поддержки) Системы Процесс оказания технической поддержки Системы включает: 1. Поступление обращений (заявок) от пользователей и их регистрацию. 2. Сопровождение обращений (заявок) в соответствии с их классификацией и приоритизацией, в том числе, с их последующей эскалацией. 3. Определение ролей и регламент их взаимодействия при осуществлении деятельности по процессу. 4. Решение обращений (заявок) в установленные настоящим Регламентом сроки. 5. Взаимодействие между 1-м, 2-м и 3-м уровнями технической поддержки, в том числе, с формированием заданий для сопровождения Системы. 6. Контроль качества выполняемых Исполнителем работ, состоящий из проверки сценария, приводящего к ошибке, зафиксированной в Инциденте, и/или к ошибке воспроизведения, а также тестирование внесенных изменений в рамках ЗНИ. 7. Обеспечение мониторинга и проведение анализа процесса обработки поступающих в техническую поддержку обращений (заявок). Техническая поддержка реализуется путем проведения ответственными сотрудниками соответствующей информационно-консультационной деятельности в соответствии с определенными ролями, а также выполнения Исполнителем конкретных действий по своевременному выявлению причин сбоев и аварийных ситуаций и их устранению, а также по адаптации, конфигурированию, корректировке Системы, включая выполнение процедур тестирования и участия в обновлениях Системы. Все роли подразделяются на уровни поддержки, взаимодействующие между собой в соответствии с блок-схемой процесса технической поддержки. Общая схема процесса рассмотрения обращений (заявок) в соответствии с видами технической поддержки представлена на рисунке 1. . Рисунок 1 - Общая схема процесса рассмотрения обращений (заявок) в соответствии с видами технической поддержки - 2.3 Каналы связи Должна быть предусмотрена омниканальность в части приема обращений (заявок). Получение обращений (заявок) технической поддержкой происходит по следующим каналам связи: – СРО; – электронная почта; – телефонная линия. Исполнитель обеспечивает прием обращений (заявок) от Заказчика и предоставляет информацию в рамках оказания услуг по техническому сопровождению Системы, руководствуясь матрицей взаимодействия, приведенной в Приложении 1 к настоящему Регламенту - 3 Порядок оказания Услуг 3.1 Типы обращений (заявок) Обращения и заявки Заказчика классифицируются в соответствии с приоритетами и регламентными сроками, указанными в Приложении 2 к настоящему Регламенту. Регистрация обращений и заявок предусматривает создание новой записи в СРО с присвоением поступившему обращению или заявке (новой записи) уникального идентификатора. Запись в СРО должна содержать вопрос или проблему, которую требуется решить или оказать консультацию. Если обращение или заявка автоматически зарегистрированы в СРО при отправке представителем Заказчика, Исполнитель проверяет корректность указанного типа обращения (заявки) и может обратиться к Заказчику с просьбой корректировки, предоставив обоснования в соответствии с настоящей классификацией (Таблица 1) - Таблица 1 - Типы обращений (заявок) Тип обращения (заявки) Описание Запрос на обслуживание Подготовка SQL запроса к СУБД для решения прикладной задачи и д р. – запрос на любое действие, не являющееся запросом информации и несовершенный на основе происшествия, прямо или косвенно влияющего на работу Системы Консультация (входит в тип обращения (заявки) «Запрос на обслуживание») «Где взять / куда обратиться...?», «Как сделать / выполнить…», «Как это работает…?» - запрос, имеющий своей целью получение информационной поддержки Инцидент Разбор ошибок/сбоев и подготовка материалов (корректировочных релизов, инструкций) для Заказчика для устранения ошибок/сбоев, которые приводят к частичному и полному нарушению работоспособности всех или отдельных функций ППО. Подготовка изменения и материалов, необходимых для проведения аварийно-восстановительных работ для возобновления работоспособности Системы. ЗНИ Подготовка изменений, связанных с изменением, улучшением/оптимизацией Системы и выводом новой модифицированной функциональности в штатном режиме. Подготовка изменений, связанных с модификацией существующих и/или реализация новых интеграционных механизмов для получения/обработки данных внешних систем. Подготовка изменений графического интерфейса по требованиям Заказчика - 3.2 Участники технической поддержки, осуществляющие сопровождение обращений (заявок) Техническая поддержка Системы должна быть организована на трех уровнях: 1. Первый и второй уровни технической поддержки организуется Заказчиком. 2. Третий уровень технической поддержки организуется Исполнителем. Зона ответственности каждого уровня технической поддержки указана в Таблице 2. Таблица 2 - Зона ответственности каждого уровня технической поддержки Участники технической поддержки Описание - Первый уровень технической поддержки (далее – 1-й уровень) Группа ответственных сотрудников 1-го уровня Заказчика, осуществляющая прием и первичную обработку обращений (заявок) (описание предмета обращения, первичная классификация и приоритизация, определение назначения, маршрутизация обращений (заявок) по назначению), руководствуется в своей работе настоящим Регламентом и БЗ, наполняемой 2-м уровнем поддержки, самостоятельно решает часть обращений (заявок), связанных с недостаточной квалификацией пользователей или настройками в рамках своей компетенции. В случае невозможности решения обращений (заявок) на 1-ом уровне ответственный сотрудник передает ее на 2-й уровень - Второй уровень технической поддержки (далее – 2-й уровень) Группа ответственных сотрудников 2-го уровня Заказчика по установленным компетенциям (информационная безопасность, сопровождение и эксплуатация информационно-аналитических систем, развитие информационно-аналитических систем, техническая поддержка информационно-аналитических систем) отвечает за поддержание работоспособности Системы, обработку обращений (заявок) и их решение в регламентные сроки в соответствии с установленными приоритетами. Осуществляет информационно-консультационную поддержку пользователей Системы в рамках своей компетенции. Оказывает экспертную помощь ответственным сотрудникам 1-го уровня в части формирования БЗ, содержащей ответы на часто задаваемые вопросы пользователей, с целью передачи знаний, навыков и инструментария на 1-й уровень для ускорения решения обращений (заявок). В случае невозможности решения обращения (заявки) на 2-ом уровне ответственный сотрудник передает его на 3-й уровень. При выявлении необходимости изменений в ППО Системы инициирует формирование обращения (заявки) и направляет его на группу ответственных сотрудников 3-го уровня по соответствующему классификатору (ЗНО, ЗНИ, и т.д.) - Третий уровень технической поддержки (далее – 3-й уровень) Группа ответственных сотрудников Исполнителя, отвечающая за устранение сбоев и аварий, проведение информационно-консультационной поддержки пользователей Системы, проведение адаптации и конфигурирования Системы в объемах действующих контрактов на оказание технической поддержки - 3.3 Перечень и описание статусов обращений (заявок) В Таблице 3 приведен перечень статусов обращений (заявок), действующий в СРО, и их описание. Таблица 3 - Перечень статусов обращений (заявок) и их описание Статус Описание Зарегистрирован Обращение (заявка) принято и зарегистрировано Направлен в группу Присваивается при назначении ответственными сотрудниками 1-го уровня группе ответственных сотрудников 2-го уровня по тематике обращения (заявки) после заполнения всей необходимой информации и полей обращения (заявки), а также при его передаче между группами 2-го уровня Передан в группу Присваивается при передаче обращения (заявки) ответственными сотрудниками 2-го уровня на группу ответственных сотрудников 3-го уровня Назначен Присваивается при назначении обращения (заявки) на ответственного сотрудника для его решения в рамках компетенции В работе Присваивается при приеме обращения (заявки) в работу ответственным сотрудником для его решения Решен Присваивается ответственным сотрудником, выполнившим работы по обращению (заявке) Закрыт Присваивается автоматически при решении запроса по обращению (заявке), а также отсутствии дополнительных запросов пользователя в соответствии с действующим SLA, или при подтверждении решения обращения (заявки) со стороны пользователя Запрос доп. информации Присваивается при необходимости запроса дополнительной информации и/или уточнения предмета обращения по обращению (заявке) у пользователя Ответ предоставлен Присваивается после ответа пользователем на запрос дополнительной информации Отклонен Присваивается, если обращение (заявка) не актуальна (по информации от пользователя), отсутствует техническая возможность решения обращения (заявки), предмет обращения не входит в компетенции технической поддержки, или существует влияние доработки на другие компоненты, что нарушает общий порядок работы Системы - Согласование Присваивается при необходимости согласования направления обращения (заявки) ответственным сотрудником Заказчика на 3-й уровень Анализ Присваивается при проведении анализа на предмет возможности внесения изменений, связанных с развитием/улучшением/оптимизацией Системы и выводом новой функциональности и оценке ресурсоемкости Тестирование Присваивается Исполнителем при завершении разработки и проведенном предварительном тестировании для последующего осуществления приемочного тестирования Специалистом 2-го уровня Релиз Присваивается ответственным сотрудником Заказчика при принятии решения о возможности вывода доработки в продуктивную среду Утверждение заказчиком Присваивается при согласовании группой профильных специалистов на 2-м уровне поддержки с пользователем технического задания для внесения изменений, связанных с развитием/улучшением/оптимизацией Системы и выводом новой функциональности Доработка Присваивается в случае несогласования Заказчиком работ, проведенных Исполнителем в рамках контрактных обязательств, по внесению изменений, связанных с развитием/улучшением/оптимизацией Системы и выводом новой функциональности в штатном режиме, и необходимости последующего направления Исполнителю для ее доработки Отложен Присваивается в случае невозможности выполнения запроса, изложенного в обращении (заявке), в связи с необходимостью запроса дополнительной информации у третьих сторон - 3.4 Порядок регистрации и сопровождения Заявок Порядок регистрации и сопровождения обращений (заявок) в рамках оказываемых услуг по технической поддержке Системы зависит от типа обращения (заявки): 1. Услуга по решению инцидентов, связанных с работой ППО – тип обращения (заявки) «Инцидент». 2. Услуга по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности – тип обращения (заявки) «Инцидент». 3. Услуга информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы – тип обращения (заявки) «Запрос на обслуживание» (в том числе, консультационный запрос). 4. Услуга адаптационного, конфигурационного и коррекционного сопровождения Системы (в рамках действующих программных модулей и функциональностей) – тип обращения (заявки) «Запрос на изменение». В случае недоступности СРО взаимодействие и информирование Исполнителем о ходе оказания услуги по обращению (заявке), изменению статусов обращений (заявок) осуществляется по согласованию с Заказчиком в соответствии с матрицей взаимодействия, представленной в Приложении 1 к настоящему Регламенту. - 3.4.1 Инцидент На рисунке 2 представлена функциональная схема регистрации и сопровождения обращений (заявок) типа «Инцидент». Рисунок 2 - Функциональная схема регистрации и сопровождения обращений (заявок) типа «Инцидент» 3.4.2 Запрос на обслуживание На рисунке 3 представлена функциональная схема регистрации и сопровождения обращения (заявки) типа «ЗНО». Рисунок 3 - Функциональная схема регистрации и сопровождения обращения (заявки) типа «ЗНО» 3.4.3 Запрос на изменение На рисунке 4 представлена функциональная схема регистрации и сопровождения обращений (заявок) типа «ЗНИ». Рисунок 4 - Функциональная схема регистрации и сопровождения обращений (заявок) типа «ЗНИ» - 3.5 Порядок классификации и приоритизации обращений (заявок) Классификация является начальной стадией процесса оказания технической поддержки, необходимой для идентификации обращения (заявки) и определения соответствующих действий для его обработки. Для проведения первичной классификации необходимо получить от пользователя и зафиксировать в описании обращения (заявки) подробные сведения о сути запроса, в том числе, для Инцидентов зафиксировать сценарий воспроизведения обнаруженной ошибки. Для проведения вторичной классификации необходимо провести анализ и диагностику для определения корневой причины и затронутой Инцидентом функциональной области (инфраструктура, сеть, ППО). В процессе классификации осуществляется первичная диагностика и оценка проблемы, описанной пользователем Системы в обращении (заявке), в части функционирования и/или удобства использования Системы. Корректная классификация позволяет увеличить скорость обработки обращения (заявки) и решения описанной в обращении (заявке) проблемы при минимальном привлечении ресурсов, в частности, за счет использования известных решений для типовых обращений (заявок), которые должны описываться в БЗ СРО. Классификация позволяет произвести первоначальное назначение обращения (заявки) на ответственного сотрудника и выставить приоритет с учетом приоритизации. Приоритизация применяется для определения критичности описанной в обращении (заявке) проблемы для функционирования ППО Системы. Приоритет рассмотрения обращения (заявки) определяется в процессе ее классификации на основании ряда параметров, вводимых при заполнении обращения (заявки). Приоритизация используется для того, чтобы при одновременном наличии нескольких обращений (заявок) в первую очередь рассматривалась обращения (заявки) с наивысшим приоритетом и не позднее установленных для данного приоритета сроков - Изменение приоритета уже зарегистрированного обращения (заявки) используется в случае появления новых обстоятельств, которые ведут к изменению влияния и/или срочности существующего обращения (заявки). При регистрации обращения (заявки) необходимо провести его приоритизацию. В процессе управления обращениями (заявками) каждому обращению (заявке) присваивается приоритет, принимающий одно из значений: Низкий, Средний, Высокий или Критический. В соответствии с приоритетом определяется время, очередность устранения, , ресурсы, привлекаемые для работ по обращению (заявке), а также может определяться порядок/процедура действий при работе с обращением (заявкой). Заказчиком в зависимости от уровня сбоя в работе Системы обращению (заявке) присваивается приоритет с указанием максимального времени реакции и решения в соответствии с требованиями, указанными в Приложении 2 к настоящему Регламенту - 4 Формы обращений (заявок) на оказание услуг по технической поддержке Системы, заполняемые в СРО 4.1. Форма обращения (заявки) на оказание услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы При подаче обращения (заявки) типа «ЗНО» в СРО указывается (Таблица 5): Таблица 5 – Описание атрибутов формы обращения (заявки) на оказание услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 5) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 5) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 5) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 5) Категория обращения: информационно-консультационная поддержка Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 5) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 5) Текст запроса на оказание услуги по информационно-консультационной поддержке сотрудников Заказчика Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 5) - На рисунке 5 приведена форма обращения (заявки) типа «ЗНО» в СРО. Рисунок 5 - Форма обращения (заявки) типа «ЗНО» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы, заполненную в свободной форме. - 4.2. Форма обращения (заявки) на оказание услуги по решению инцидентов, связанных с работой ППО При подаче обращения (заявки) типа «Инцидент» в СРО указывается (Таблица 6): Таблица 6 – Описание атрибутов формы обращения (заявки) на оказание услуги по решению инцидентов, связанных с работой ППО Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 6) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 6) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 6,) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 6) Категория обращения (заявки): инцидент Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 6) Приоритет изменения Время - одно из значений: Низкий, Средний, Высокий или Критический. Определяет, очередность решения обращения (заявки), ресурсы, привлекаемые для решения обращения (заявки), порядок/процедура действий при решении обращения (заявки) – поле СРО «Приоритет» (см. рисунок 6,) - Тип изменения Справочник, классифицирующий типовые запросы характерные для Системы – поле СРО «Предмет обращения» (см. рисунок 6) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 6) Полное описание инцидента, включая скриншоты и описание шагов, приведших к неисправности Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 6) Однократность/неоднократность Круг пользователей или компьютеров, затронутых данным инцидентом Действия, предпринятые для самостоятельного решения инцидента (при наличии) Версии используемого программного обеспечения на клиентской рабочей станции, где воспроизводится ошибка (операционная система, прикладное программное обеспечение) Дополнительная информация - На рисунке 6 приведена форма обращения (заявки) типа «Инцидент» в СРО. Рисунок 6 - Форма обращения (заявки) типа «Инцидент» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуги по решению инцидентов, связанных с работой ППО, заполненную в свободной форме - 4.3. Форма обращения (заявки) на оказание услуг по адаптационному конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) При подаче обращения (заявки) типа «ЗНИ» в СРО указывается (Таблица 7): Таблица 7 – Описание атрибутов формы обращения (заявки) на оказание услуг по адаптационному, конфигурационному и коррекционному сопровождению Системы Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 10) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 9) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 10) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 10) Категория обращения (заявки): запрос на изменение Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 7) Приоритет изменения Время, очередность решения обращения (заявки), ресурсы, привлекаемые для решения обращения (заявки), порядок/процедура действий при решении обращения (заявки) – поле СРО «Приоритет» (см. рисунок 7) Тип изменения Справочник, классифицирующий типовые запросы характерные для Системы – поле СРО «Предмет обращения» (см. рисунок 7) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 7) Текст запроса на оказание услуги по адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 7) - На рисунке 7 приведена форма обращения (заявки) типа «ЗНИ» в СРО. Рисунок 7 - Форма обращения (заявки) типа «ЗНИ» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуг по адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей), заполненную в свободной форме - 4.4. Форма обращения (заявки) на оказание услуги по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности При подаче обращения (заявки) типа «Инцидент» в СРО указывается (Таблица 8): Таблица 8 – Описание атрибутов формы обращения (заявки) на оказание услуг по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности - Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 8) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 8) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 8) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 8) Категория обращения (заявки): инцидент Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 8) Приоритет Время, очередность решения обращения (заявки), ресурсы, привлекаемые для решения обращения (заявки), порядок/процедура действий при решении обращения (заявки) – поле СРО «Приоритет» (см. рисунок 8) Тип изменения Справочник, классифицирующий типовые запросы характерные для Системы – поле СРО «Предмет обращения» (см. рисунок 8) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 8) Текст запроса на оказание услуги по обновлению или удалению уязвимых компонентов (библиотек) ППО в соответствии с требованиями к обеспечению информационной безопасности Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 8) - На рисунке 8 приведена форма обращения (заявки) типа «Инцидент» в СРО. Рисунок 8 - Форма обращения (заявки) типа «Инцидент» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуги по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности, заполненную в свободной форме - Приложение 1 к Регламенту Матрица ответственных за взаимодействия в рамках выполнения работ по техническому сопровождению Системы Таблица 1 – Ответственные за взаимодействия в рамках выполнения работ по техническому сопровождению Системы со стороны Исполнителя ФИО Должность Адрес электронной почты Телефон — — — Общий контакт - Приложение 2 к Регламенту Приоритеты и регламентные сроки решения обращений (заявок) Приоритеты и регламентные сроки решения обращений (заявок) приведены в таблице 1. Таблица 1 – Приоритеты и регламентные сроки решения обращений (заявок) № п/п Приоритет Максимальное время реагирования Время решения (срок выполнения) Описание приоритета - По информационно-консультационной поддержке сотрудников Заказчика и пользователей Системы 1 – не более 1 часа не более 10 часов – - По решению инцидентов, связанных с работой ППО 1 Критический не более 30 минут не более 4 часов – полная недоступность ППО; – недоступность ключевых функций; – ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО; – невозможность информационного обмена с ППО для ИС более 4 часов 2 Высокий не более 1 часа не более 8 часов – ошибки/сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; – снижение быстродействия СПО (время отклика ППО на операции превышает 30 секунд); – невозможность управления правами и ролями пользователей 3 Средний не более 4 часов не более 24 часов – невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым недоступность функции формирования отчетов 4 Низкий не более 8 часов не более 40 часов – отклонение в работе ППО, не влияющее на корректную работу функций; – другие сбои и ошибки, затрагивающие основные функции ППО - По адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) 1 Критический не более 40 минут не более 8 часов – изменения необходимые при проведении аварийно-восстановительных работ для возобновления работоспособности Системы; – изменения, связанные с критичными ошибками, блокирующими возможность оказания государственных услуг и/или чтение и внесение данных в Систему 2 Высокий не более 1 часа не более 40 часов – изменения относящиеся к обеспечению работоспособности основной функциональности Системы, устраняют выявленные дефекты в работе Системы, оказывающие существенное влияние на процесс оказания государственных услуг и работу пользователей в Системе; – изменения, затрагивающие три и более подсистемы/модуля Системы для адаптации 3 Средний не более 4 часов не более 72 часов – изменения, связанные с развитием/улучшением/оптимизацией Системы и выводом новой функциональности в штатном режиме для одного-двух модулей/подсистем; – изменения, связанные с развитием интеграционных механизмов Системы, например, обновление существующих и/или реализация новых видов сведений СМЭВ, обновление существующих и/или реализация новых API, адаптация и/или изменение механизмов импорта и экспорта данных Системы и т.д. 4 Низкий не более 8 часов не более 160 часов – изменения, связанные с ошибками/ корректировкой/изменение в отображении информации в пользовательском графическом интерфейсе Системы (графика, текст, органы управления, элементы интерфейса) - По устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности 1 Критический не более 30 минут не более 24 часов – критические уязвимости, влияющие на возможную полную недоступность ППО, ключевых функций Системы, ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО без возможности восстановления работоспособности Системы; – Критический уровень CVSS > 8.0 2 Высокий не более 1 часа не более 84 часов – критические уязвимости, влияющие на ошибки и сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; – Высокий уровень CVSS 5.0 - 8.0 3 Средний не более 4 часов не более 120 часов – уязвимости, влияющие на невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым; – Средний уровень CVSS 2.0 - 4.9 4 Низкий не более 8 часов не более 160 часов – уязвимости, влияющие на отклонение в работе ППО, не влияющее на корректную работу функций; – другие сбои и ошибки, затрагивающие основные функции ППО; – Низкий уровень CVSS < 2.0 - Приложение Г Форма Отчета об оказанных услугах Отчет об оказанных услугах за этап «наименование этапа» в период с «__» _________ по «__» _________. № п/п Наименование услуги Общее количество Номер ОРС Краткое Описание Время реагирования по ТЗ Время реагирования фактическое Время решения по ТЗ Время решения фактическое Результат соблюдения времени реагирования Результат соблюдения времени решения Примечание 1 Услуги по информационно-консультационной поддержке работников Заказчика 2 546782 Консультация по работе Модуля СЦ 1 2 10 часов 11 часов Нет Нет 567123 Консультация по схеме БД 1 1 10 часов 1 час Да Да 2 … … Заказчик Подрядчик /Должность/ /Должность/ ____________________ /Ф.И.О/ ___________________ /Ф.И.О/ М.П. М.П. «_____»_______________________202_г. «_____»_______________________202_г - Приложение 1 к Отчету об оказанных услугах Журнал обращений (заявок) на оказание услуги по информационно-консультационной поддержке пользователей Системы (шаблон) Наименование Исполнителя в этапе «наименование этапа» в период с ________________ по _______________ оказал(о) Услугу по поддержке пользователей Системы в объеме, указанном в Таблице 1 Таблица 1 - Журнал обращений (заявок) пользователей Системы № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. ИТОГО зарегистрировано: Всего обращений (заявок): ________ ИТОГО решено: Всего обращений (заявок): ________ - Приложение 2 к Отчету об оказанных услугах Журнал обращений (заявок) по решению инцидентов, связанных с работой ППО (шаблон) Наименование Исполнителя в этапе «наименование этапа» в период с ________________ по _______________ оказал(о) Услугу по решению инцидентов в объеме, указанном в Таблице 1. Таблица 1 - Журнал по решению инцидентов № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. ИТОГО зарегистрировано: Всего инцидентов: ________ ИТОГО решено: Всего инцидентов: ________ - Приложение 3 к Отчету об оказанных услугах Журнал обращений (заявок) выполнения адаптационного, конфигурационного и коррекционного сопровождения Системы (шаблон) Журнал выполнения адаптации, конфигурации и коррекции Системы сформирован за этап «наименование этапа» в период с «__» _________ по «__» ____________ и представлен в таблице ниже (Таблица 1). Таблица 1 - Журнал выполнения адаптации, конфигурации и коррекции сопровождения Системы № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. Количество выполненных заявок за этап: ________ - Приложение 4 к Отчету об оказанных услугах Журнал обращений (заявок) по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности (шаблон) Журнал обращений (заявок) по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности сформирован за этап «наименование этапа» в период с «__» _________ по «__» ____________ и представлен в таблице ниже (Таблица 1). Таблица 1 - Журнал выполнения заявок по устранению уязвимостей в ППО № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. Количество выполненных заявок за этап: ________

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

ОПРЕДЕЛЕНИЯ, ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ - Автоматизированная система (АС) Система, состоящая из комплекса средств автоматизации, реализующего информационную технологию выполнения установленных функций, и персонала, обеспечивающего его функционирование (ГОСТ Р 59853-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения») АРМ Автоматизированное рабочее место АСУ ТК, Система Информационно-аналитическая система регулирования на транспорте АТС Автоматическая телефонная станция БД База данных ГИС Государственная информационная система ГОСТ Государственный стандарт ГЦОД СИЦ Минтранса России, ГЦОД Головной центр обработки данных ФГБУ «СИЦ Минтранса России» Дашборд Интерактивная аналитическая панель, графический интерфейс. ЕИС Единая информационная система в сфере закупок ЕСИА Единая система идентификации и аутентификации Заказчик Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» КИИ Критическая информационная инфраструктура Кластер Кла?стер (англ. cluster) – объединение нескольких однородных элементов, которое может рассматриваться как самостоятельная единица, обладающая определёнными свойствами Компонент Часть АС, выделенная по определенному признаку или совокупности признаков и рассматриваемая как единое целое (ГОСТ Р 59853-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения») Контракт Контракт на выполнение работ по развитию и оказанию услуг по технической поддержке Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК в 2026 году, заключаемый по результатам проведения конкурентной процедуры закупки в соответствии с требованиями Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» - - Значение характеристики не может изменяться участником закупки

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

ФГБУ «СИЦ Минтранса России» Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации», Заказчик Федеральный закон № 44-ФЗ Федеральный закон от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» ФЗ Функциональная задача ФЗ «Реестр объектов» Функциональная задача «Формирование и ведение единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации» ФСБ России Федеральная служба безопасности Российской Федерации ФСТЭК России Федеральная служба по техническому и экспортному контролю ЧС Чрезвычайная ситуация ЭВМ Электронно-вычислительная машина API От англ. Application Programming Interface – интерфейс прикладного программирования – совокупность инструментов и функций в виде интерфейса для взаимодействия с программой CSS От англ. Cascading Style Sheets — каскадные таблицы стилей FPS От англ. frame per second - количество кадров в секунду HTML От англ. HyperText Markup Language - стандартный язык разметки документов, создающий основу и структуру всех веб-страниц JSON От англ. JavaScript Object Notation – текстовый формат обмена данными, основанный на JavaScript WebAssembly (Wasm) Открытый стандарт, представляющий собой низкоуровневый бинарный формат инструкций, который позволяет выполнять код, написанный на языках C++, Rust или Go, в браузерах с производительностью, близкой к нативной

1. ОБЩИЕ СВЕДЕНИЯ - 1.1. Наименование Системы Полное наименование системы: Информационно-аналитическая система регулирования на транспорте. Условное обозначение системы: АСУ ТК. Полное наименование модуля: Модуль сбора, ведения и анализа информации о нештатных ситуациях на транспорте. Условное обозначение модуля: Модуль СЦ. Модуль СЦ создан в рамках контракта от 05.08.2024 № ОК/24_04 на выполнение работ по развитию АСУ ТК в части создания модуля «Сбора, ведения и анализа информации о нештатных ситуациях на транспорте». Развитие Модуля СЦ осуществлено в рамках контракта от 19.05.2025 № ОК/25_09 на выполнение работ по развитию Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК - - Значение характеристики не может изменяться участником закупки

1.2. Шифр темы или номер контракта Присваивается Заказчиком по результатам организации закупочных процедур. 1.2.1. Предмет контракта Выполнение работ по развитию Модуля СЦ. Код по ОКПД2: 62.01.11.000 – услуги по проектированию и разработке информационных технологий для прикладных задач и тестированию программного обеспечения. Оказание услуг по технической поддержке Модуля СЦ. Код по ОКПД2: 62.02.30.000 – услуги по технической поддержке информационных технологий. Выполнение работ по развитию Модуля СЦ предусмотрено с учетом ключевых результатов (ОКР) Ведомственной программы цифровой трансформации Минтранса России на 2026-2028 (далее - ВПЦТ Минтранса России) в составе мероприятия № 103.002 «АСУ ТК» ИТ расхода 103.26.000005 «Развитие Информационно-аналитической системы регулирования на транспорте (АСУ ТК)»: · «Обеспечено информационное взаимодействие с Минобороны о происшествиях на транспортных объектах»; · «Обеспечена автоматизация формирования отчетов о нештатных ситуациях на транспорте, в том числе по данным внешних систем». Выполнение работ по технической поддержке АСУ ТК предусмотрено ВПЦТ Минтранса России в составе мероприятия № 103.002 «АСУ ТК» ИТ расхода 103.26.000021 «Эксплуатация Информационно-аналитической системы регулирования на транспорте (АСУ ТК)»

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

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

1.5. Основания для выполнения работ Работы осуществляются на основании следующих документов: – постановление Правительства Российской Федерации от 30.12.2003 № 794 «О единой государственной системе предупреждения и ликвидации чрезвычайных ситуаций»; – постановление Правительства Российской Федерации от 08.11.2013 № 1007 «О силах и средствах единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций»; – распоряжение Правительства Российской Федерации от 27.11.2021 № 3363-р «О Транспортной стратегии Российской Федерации до 2030 года с прогнозом на период до 2035 года»; – Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 26.08.2025 №ЕФ-3; – Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 27.11.2025 №ЕФ-23;

– Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 19.02.2026 №ЕФ-1; – План мероприятий по профилактике случаев непроизводственного травматизма граждан на железнодорожном транспорте, являющийся приложением к постановлению коллегии Министерства транспорта Российской Федерации от 11.03.2026 № 2

1.6. Перечень документов, требования которых должны быть учтены при выполнении работ – Федеральный закон Российской Федерации от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации»; – Федеральный закон Российской Федерации от 27.07.2006 № 152-ФЗ «О персональных данных»; – Федеральный закон Российской Федерации от 06.04.2011 № 63-ФЗ «Об электронной подписи»; – Федеральный закон Российской Федерации от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации»; – Указ Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации»; – Указ Президента Российской Федерации от 01.05.2022 № 250 «О дополнительных мерах по обеспечению информационной безопасности Российской Федерации»; – Указ Президента Российской Федерации от 31.03.2010 № 403 «О создании комплексной системы обеспечения безопасности населения на транспорте»; – постановление Правительства Российской Федерации от 30.07.2004 № 395 «Об утверждении Положения о Министерстве транспорта Российской Федерации»; – постановление Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации»; – постановление Правительства Российской Федерации от 16.11.2015 № 1236 «Об установлении запрета на допуск программного обеспечения, происходящего из иностранных государств, для целей осуществления закупок для обеспечения государственных и муниципальных нужд»; – постановление Правительства Российской Федерации от 23.12.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 Федерального закона «Об электронной подписи»;

– постановление Правительства Российской Федерации от 08.06.2011 № 451 «Об инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг и исполнения государственных и муниципальных функций в электронной форме»; – постановление Правительства Российской Федерации от 30.01.2013 № 62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин»; – приказ ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации»; – приказ ФСТЭК России от 11.04.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений»; – приказ ФСБ России от 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.7. Сроки начала и окончания работ Начало работ: с даты заключения Контракта. Окончание работ: не позднее 15.12.2026. Работы выполняются в соответствии с этапами. Сроки выполнения этапов работ по развитию и технической поддержке Модуля СЦ определяются Календарным планом. Календарный план, приведен в разделе 5 настоящего ТЗ

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

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

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

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

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

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

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

3. ХАРАКТЕРИСТИКА ОБЪЕКТА АВТОМАТИЗАЦИИ - 17 Модуль ГЭТ Модуль предназначен для получения, хранения данных инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по отдельно взятому предприятию-перевозчику. Формирования отчетов об инвентаризации с детальными данными по каждому разделу инвентаризации с маршрутизацией в муниципалитет / регион / Минтранс. Содержит агрегированные данные инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по всем перевозчикам, относящихся к данному муниципалитету. Формирует сводный отчет по муниципалитету по каждому разделу инвентаризации с маршрутизацией в регион / Минтранс. Формирует агрегированные данные инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по всем перевозчикам, относящиеся к данному региону и по всем муниципалитетам, относящимся к данному региону. Аналитические и статистические данные о состоянии ГЭТ региона. Содержит данные о видах транспорта, цифровых транспортных сервисах и платежных инструментах Региона. Формирует сводный отчет по каждому разделу инвентаризации с маршрутизацией в Минтранс. Формирует агрегированную статистику и аналитику по всем регионам страны в разрезе транспортных средств, маршрутов, пассажиропотоков, инфраструктуры ГЭТ. Данные о рейтинге регионов и перевозчиков на основании выбранных параметров, документооборот с участниками Системы: получение подписанных печатных форм, их утверждение, возврат на доработку. 18 Модуль iМинтранс Модуль создан для отчета по ключевым показателям транспортного комплекса России (Отраслевые и статистические показатели, исполнение бюджета, исполнение поручений, аналитика СМИ, происшествия по видам транспорта). 19 Модуль СЦ Модуль СЦ предназначен для оперативного мониторинга нештатных ситуаций транспортной отрасли, оповещения заинтересованных лиц и структур и предоставления данных о нештатных ситуациях - - Значение характеристики не может изменяться участником закупки

АСУ ТК осуществляет идентификацию и авторизацию посредством Единой системы идентификации и аутентификации (ЕСИА). Информационный обмен с внешними информационными системами осуществляется посредством СМЭВ 3 и СМЭВ 4. АСУ ТК развернута на вычислительных мощностях ГЦОД СИЦ Минтранса России

3.2. Описание и текущее состояние объекта автоматизации Модуля СЦ Объектом автоматизации является процесс организации мониторинга информации о НС и ЧС на транспорте. Предметом деятельности Учреждения являются следующие функции: – информационное обеспечение в области транспортной безопасности, защиты населения и территорий от чрезвычайных ситуаций природного и техногенного характера в транспортном комплексе; – подготовка справочных материалов при угрозе возникновения и возникновении чрезвычайных ситуаций и иных происшествий в транспортном комплексе; – взаимодействие и обмен оперативной информацией с органами управления Единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций; – организация оперативного мониторинга обстановки на объектах транспорта при угрозе и возникновении чрезвычайных ситуаций и иных происшествий. Перечень компонентов Модуля СЦ и выполняемые ими функции представлены в Таблице 2

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

3 Информирование – ведение справочника способов оповещения (веб-интерфейс, мессенджер); – формирование сценария выполнения оповещения (настройка условий, способа, параметров оповещения); – выполнение оповещений пользователей 4 Отчетность – формирование отчета и справки о событиях; – фильтрация событий для выгрузки в справку о событиях или в отчет о событиях 5 Администрирование – ведение ролей пользователей; – ведение учетных данных пользователей; – ведение справочника организаций; – ведение справочника групп системы мгновенного обмена сообщениями; – выполнение исходящего звонка на контактный телефонный номер организации; – формирование матрицы эскалации событий Архитектура Модуля СЦ представлена на рисунке 1. Рисунок 1. Архитектура Модуля СЦ

3.3. Состав используемого ПО Модуля СЦ Программная архитектура Модуля СЦ разработана как трехуровневая клиент-серверная архитектура. Архитектура включает в себя следующие уровни: • уровень представления – презентационный уровень, обеспечивающий взаимодействие с пользователя с клиентскими приложениями с использованием веб-браузера («тонкий» клиент); • уровень приложений – реализован в виде сервисов, обеспечивает обработку запросов, поступающих от клиентских приложений, формирование ответов на запрос в доступном пользователю виде (формирование пользовательских интерфейсов); • уровень хранения данных – реализуется как сервер БД и обеспечивает хранение и целостность хранимых данных, создание резервных копий, ведение журнала транзакций, восстановление данных после сбоев. Программная архитектура Модуля СЦ включает в себя сервисы и интерфейсы, указанные в Таблице 3. Таблица 3. Программная архитектура Модуля СЦ Программный сервис/интерфейс Технологии реализации Уровень представления Интерфейс пользователя и администратора (front-end) Javascript Уровень приложений Сервис (GateWay) Kotlin Сервис геокодирования (geocoding-service) Kotlin Сервис уведомлений (notifiсation-service) Kotlin Сервис работы с файлами (file-service) Kotlin Сервис отчетности (report-service) Kotlin Сервис управления событиями (event-service) Kotlin Сервис информирования через мессенджер (messenger-notifier) Python Сервис внешних интеграций (integration-service) Сбор информации из внешних систем и сервисов Брокер сообщений Kafka Уровень хранения данных Файловое хранилище MinIO S3 СУБД Postgres Pro Enterprise

3.4. Информационное взаимодействие программных сервисов и интерфейсов Модуля СЦ Объект автоматизации функционирует в распределенной информационной среде. Обмен данными осуществляется по защищенным каналам связи (в том числе ведомственным сетям передачи данных). Источники информации включают: · внешние автоматизированные системы (органов государственной власти); · внутренние базы данных (реестры объектов транспортной инфраструктуры, паспорта регионов и пр.); · оперативная информация от персонала, поступающая через автоматизированные рабочие места (АРМ) и мобильные устройства. 3.4.1. Взаимодействие Модуля СЦ со смежными подсистемами АСУ ТК Модуль СЦ входит в состав АСУ ТК и взаимодействует со следующими ее функциональными задачами и подсистемами: · Функциональной задачей «Формирование и ведение единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации» (ФЗ «Реестр объектов»); · Геоинформационной подсистемой АСУ ТК (П-ГИС); · Подсистемой ведения нормативно-справочной информации и метаданных (П-НСИ); · Подсистемой сбора данных и централизованное хранилище данных (П-СД); · Подсистемой информационного взаимодействия (П-ИВ). 3.4.2. Взаимодействие с внешними информационными системами Список внешних информационных систем, с которыми осуществляется взаимодействие Модуля СЦ: · ЕСИА; · мессенджер; · Яндекс Геокодер; · Информационная система «Централизованная система сбора информации систем-112»; · ПВК «Поиск-Море», АИС РПТ; · облачная АТС

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

3.1. Описание объекта автоматизации АСУ ТК Объектом автоматизации являются процессы основной и обеспечивающей деятельности, направленные на управление транспортным комплексом, в том числе, процессы информационного взаимодействия с другими организациями и субъектами транспортного комплекса. АСУ ТК относится к государственным информационным системам, а также к информационным системам персональных данных и значимым объектам критической информационной инфраструктуры Российской Федерации. АСУ ТК соответствует требованиям, предъявляемым к: – ГИС второго класса защищенности в соответствии с приказом ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах»; – ИС персональных данных при обеспечении третьего уровня защищенности персональных данных в соответствии с требованиями постановления Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»; – значимым объектам КИИ Российской Федерации второй категории значимости с постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении Правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений». Модуль СЦ является подсистемой АСУ ТК. Перечень платформенных решений и функциональных задач АСУ ТК представлен в Таблице 1

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

8 Подсистема проектного архива АСУ ТК Подсистема проектного архива АСУ ТК предназначена для автоматизации деловых процессов должностных лиц Министерства транспорта Российской Федерации, подведомственных агентств и службы, в том числе, и процессов информационного взаимодействия внутреннего и внешнего характера 9 ФЗ «Реестр объектов» Функциональная задача предназначена для формирования и ведения единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации 10 ФЗ «СТП» Функциональная задача предназначена для организации информационно-аналитической поддержки процессов территориального планирования Российской Федерации в области федерального транспорта 11 ФЗ «МРТБ ПП» Функциональная задача предназначена для формирования и ведения межрегионального транспортного баланса пассажирских перевозок в дальнем (межрегиональном) сообщении 12 ФЗ «МДД» Функциональная задача предназначена для осуществления мониторинга дорожного движения 13 ФЗ «ТПР» Функциональная задача предназначена для формирования и ведения транспортного паспорта региона 14 ФЗ «Данные по грузообороту» Функциональная задача предназначена для обеспечения подсистем и пользователей АСУ ТК данными по грузообороту между Российской Федерацией и зарубежными странами 15 ФЗ «МЖТ» Функциональная задача предназначена для осуществления мониторинга железнодорожного транспорта 16 ФЗ «МГМП» Функциональная задача предназначена для осуществления мониторинга грузопотоков в морских портах с целью формирования единой цифровой среды мониторинга и планирования перевозок в/из портов Дальнего Востока

4. ТРЕБОВАНИЯ К МОДУЛЮ СЦ - 4.3.6.4.1. Требования к проведению изменений Основанием для внесения изменений является запрос от Заказчика. Все активности по внесению изменений должны быть согласованы с Заказчиком, а действия Подрядчика при оказании данной услуги должны быть зафиксированы. В рамках данного Технического задания изменениями считаются локальные доработки функционала Модуля СЦ, которые не должны приводить к необходимости выполнения дополнительных аттестационных испытаний или переаттестации АСУ ТК в соответствии с п. 33 приказа от 29.04.2021 № 77 «Об утверждении Порядка организации и проведения работ по аттестации объектов информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну». При необходимости внесения изменений в Модуль СЦ, не связанных с критичным инцидентом, существенно нарушающим работоспособность Модуля СЦ, Заказчик направляет Подрядчику обращение (заявку), в котором излагает суть изменения, которое требуется внести в Модуль СЦ. Исполнитель, в течение 3 (трех) рабочих дней с момента поступления соответствующего обращения (заявки), оценивает техническую возможность реализации запрашиваемого изменения и варианты реализации. По итогу проведения оценки Подрядчик направляет Заказчику заключение о возможности реализации данного изменения с описанием возможных вариантов реализации и согласует с Заказчиком проведение данного изменения - - Значение характеристики не может изменяться участником закупки

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

4.3.6.4.2. Требования к изменению настроек функционирования Изменение настроек функционирования может проводиться в рамках допустимых пределов изменения функционирования, заложенных в архитектуру Модуля СЦ. Изменение настроек функционирования включает в себя изменение данных и справочников, изменение форм документов, формируемых Модулем СЦ, изменение и настройку форматов и версий передачи данных в смежные системы. Доработка программного кода Модуля СЦ может допускаться (в случае необходимости) при выполнении работ по адаптации функций Модуля СЦ в части изменения формата передачи данных в смежные информационные системы при условии соблюдения требований пункта 29.3 приказа ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации»

4.3.6.5. Требования к услугам по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности По запросу Заказчика Подрядчик должен провести работу по приведению ППО в соответствие с требованиями по обеспечению информационной безопасности. Критичность уязвимости оценивается в соответствии в соответствии с Методическим документом ФСТЭК России «Методика оценки уровня критичности уязвимостей программных, программно-аппаратных средств» (утвержден ФСТЭК России 30.06.2025), а также с учетом ГОСТ 56545-2015 и международными стандартами (CVSS 3.0 и выше), и задает необходимый срок устранения. В процессе проведения Заказчиком обследования Модуля СЦ и выявления уязвимостей в ППО, связанных с исходным кодом Модуля СЦ и/или используемыми компонентами (библиотеками), Заказчик направляет Подрядчику обращение (заявку) на устранение, с указанием критичности и срочности принятия мер по устранению в СРО.

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

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

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

4.4. Требования к видам обеспечения 4.4.1. Требования к лингвистическому обеспечению Документация на Модуль СЦ должна разрабатываться на русском языке. Взаимодействие пользователей с Модулем СЦ посредством графического интерфейса должно происходить на русском языке за исключением сообщений, зависящих от настроек системного программного обеспечения, установленного на рабочих местах пользователей. При разработке программных решений Модуля СЦ должно быть предусмотрено использование языков программирования высокого уровня, приведенных в Таблице 7. Таблица 7. Языки и средства разработки, специального программного обеспечения Модуля СЦ Категория Наименование Назначение Языки программирования Kotlin Разработка серверной логики и сервисов (backend) JavaScript / TypeScript Разработка клиентской части (frontend) Python Разработка скриптов интеграции, обработки данных и автоматизации Фреймворки и библиотеки Vue.JS Разработка пользовательских интерфейсов (веб-интерфейсы компонентов визуализации и отчетности) React Разработка пользовательских интерфейсов (при необходимости создания сложных интерактивных компонентов) Решения по лингвистическому обеспечению, включая перечень используемых языков программирования, должны быть согласованы с Заказчиком на этапе технического проектирования

4.4.2. Требования к математическому обеспечению Требования к математическому обеспечению не предъявляются. 4.4.3. Требования к метрологическому обеспечению Требования к метрологическому обеспечению не предъявляются. 4.4.4. Требования к организационному обеспечению Требования к организационному обеспечению не предъявляются. 4.4.5. Требования к методическому обеспечению Задачи методического обеспечения Модуля СЦ должны быть обеспечены за счет использования технологических и методических документов касающихся вопросов функционирования транспортного комплекса и разработки и эксплуатации ПО. 4.4.6. Требования к информационному обеспечению Состав, структура и способы организации информационного обеспечения в Модуле СЦ должны быть определены на этапе технического проектирования. Факты информационного обмена с внешними системами должны фиксироваться в соответствующем журнале

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

4.5.3. Требования по диагностированию Модуля СЦ Диагностирование Модуля СЦ должно осуществляться путем анализа записей в системных журналах СУБД, операционных систем серверов, а также с помощью встроенных средств диагностирования общего программного обеспечения Модуля СЦ. Диагностированию подлежат: – сбои и нарушения функционирования технического обеспечения (серверов) Модуля СЦ; – сбои и нарушения функционирования системного программного обеспечения серверов, используемых для работы Модуля СЦ; – сбои и нарушения функционирования прикладного программного обеспечения серверов, используемых для работы Модуля СЦ; – случаи недоступности (отсутствия ответа) или некорректные ответы внешних систем; – сбои и нарушения функционирования СУБД; – сбои при выполнении регламентных операций резервного копирования. При возникновении аварийных ситуаций либо ошибок в программном обеспечении диагностические инструменты должны позволять сохранять набор информации, необходимой для идентификации и устранения проблемы. Модуль СЦ и ее компоненты должны обеспечивать возможность диагностики своей работоспособности с возможностью интеграции с модулем мониторинга АСУ ТК. Набор передаваемых журналов и метрик должен быть определен на этапе технического проектирования

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

4.1. Требования к структуре Модуля СЦ В процессе работ по развитию Системы должны сохраниться основные требования к построению архитектуры Системы в соответствии с принципами трехуровневой архитектуры: 1. уровень хранения данных или уровень базы данных (сервер СУБД); 2. уровень сервера приложений (сервер аналитической обработки); 3. презентационный уровень, обеспечивающий взаимодействие с клиентскими приложениями. В состав Системы должны входить следующие основные компоненты: 4. сервер баз данных; 5. сервер приложений; 6. веб-сервер. Сервер баз данных должен обеспечивать хранение и целостность хранимых данных, создание резервных копий, ведение журнала транзакций, восстановление данных после сбоев. Сервер приложений должен обеспечивать обработку запросов, поступающих от клиентских приложений (через веб-сервер), формирование ответов на запрос в доступном пользователю виде (формирование пользовательских интерфейсов). Веб-сервер должен обеспечивать взаимодействие с оператором и внешними системами по HTTP / HTTPS протоколу в режиме «запрос-ответ» (получения запросов от пользователя и передачи ответа в виде соответствующей информации, обработанной серверами приложений). Взаимодействие Системы с пользователем должно отвечать требованиям модели «тонкого клиента» (т.е. представлять на стороне клиента (пользователя) лишь графический пользовательский интерфейс). Все составляющие Системы должны использовать единую методологию и отвечать единым принципам взаимодействия, надежности и управления. Перечень компонентов Модуля СЦ представлен в Таблице 4. Таблица 4. Перечень компонентов Модуля СЦ, в отношении которых выполняются работы по развитию № п.п. Наименование компонента Модуля СЦ Раздел ТЗ 1 Компонент регистрации событий 4.2.1. 2 Компонент отчетности 4.2.2 3 Компонент визуализации 4.2.3 4 «Интерактивная карта» (компонент создается) 4.2.4 5 Компонент администрирования 4.2.5

4.2. Требования к дорабатываемым функциям модуля СЦ 4.2.1. Развитие компонента регистрации событий (1 очередь) Должны быть выполнены следующие доработки: – обеспечение логирования действий пользователя, связанных с карточкой события; – доработка объектной модели в части создания новых типов сущностей (карточек) с учетом реализуемых интеграций с информационными ресурсами (силы и средства предупреждения и ликвидации ЧС и нештатных ситуаций на транспорте, ТС, ограничения воздушного пространства, неблагоприятные и опасные природные явления); – реализация механизма установления связи между сущностями в Модуле СЦ автоматизированным и ручным способами (события, природные явления, силы и средства предупреждения и ликвидации ЧС и нештатных ситуаций на транспорте, ограничения воздушного пространства, ОТИ, ТС и др.); – отображение в карточке установленных связей между сущностями.

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

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

4.4.7.1. Требования к инструментам разработки и процессу контроля версий программного обеспечения 4.4.7.1.1. Система контроля версий Для управления исходным кодом должна использоваться система контроля версий кода, развернутая в инфраструктуре Заказчика. 4.4.7.1.2. Правила именования веток Имя ветки должно соответствовать следующему формату: / / Категории веток: ? feature/ — разработка новой функциональности, а также рефакторинг или удаление существующей; ? fix/ — исправление ошибок; ? hotfix/ — срочные исправления, применяемые в обход стандартного процесса разработки; ? test/ — для проведения экспериментов, не влияющих на основную разработку. Идентификатор задачи: после категории указывается ссылка на задачу (issue) в системе контроля версий кода. Описание: добавляется краткое описание решаемой задачи в формате kebab-case (слова разделяются дефисами, например, add-user-auth). Примеры именования веток: ? feature/#123/add-payment-integration; ? fix/#45/correct-calculation-logic; ? hotfix/#67/urgent-database-connection-patch. 4.4.7.1.3. Правила именования коммитов Сообщение коммита должно соответствовать соглашению Conventional Commits и состоять из категории и описания: : ? fix — исправление ошибки. Примеры сообщений коммитов: ? feat: добавление формы регистрации пользователя; ? fix: исправление ошибки валидации email-адреса; ? refactor: оптимизация алгоритма сортировки данных; ? chore: обновление версий в файле dependencies. 4.4.7.1.4. Модель ветвления В процессе разработки используются следующие основные ветви: ? main / master — стабильная ветка, содержит только код, прошедший полное тестирование и развернутый в продуктивных контурах; ? dev — ветка для интеграции завершенных задач, предназначенная для сборки и тестирования в тестовых средах. Попадание кода в main осуществляется только через Merge Request (MR) из dev

4.5.5. Требования к информационной безопасности Работы по защите информации/информационной безопасности, не включенные в состав настоящего раздела, требуемые в соответствии с требованиями постановления Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации», а также нормативно правовых актов в области защиты персональных данных и обеспечения безопасности объектов критической информационной инфраструктуры, будут проведены в рамках исполнения отдельного контракта, заключенного по результатам отдельной закупочной процедуры (не является частью данного ТЗ), включающего: – определение актуальных угроз безопасности информации и актуализация модели угроз безопасности информации (при необходимости); – выполнение требований о согласовании технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России в установленном порядке; – выполнение требований по устранению Подрядчиком замечаний и недостатков, в случае их выявления при согласовании Заказчиком технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России; – выполнение требований к классу защищенности ГИС, уровню защищенности персональных данных и категории значимости объекта КИИ РФ, установленных для Головного центра обработки данных ФГБУ «СИЦ Минтранса России» (далее – ГЦОД);

– определение перечня объектов защиты информационной системы; – описание (актуализированных) требований к системе защиты информации, а также к мерам защиты информации информационной системы в зависимости от установленных классов защищенности, уровня защищенности персональных данных и категории значимости объектов КИИ РФ (приказы ФСТЭК России № 21, 117, 239); – выполнение требований к мерам по защите ГИС от атак, направленных на отказ в обслуживании, в соответствии с пунктами 30, 34, 59, 63 Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений, утвержденных приказом ФСТЭК России от 11.04.2025 № 117; – описание (актуализированных) требований по защите информации, подлежащих реализации в информационно телекоммуникационной инфраструктуре ГЦОД; – выполнение требований о применении сертифицированных средств защиты информации, включая их классы защиты и уровни доверия; – выполнение требований о запрете использования с 01.01.2025 органами (организациями) средств защиты информации странами происхождения, которых являются иностранные государства в соответствии с пунктом 6 Указа Президента Российской Федерации от 01.05.2022 № 250; – выполнение требований по обеспечению непрерывного взаимодействия с ГосСОПКА в установленном порядке;

4.2.2. Развитие компонента отчетности (3 очередь) Должна быть обеспечена автоматизация процессов формирования отчетов о ЧС и нештатных ситуациях на транспорте, в т.ч. на основе данных из внешних систем. Включает следующие доработки: – разработка шаблонов отчетов в различных форматах (табличный, текстовый); – реализация выбора фотоматериалов для включения в справку; – форматирование содержимого справок с учетом правил русского языка в отношении окончаний слов (в зависимости от падежа, склонения, числа и рода); – автоматизированное формирование выводов к содержимому справки на основе настраиваемых критериев; – создание интерфейса выбора параметров (фильтрации) для формирования отчетов: o состав полей для включения в отчёт; o настройка диапазонов значений характеристик и дат; o порядок отображения полей; o настройка заголовка. – реализация способа подготовки отчётов в асинхронном режиме (очереди); – реализация интерфейса компонента формирования отчетности для отображения очереди формирования отчетов и статусов их подготовки; – экспорт отчётов в форматы xlsx, csv и справок в форматы pdf, docx. Необходимо разработать не менее 10 шаблонов отчетов и/или справок. Перечень, структура и содержание шаблонов должны быть согласованы с Заказчиком на этапе технического проектирования.

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

– отображение на карте связанных сущностей и ОТИ; – реализация функции выбора темного и светлого стилей отображения элементов интерфейса, карточек сущностей, картографической основы и объектов, отображаемых на карте; – реализация механизма для выбора картографической основы в одном из распространенных форматов WMTS, TMS, MVT и др. Должна быть предусмотрена возможность настройки перечня картографических основ и параметров доступа к ним; – настройка базового набора дашбордов, содержащих преднастроенные виджеты о количестве событий в разрезе видов транспорта с возможностью перехода к исходным данным (карточкам событий, ОТИ и т.д.), с фильтрацией по параметрам. Параметры фильтрации должны быть определены на этапе технического проектирования. Должно быть обеспечено автоматическое и принудительное обновление данных, отображаемых на дашбордах

4.4.7.1.5. Требования к используемым зависимостям (библиотекам) Все внешние зависимости проекта должны быть зафиксированы с указанием точных версий. Для контроля версий зависимостей в репозиторий обязательно должны быть включены следующие файлы: · Для JavaScript: package-lock.json или yarn.lock; · Для Python: requirements.txt (с зафиксированными версиями) или Pipfile.lock; · Для Go: go.mod и go.sum; Загрузка всех зависимостей должна производиться исключительно через внутренний прокси-репозиторий Заказчика, настроенный в соответствующем системе менеджере пакетов. Запрещается: · Использование плавающих версий (например, ^1.2.3, ~4.5.0, latest); · Использование библиотек, содержащих критические уязвимости, в том числе зарегистрированные в реестре CVE (Common Vulnerabilities and Exposures). 4.4.7.1.6. Требования к процессу непрерывной интеграции (CI) Сборка программного обеспечения, включая этапы компиляции, тестирования и анализа кода, должна выполняться исключительно в инфраструктуре непрерывной интеграции Заказчика. 4.4.7.1.7. Требования к хранению артефактов сборки Все артефакты сборки (результирующие пакеты, Docker-образы и т.д.) подлежат обязательному хранению в предназначенной для этого инфраструктуре Заказчика (артефакторий). Запрещается размещение финальных артефактов сборки на сторонних ресурсах

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

4.5. Общие технические требования 4.5.1. Требования к численности и квалификации персонала и пользователей Модуля СЦ Программное обеспечение Модуля СЦ не должно требовать изменения штатной численности персонала Заказчика. Программное обеспечение Модуля СЦ не должно требовать наличия у пользователей дополнительной квалификации в сфере информационных технологий, кроме базовых знаний в обращении с персональным компьютером, базовых навыков работы в интернет-обозревателях и знаний о Модуле СЦ в объеме документов Руководство пользователя, Руководство администратора

– выполнение требований по обеспечению в автоматизированном режиме с Национальной системой противодействия DDoS-атакам (НСПА) Центра мониторинга и управления сетью связи общего пользования ФГУП «ГРЧЦ» в рамках реализации мер по защите ГИС от атак, направленных на отказ в обслуживании; – детализированные требования к составу и содержанию работ по аттестации, а также к их результатам в соответствии с пунктами 13, 15 и 16 требований приказа ФСТЭК России от 29.04.2021 № 77 «Об утверждении Порядка организации и проведения работ по аттестации объектов информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну»

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

Подрядчик должен обеспечить реализацию и проведение внутренних проверок мер по разработке безопасного ПО, приведенных в Руководстве. Подрядчик должен провести анализ угроз безопасности информации программного обеспечения в соответствии с ГОСТ 58412-2019 «Защита информации. Разработка безопасного программного обеспечения. Угрозы безопасности информации при разработке программного обеспечения». Подрядчик должен провести испытания по выявлению уязвимостей в программном обеспечении Системы: · проведение статического анализа исходного кода программы; · проведение динамического анализа исходного кода программы; · проведение композитного анализа исходного кода и образов программы; · проведение фаззинг-тестирования программы, направленного на выявление в ней уязвимостей. Испытания по выявлению уязвимостей в программном обеспечении Системы должны быть проведены в рамках: · предварительных испытаний; · опытной эксплуатации; · приемочных испытаний

4.2.4. Создание компонента «Интерактивная карта» (2 очередь) В составе создаваемого компонента должны отображаться данные, доступные в компоненте визуализации. Требования к интерфейсу интерактивной карты: – интерактивная карта должна быть представлена в виде объемной карты с учетом макетов, представленных в Приложении А к ТЗ; – интерфейс должен корректно отображаться на экранах мониторов (разрешение Full HD 1920?1080), телевизоров (разрешение 4К 3840?2160), жидкокристаллических панелей для видеостены, используемой Заказчиком, с параметрами каждой панели: диагональ 55 дюймов, разрешение 1920x1080; – интерфейс должен корректно отображаться на планшетных устройствах с диагональю экрана 10-12 дюймов, конкретные требования должны быть уточнены на этапе технического проектирования; – должна быть обеспечена кластеризация и генерализация отображения объектов на карте при изменении масштаба; – должно быть обеспечено отображение основных характеристик объектов при выборе их на карте; – должно быть обеспечено управление отображением слоев на карте; – должна быть обеспечена настройка цветовой индикации отображаемых объектов транспортной инфраструктуры; – должно быть обеспечено отображение легенды карты, содержащей отображаемые объекты на карте; – должна быть обеспечена возможность одновременного отображения не менее 5 000 ОТИ и ТС на карте.

На интерактивной карте должны быть отображены подвижные объекты совместно с объектами транспортной инфраструктуры (ОТИ), включая следующие возможности: § отображение местоположения транспортных средств (воздушный, водный и автомобильный транспорт) на карте в режиме реального времени (с заданным периодом обновления данных); § отображение маршрутов движения всех ТС за выбранный период времени, в том числе с использованием эффектов анимации; § отображение маршрутов движения ТС, связанных с карточкой события: ТС, являющихся участниками события, и ТС, находящиеся в заданном радиусе от события; § управление отображением сущностей и ОТИ на карте, включая настройку состава отображаемых объектов, поиск, фильтрацию, с использованием соответствующей панели управления и наглядным представлением результатов; § автоматическое изменение вида отображения объектов (цветовая индикация) по заданным условиям (например, при достижении критических значений параметров, характеризующих функционирование объекта); Должна обеспечиваться производительность обновления изображения на экране в 30 кадров в секунду на тестовой конфигурации пользовательского устройства (модель Бештау AIO2402/B560, входящая в Реестр российской промышленной продукции под номером 10394100 или аналог) при одновременном отображении не менее 5 000 объектов и 200 уникальных моделей объектов. Макеты интерфейсов Модуля СЦ должны быть предварительно согласованы с Заказчиком и разработаны с учетом требований ГОСТ Р ИСО 9241-161-2016 «Элементы графического пользовательского интерфейса»

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

В аварийном режиме осуществляется поиск неисправностей и проведение работ по их устранению. Перевод в аварийный режим должен осуществляться при возникновении сбоев, аварий и прочих незапланированных воздействий, сразу после наступления одной или нескольких аварийных ситуаций, с последующим возвратом в штатный режим функционирования сразу после окончания восстановительных работ. ПО Модуля СЦ должно обладать надежностью, обеспечивающей работу пользователей в произвольном режиме и оперативное восстановление работоспособности при сбоях. В целях обеспечения надежного функционирования ПО должно предусматривать: – сохранение целостности данных при нештатном завершении работы компонентов Модуля СЦ; – сохранение работоспособности программного обеспечения при некорректных действиях пользователя; – резервное копирование базы данных Модуля СЦ. – время восстановления работоспособности Модуля СЦ после отказа не более 4 часов. – отказоустойчивость на уровне 99% при единовременной количестве не менее 200 пользовательских сессий в Модуле СЦ. Указанные характеристики приведены без учета характеристик надежности инфраструктуры и времени передачи информации по каналам связи. При возникновении сбоев в аппаратном обеспечении, включая аварийное отключение электропитания, Модуль СЦ должен автоматически восстанавливать свою работоспособность (не требовать перенастройки) после устранения сбоев и корректного перезапуска аппаратного обеспечения

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

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

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

4.2.4.1. Требования к технической реализации компонента «Интерактивная карта» При реализации компонента «Интерактивная карта» должны учитываться требования, указанные ниже. 4.2.4.1.1. Требования к отображению элементов Повторяющихся элементы карты (ТС, ОТИ, события и пр.) должны отрисовываться с использованием аппаратного создания экземпляров объектов на пользовательском устройстве (WebGL/WebGPU)). Отрисовка каждого объекта отдельным запросом не допускается, должна обеспечиваться возможность одновременного отображения не менее 5 000 объектов без снижения производительности (30 кадров в секунду на тестовой конфигурации). 4.2.4.1.2. Уровни детализации объектов Для управления отображением сложных объектов должно быть создано не менее 3-х уровней детализации, отображаемых при изменении масштаба с возможностью автоматического переключения между уровнями. Все отображаемые объекты должны масштабироваться с учетом разрешения экрана пользователя с сохранением качества детализации. 4.2.4.1.3. Полигональная оптимизация и текстурирование При реализации компонента «Интерактивная карта» должна обеспечиваться технология рельефного тестурирования объектов. Не должны использоваться высокополигональные трехмерные модели. Все повторяющиеся элементы должны генерироваться единоразово и повторно использоваться при последующих отображениях. 4.2.4.1.4. Управление памятью Требуется реализовать потоковую загрузку на устройство пользователя элементов карты и текстур. Загрузка данных целиком при старте приложения не допускается. Необходимо реализовать механизм очистки памяти от элементов, которые находятся вне области видимости камеры в течение заданного времени. 4.2.4.1.5. Требования к взаимодействию пользователя с интерфейсом компонента «Интерактивная карта» Программная реализация механизмов управление камерой (масштабирование и навигация) должна быть выполнена с поддержкой технологии WebAssembly (WASM). Элементы управления должны являться неотъемлемой частью интерактивной карты.

4.2.5. Развитие компонента администрирования (3 очередь) Должна быть выполнена доработка ролевой модели. Ролевая модель должна обеспечивать управление доступом к отдельным объектам Модуля СЦ и их элементам (атрибутам) с разграничением по видам транспорта, регионам и пр., в частности: – определение набора конкретных действий, доступных пользователям (выполняемых над объектом доступа, например, удаление записи, редактирование записи, формирование отчета и др.); – реализация возможности объединения пользователей в группы; – определение прав доступа для групп пользователей; – реализация интерфейса визуальной настройки прав доступа пользователей к объектам Модуля СЦ

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

4.5.8. Требования к защите от влияния внешних воздействий Требования к защите от влияния внешних воздействий не предъявляются

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

4.2.6. Взаимосвязи с внешними автоматизированными системами (1 очередь) Способы взаимодействия с внешними информационными системами должны быть определены на этапе технического проектирования. Должны быть выполнены следующие доработки: – интеграции с информационными ресурсами в целях получения данных о движении подвижных ТС (воздушные суда, суда водного транспорта); – интеграция с информационным ресурсом в целях получения данных о событиях на железнодорожном транспорте. Реализация интеграций должна включать проектирование и реализацию интеграционных механизмов обмена данными с учетом доступных вариантов реализации, обеспечение защищенных способов взаимодействия, настройку отображения отдельных данных на карте (настройка слоев). Взаимодействия, имеющие каналы связи, выходящие за пределы контролируемой зоны взаимодействующих систем, считаются защищенными, если для их защиты используются программные и/или программно-аппаратные шифровальные (криптографические) средства, сертифицированные ФСБ России (далее – СКЗИ). Выбор СКЗИ, схемы подключения и требуемого класса криптостойкости должен производиться в соответствии с Техническими условиями на подключение к информационным ресурсам ФГБУ «СИЦ Минтранса России» и инструкциями по подключению пользователей к ресурсам инфраструктуры Головного центра обработки данных, утвержденных приказом директора ФБГУ «СИЦ Минтранса России» от 24.05.2024 № 21-ОД

4.3. Требования к оказанию услуг по технической поддержке Модуля СЦ 4.3.1. Общие требования к оказанию Услуг Техническая поддержка Модуля СЦ должна осуществляться с учетом требований постановления Правительства Российской Федерации от 06.07.2015 N 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации». Подрядчик обязан выполнять требования законодательства в сфере защиты информации, требования по защите информации, информационной безопасности, указанные в локальных нормативных актах ФГБУ «СИЦ Минтранса России», регламентирующих условия информационного взаимодействия, защиты информации и подключения к информационным ресурсам ФГБУ «СИЦ Минтранса России», участвующих в информационном взаимодействии в рамках оказания услуг по технической поддержке АСУ ТК в 2026 году

4.3.1.1. Требования к составу и содержанию услуг третьего уровня технической поддержки Оказание услуг по технической поддержке Системы осуществляется в рамках этапов в соответствии с календарным планом. Подрядчик в течение 5 рабочих дней с даты заключения Контракта должен предоставить со своей стороны, а Заказчик со своей стороны Матрицу ответственных за взаимодействия в соответствии с Приложением 1 к Регламенту оказания услуг по третьему уровню технической поддержки Модуля СЦ (далее – Регламент, Приложение В). Подрядчик в течение 10 рабочих дней с даты заключения Контракта должен провести мероприятия по организации третьего уровня технической поддержки в соответствии с Регламентом. Услуги по третьему уровню технической поддержки Модуля СЦ должны включать: – организацию Подрядчиком третьего уровня технической поддержки; – информационно-консультационную поддержку работников Заказчика; – решение инцидентов, связанных с работой ППО; – адаптационное, конфигурационное и коррекционное сопровождение Модуля СЦ (в рамках действующих программных модулей и функциональности); – устранение уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности

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

Лицензионное (сублицензионное) соглашение (договор) не может возлагать на Заказчика какие-либо обязанности (в т.ч. в части конфиденциальности, предоставления отчетности), не предусмотренные Контрактом. 4.5.9.7. Передача Заказчику исключительных прав, или простых (неисключительных) прав не может повлечь увеличение стоимости Контракта и/или изменение иных существенных условий Контракта. 4.5.9.8. Функциональность Модуля СЦ передается в объеме и в сроки, установленные Техническим заданием. 4.5.9.9. Нарушение условий настоящего раздела Технического задания, в т.ч. отсутствие соответствующего лицензионного (сублицензионного) соглашения (или договора), либо предоставление лицензионного (сублицензионного) соглашения (или договора), не соответствующего требованиям действующего законодательства Российской Федерации или требованиям Контракта, является нарушением существенных условий Контракта. 4.5.9.10. В случае, если в соответствии с пунктом 4.5.9.6 Заказчику передается исключительное право, такая передача осуществляется в порядке, установленном Гражданским кодексом Российской Федерации. 4.5.9.11. В случае, если при выполнении Работ положения пунктов 4.5.9.5-4.5.9.6 не применялись, Подрядчик в составе отчетной документации предоставляет об этом декларацию в свободной форме. Декларация должна содержать сведения о полном соответствии результата Работ требованиям Контракта, а также о неприменении при выполнении работ готового программного обеспечения (платформ, подсистем, СУБД и т.д.), которое стало частью (компонентом) Системы

4.3.1.2. Требования к общему порядку оказания услуг Техническая поддержка Модуля СЦ должна быть организована на трех уровнях: – первый и второй уровни технической поддержки организуется Заказчиком; – третий уровень технической поддержки организуется Подрядчиком. Перечень действий на каждом уровне технической поддержки указан в Таблице 5: Таблица 5 – Перечень действий на каждом уровне технической поддержки Уровень технической поддержки Доступные действия Условия передачи задачи на следующий уровень Первый уровень технической поддержки (далее – 1-й уровень) – принимает обращения (заявки) пользователей Модуля СЦ и работников Заказчика; – регистрирует обращения в Модуле СЦ регистрации обращений; – присваивает уникальный идентификационный номер, классифицирует обращения; – самостоятельно решает обращения, которые связаны с недостаточной квалификацией пользователей или настройками в рамках своей компетенции; – взаимодействует с пользователями Модуля СЦ при решении проблемы Передает обращение на второй уровень поддержки в случае невозможности решения на своем уровне Второй уровень технической поддержки (далее – 2-й уровень) – принимает обращения от 1-го уровня; – уточняет классификацию обращения в результате дополнительного анализа; – самостоятельно решает обращения в рамках своей компетенции; – осуществляет техническую и консультационную поддержку Модуля СЦ; – взаимодействует с сотрудниками 1-го и 3-го уровня и пользователями Модуля СЦ; – формирует заявки для 3-го уровня и контролирует исполнение Передает обращение на третий уровень поддержки в случае невозможности решения на своем уровне Третий уровень технической поддержки (далее – 3-й уровень) – принимает обращения от 2-го уровня; – обеспечивает выполнение требований, предъявляемых Контрактом и настоящим Техническим заданием к Услугам, оказываемым Подрядчиком Все поступающие обращения должны быть исполнены Подрядчиком

Для обеспечения взаимодействия с Заказчиком Подрядчик со своей стороны определяет ответственных лиц, уполномоченных в структуре Подрядчика за своевременное и качественное оказание Услуг в рамках настоящего ТЗ, а также контактную информацию ответственных лиц (телефон, электронную почту). Подрядчик должен предоставить Заказчику единый адрес электронной почты для приема обращений (заявок) в течение 3 (трех) рабочих дней после заключения Контракта. Указанный в настоящем пункте адрес электронной почты (способ направления обращений (заявок) применяется в случае сбоя в работе СРО Заказчика. Со своей стороны, Заказчик предоставляет Подрядчику перечень и контактную информацию (телефон, электронную почту) уполномоченных лиц для осуществления взаимодействия с указанием зон ответственности. О любых изменениях в контактной информации ответственных лиц Стороны должны уведомить друг друга в течение 1 (одного) рабочего дня с момента возникновения таких изменений посредством уведомления на электронную почту ответственных лиц и/или в письменной форме. В результате оказания услуг по настоящему ТЗ не должны быть изменены исходные коды, дистрибутивы и иные компоненты Модуля СЦ вне согласованных с Заказчиком изменений. Любые изменения исходных кодов, дистрибутивов и иных компонентов Модуля СЦ должны производиться только после согласования с Заказчиком уполномоченными лицами по электронной почте или иным заранее согласованным способом. Не должна быть ухудшена надежность и производительность Модуля СЦ. Оказание услуг по Контракту не должно нарушать требования к информационной безопасности, описанной в документации на Модуль СЦ

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

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

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

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

4.5.11. Требования к показателям назначения 4.5.11.1. Требования к показателям назначения мероприятий по развитию Модуля СЦ В рамках выполнения работ по развитию Модуля СЦ, предусмотренных ТЗ, показатель назначения «Количество пользователей» должен соответствовать значениям, приведенным в данном разделе. Пояснения по показателям, связанным с количеством пользователей, приведены в Таблице 8. Таблица 8. Определения показателей, связанных с количеством пользователей в Модуле СЦ № Показатель Определение Расчетное количество пользователей Количество пользователей, работу которых должен обеспечить Модуль СЦ к моменту сдачи работ по Контракту с учетом достижения всех показателей назначения Расчетное количество одновременно работающих пользователей Количество одновременно работающих пользователей, работу которых должен обеспечивать Модуль СЦ к моменту сдачи работ по Контракту с учетом достижения всех показателей назначения Значения показателей количества пользователей, достижение которых необходимо обеспечить, представлено в Таблице 9

Таблица 9. Значения показателей количества пользователей № Показатель Значение 1. Расчетное количество пользователей 1 000 2. Расчетное среднее количество одновременно работающих пользователей 200 Развитие Модуля СЦ должно быть направлено на достижение следующего эффекта (показателя), подставленного в мероприятии 103.002 «Информационно-аналитическая система регулирования на транспорте (АСУ ТК)» ВПЦТ Минтранса России: Выполнение работ по развитию Модуля СЦ предусмотрено мероприятием по развитию АСУ ТК, приведенном в ВПЦТ Минтранса России на 2026-2028 гг: № 103.002 «АСУ ТК» в составе ИТ расхода 103.26.000005 «Развитие предусматривает реализацию ОКР и эффектов, приведенных в Таблице 10. Таблица 10. ОКР и эффекты, приведенные в ВПЦТ Минтранса России на 2026 г. № ОКР Дата ОКР Эффекты 1 Обеспечено информационное взаимодействие с Минобороны России о происшествиях на транспортных объектах 25.12.2026 Сокращено время сбора и передачи сведений для Минобороны России о ЧС и НС на транспорте с 120 до 10 минут 2 Обеспечена автоматизация формирования отчетов о нештатных ситуациях на транспорте, в том числе по данным внешних систем 25.12.2026 Сокращено время на подготовку отчетов о нештатных ситуациях на транспорте с 20 до 5 минут Реализация остальных ОКР не является предметом данного ТЗ и проводится в рамках отдельного технического задания.

4.5.11.2. Требования к показателям назначения мероприятий по эксплуатации Модуля СЦ. Работы по эксплуатации Модуля СЦ не должны обеспечивать режимы функционирования Модуля СЦ, приведенные в разделе 4.5.2 данного ТЗ

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

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

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

4.3.4. Требования к документированию результатов оказываемых услуг Для обеспечения контроля оказываемых услуг по поддержке Модуля СЦ со стороны Заказчика, по окончании каждого отчетного периода по контракту в соответствии с календарным планом, Подрядчик обязан предоставить Заказчику Отчет об оказанных услугах. Отчет должен содержать детальную информацию об оказанных услугах с указанием даты выполненных мероприятий и приложением обосновывающих документов (заявок, запросов, требований) или ссылкой на такие документы, если они содержатся в Модуле СЦ. Информация о выполненных мероприятиях по заявкам должна быть сформирована на основании соответствующих записей СРО по каждому этапу исполнения Контракта. В случае оказания услуги адаптационного, конфигурационного и коррекционного сопровождения Модуля СЦ, должны быть предоставлены документы, подтверждающие выполнение требований п. 29.3 приказа ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации». Фактическое время реагирования и время решения по всем обращениям, поступившим в СРО, формируется в СРО по итогам отчетного периода в разделе «Отчеты». Фактическое время реагирования и время решения по обращениям учитывает суммарное время, затраченное на реагирование и, соответственно, на работу по обращению с момента назначения обращения специалисту Подрядчика или группе исполнителей, ответственным за оказание услуг технической поддержки 3 уровня от начала до завершения работ Подрядчиком. При этом принимается суммарное время нахождения заявки в соответствующих статусах заявки СРО на стороне Подрядчика

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

Таблица 6. Категории обращений и заявок Категория Примеры Запрос на обслуживание Подготовка SQL запроса к СУБД для решения прикладной задачи и д.р. – запрос на любое действие, не являющееся запросом информации и несовершенный на основе происшествия, прямо или косвенно влияющего на работу Модуля СЦ Консультация «Где взять / куда обратиться...?», «Как сделать / выполнить…», «Как это работает…?» - запрос, имеющий своей целью получение информационной поддержки Инцидент Разбор ошибок/сбоев и подготовка материалов (корректировочных релизов, инструкций) для Заказчика для устранения ошибок/сбоев, которые приводят к частичному и полному нарушению работоспособности всех или отдельных функций ППО. Подготовка изменения и материалов, необходимых для проведения аварийно-восстановительных работ для возобновления работоспособности Модуля СЦ ЗНИ Подготовка изменений, связанных с изменением, улучшением/оптимизацией Модуля СЦ и выводом новой модифицированной функциональности в штатном режиме. Подготовка изменений, связанных с модификацией существующих и/или реализация новых интеграционных механизмов для получения/обработки данных внешних систем. Подготовка изменений графического интерфейса по требованиям Заказчика. Перечень статусов обращений (заявок) приведен в пункте 3.3. Регламента оказания Услуг. Назначение обращению (заявке) статуса «Закрыто» осуществляется Заказчиком только после получения от инициатора обращения (заявки) подтверждения о его исполнении или нахождения обращения (заявки) в статусе «Выполнено» и отсутствия повторных вопросов/запросов по данному обращению (заявки) в течение 5 рабочих дней. Категории и статусы обращений (заявок) могут быть скорректированы в процессе оказания услуг исключительно по согласованию с Заказчиком

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

4.3.6.2. Требования к услугам информационно-консультационной поддержки работников Заказчика и пользователей Модуля СЦ Услуги информационно-консультационной поддержки сотрудников Заказчика включают: – обработку обращений и заявок, поступивших от сотрудников Заказчика; – консультирование сотрудников Заказчика и пользователей Модуля СЦ; – актуализацию документации, и других материалов по работе с Модулем СЦ при необходимости. – консультирование и разработку рекомендаций по настройке Модуля СЦ (без изменения программного кода), включая изменение настроек функционирования; – консультации по вопросам использования, настройки и возможностям Модуля СЦ; – консультации по проведению превентивных мер для недопущения аварийных ситуаций в Модуле СЦ; – консультации по предварительной диагностике и локализации возникшей неисправности Модуля СЦ; – консультации по вопросам обеспечения информационной безопасности Модуля СЦ и настройки функций, обеспечивающих корректную работу программного обеспечения для совершения юридически значимых действий в Модуле СЦ; – другие вопросы, связанные с работой Модуля СЦ. 4.3.6.2.1. Требования к порядку оказания услуг информационно-консультационной поддержки работников Заказчика и пользователей Модуля СЦ Подрядчик выполняет консультирование сотрудников Заказчика и пользователей Модуля СЦ. Консультация может быть предоставлена по согласованным с представителем Заказчика каналам коммуникации с регистрацией результата консультации в СРО Подрядчиком. Детальный порядок оказания консультационных услуг определен в Регламенте оказания Услуг

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

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

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

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

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

4.3.6.4. Требования к услугам адаптационного, конфигурационного и коррекционного сопровождения и доработки Модуля СЦ (в рамках действующих программных модулей и функциональностей) Услуги адаптационного, конфигурационного и коррекционного сопровождения и доработки Модуля СЦ включают: – управление изменениями и адаптация функций Модуля СЦ; – изменение настроек функционирования Модуля СЦ; – внесение изменений и/или модификаций Модуля СЦ (в рамках действующих программных модулей и функциональностей), направленных на улучшение их работоспособности и функциональных возможностей; – подготовка и передача Заказчику SQL запросов в СУБД для получения агрегированной информации из Модуля СЦ, которую невозможно получить с использованием графического пользовательского интерфейса; – адаптация модулей интеграций со смежными информационными системами

5. СОСТАВ И СОДЕРЖАНИЕ РАБОТ ПО РАЗВИТИЮ И ТЕХНИЧЕСКОЙ ПОДДЕРЖКЕ МОДУЛЯ СЦ (КАЛЕНДАРНЫЙ ПЛАН) - Сдача-приемка результатов выполненных работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная техническая документация, а также результаты работ предоставляются Заказчику в порядке, предусмотренном Контрактом и ТЗ, до размещения Подрядчиком в ЕИС документа о приемке. Документ о приемке размещается в ЕИС по каждому этапу в соответствии с условиями Контракта. Этапы выполнения работ по развитию Модуля СЦ приведены в Таблице 11. Таблица 11. Этапы выполнения работ по развитию Модуля СЦ. № этапа Наименование этапа Результат (отчетная документация) Срок исполнения этапа - - Значение характеристики не может изменяться участником закупки

1 Техническое проектирование Сопроводительным письмом предоставляются Заказчику: · Технический проект, включая следующие документы: – Ведомость технического проекта; – Ведомость машинных носителей информации – Пояснительная записка; – Описание информационного обеспечения системы; – Описание автоматизируемых функций; – Схема функциональной структуры; – Описание организации информационной базы; – Описание программного обеспечения; · Макеты экранных форм компонента «Интерактивная карта»; · Руководство по безопасной разработке программного обеспечения; · Документ о приемке Начало: с даты заключения контракта Окончание: не позднее 31.07.2026

2 Услуги по технической поддержке Модуля СЦ (с даты заключения контракта по 10.09.2026) По окончании оказания Услуг сопроводительным письмом предоставляются Заказчику: – Отчет об оказанных Услугах по технической поддержке; – Актуальные на дату окончания оказания Услуг по данному этапу исходные коды прикладного ПО на электронном носителе (в случае внесения изменений); – Инструкция по сборке и развертыванию (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство пользователя (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство администратора (в случае внесения изменений); – Документ о приемке Начало: с даты заключения контракта Окончание: не позднее 10.09.2026

3 Разработка программного обеспечения (1 очередь, пп. 4.2.1, 4.2.6 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ; – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 1 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 1 очереди; – Руководство по резервному копированию; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 16.09.2026

4 Разработка программного обеспечения (2 очередь, пп. 4.2.3, 4.2.4 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ. – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 2 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 2 очереди; – Руководство по резервному копированию; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 25.09.2026

5 Разработка программного обеспечения (3 очередь, пп. 4.2.2, 4.2.5 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ; – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 3 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 3 очереди; – Руководство по резервному копированию; – Описание ролевой модели; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 09.10.2026

6 Опытная эксплуатация (1 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акт о завершении опытной эксплуатации 1 очереди; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке 17.09.2026 Окончание: не позднее 26.10.2026

7 Опытная эксплуатация (2 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акт о завершении опытной эксплуатации 2 очереди; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке 26.09.2026 Окончание: не позднее 26.10.2026

8 Опытная эксплуатация (3 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Акт о завершении опытной эксплуатации 3 очереди; – Документ о приемке Начало: с 10.10.2026 Окончание: не позднее 26.10.2026

9 Приемочные испытания Сопроводительным письмом предоставляются Заказчику: – Программа и методика приёмочных испытаний; – Протокол приемочных испытаний; – Исходные коды и дистрибутивы на электронном носителе (при условии внесения изменений, с учетом доработок по результатам опытной эксплуатации и проведенных испытаний); – Комплект рабочей документации на Модуль СЦ (при условии внесения изменений, с учетом доработок по результатам опытной эксплуатации и проведенных испытаний); – Акт приемки Системы в эксплуатацию; – Акт приемки-передачи исключительных прав на объект; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке; – Документы в соответствии с разделом 4.5.9 ТЗ; – Обеспечение гарантийных обязательств Начало: с 27.10.2026 Окончание: не позднее 10.11.2026

10 Услуги по технической поддержке Модуля СЦ (с 11.09.2026 по 15.12.2026) По окончании оказания Услуг сопроводительным письмом предоставляются Заказчику: – Отчет об оказанных Услугах по технической поддержке; – Актуальные на дату окончания оказания Услуг по данному этапу исходные коды прикладного ПО на электронном носителе (в случае внесения изменений); – Инструкция по сборке и развертыванию (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство пользователя (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство администратора (в случае внесения изменений); – Документ о приемке Начало: с 11.09.2026 Окончание: не позднее 15.12.2026

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

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

6.1. Сведения о гарантийном обслуживании Модуля СЦ Под гарантией понимается устранение Подрядчиком своими силами и за свой счет допущенных по его вине недостатков, выявленных после приемки выполненных Работ, как в работе самой Модуля СЦ, так и недостатков в отчетной документации. Если в период гарантийного срока обнаружатся недостатки, то Подрядчик обязан устранить их за свой счет, в сроки, установленные Заказчиком. Гарантийный срок в этом случае продлевается на период устранения недостатков. Срок гарантии: 1 год с даты приемки Заказчиком результатов исполнения Этапа № 9 контракта. Подрядчиком должны быть внесены соответствующие исправления в техническую и рабочую документацию (указанную в пунктах 5 и 6 настоящего ТЗ), связанные с устранением замечаний к работе Модуля СЦ или в случае выявления Заказчиком недостатков в такой документации в период гарантийного срока. Внесение изменений в документацию технического и рабочего проектирования осуществляется в соответствии с ГОСТ 2.503-2023 и ГОСТ Р 2.504-2021.

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

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

8. ТРЕБОВАНИЯ К СОСТАВУ И СОДЕРЖАНИЮ РАБОТ ПО ПОДГОТОВКЕ МОДУЛЯ СЦ К ВВОДУ В ЭКСПЛУАТАЦИЮ - По результатам проведения приемочных испытаний оформляется Протокол приемочных испытаний и Акт приемки в эксплуатацию. В случае, если взаимодействие с внешними системами не может быть проверено на средах постоянной эксплуатации взаимодействующих систем (по причине неготовности со стороны внешней системы или иным причинам), функции взаимодействия, разработанные в соответствии с требованиями ТЗ, должны быть проверены на тестовых данных с использованием программ-имитаторов взаимодействия. По результатам выполнения этапа приемочных испытаний должны быть подготовлены материалы для регистрации доработанной версии Модуля СЦ (объекта учета) в НФАП в соответствии с требованиями постановления Правительства Российской Федерации от 30 января 2013?г. №?62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин» (с изменениями и дополнениями) в части обязательности размещения результатов работ в национальном фонде алгоритмов и программ для электронных вычислительных машин. Сдача-приемка результатов выполнения Работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная, техническая документация, а также программное обеспечение предоставляется Заказчику в порядке, предусмотренном Контрактом и ТЗ до размещения Подрядчиком в Единой информационной системе в сфере закупок документа о приемке. Результаты проведения опытной эксплуатации, предварительных и приемочных испытаний должны быть зафиксированы в соответствующих протоколах и актах. Выявленные отклонения от настоящего ТЗ, оформляются как недостатки Модуля СЦ - - Значение характеристики не может изменяться участником закупки

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

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

9. ТРЕБОВАНИЯ К ДОКУМЕНТИРОВАНИЮ - 9.1. Общие требования Документация на Модуль СЦ должна быть разработана в составе, указанном в разделах 5-8 данного ТЗ, и должна удовлетворять требованиям комплекса стандартов и руководящих документов на автоматизированные системы: – ГОСТ Р 2.105-2019 в части оформления текстовых документов; – ГОСТ 34.201-2020 в части наименования и обозначения документов. Документация на Модуль СЦ должны оформляться на листах формата А4. Допускается для размещения рисунков и таблиц использование листов формата А3 с подшивкой по короткой стороне листа. Документы объемом более 25 (двадцати пяти) листов должны содержать информационную часть, состоящую из аннотации и содержания. Исходные коды должны быть представлены в 1 (одном) экземпляре на электронном носителе, отчетные материалы должны быть представлены в 2 (двух) экземплярах на бумажном носителе (по одному экземпляру для Заказчика и Подрядчика) и в 1 (одном) экземпляре на электронном носителе в формате документов DOCX и PDF. При разработке документов на Модуль СЦ допускается отклонение от требований комплекса стандартов, описанных выше. Документам на Модуль СЦ должны в обязательном порядке присваиваться уникальные децимальные номера в соответствии с порядком, установленном в ГОСТ 34.201-2020. Документ «Программа и методика предварительных испытаний» должен включать приложения с формой протокола предварительных испытаний и формой акта приемки в опытную эксплуатацию. Документ «Программа опытной эксплуатации» должен включать приложение с формой журнала опытной эксплуатации. Документ «Программа и методика приемочных испытаний» должен включать приложения с формой протокола приемочных испытаний и формой акта приемки в эксплуатацию - - Значение характеристики не может изменяться участником закупки

10. ИСТОЧНИКИ РАЗРАБОТКИ - 10.1. Список литературы Специальная литература для разработки ТЗ не использовалась. 10.2. Нормативно-методические документы Список используемых нормативно-методических документов представлен в разделе 1.6 технического задания. ? Приложение А Эскизы визуального оформления компонента «Интерактивная карта» - - Значение характеристики не может изменяться участником закупки

Приложение Б Параметры оказания услуг - Б.1. Базовые параметры оказания Услуг Базовые параметры оказания Услуг приведены ниже: – режимы оказания Услуг (таблица Б.1.1); – сроки предоставления отчетности (таблица Б.1.2). Таблица Б.1.1 - Режимы оказания Услуг № п/п Параметр Значение - - Значение характеристики не может изменяться участником закупки

1 Режим работы Системы Круглосуточно (24х7) 2 Режим доступности информационно-консультационной поддержки пользователей Системы 2.1 Прием и регистрация обращений (заявок) в СРО Регистрация обращений (заявок) производится круглосуточно в режиме 24х7, без праздников и выходных дней. Обработка заявок первой линией поддержки осуществляется в рабочие дни с 9 до 18 часов 2.2 Консультирование сотрудников Заказчика и пользователей Системы в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 3 Режим доступности по решению инцидентов, связанных с работой ППО: 3.1 - приоритет «Критический» Круглосуточно (24х7) 3.2 - приоритет «Высокий» Круглосуточно (24х7) 3.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 3.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4 Режим доступности услуг по адаптации, конфигурации и коррекционному сопровождению Системы 4.1 - приоритет «Критический» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.2 - приоритет «Высокий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 5 Режим доступности по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности 5.1 - приоритет «Критический» Круглосуточно (24х7) 5.2 - приоритет «Высокий» Круглосуточно (24х7) 5.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 5.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням)

Таблица Б.1.2. Сроки предоставления отчетности, с момента получения запроса № п/п Параметр Значение 1 Предоставление отчета об оказанных услугах за произвольный период 10 рабочих дней 2 Предоставление подробной информации по инциденту с приоритетом «Критический» 16 рабочих часов 3 Предоставление актуализированной документации 10 рабочих дней

Б.2. Приоритеты и регламентные сроки решения обращений (заявок) В зависимости от уровня сбоя в работе Системы обращению (заявке) присваивается один из следующих приоритетов, а также в зависимости от приоритета обращения (заявки) устанавливаются следующие контрольные сроки решения в соответствии с таблицей ниже (Таблица Б.2.1). Таблица Б.2.1 – Приоритеты и регламентные сроки решения обращений (заявок) № п/п Приоритет Максимальное время реагирования Время решения (срок выполнения) Описание приоритета По информационно-консультационной поддержке сотрудников Заказчика и пользователей Системы 1 - не более 1 часа не более 10 часов - По решению инцидентов, связанных с работой ППО: 1 Критический не более 30 минут не более 4 часов - полная недоступность ППО; - недоступность ключевых функций - ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО; - невозможность информационного обмена с ППО для ИС более 4 часов 2 Высокий не более 1 часа не более 8 часов - ошибки/сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; - снижение быстродействия СПО (время отклика ППО на операции превышает 30 секунд); - недоступность управления правами и ролями пользователей 3 Средний не более 4 часов не более 24 часов - невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым -недоступность функции формирования отчетов 4 Низкий не более 8 часов не более 40 часов - отклонение в работе ППО, не влияющее на корректную работу функций; - другие сбои и ошибки, затрагивающие основные функции ППО

По адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) 1 Критический не более 40 минут не более 8 часов - изменения, необходимые при проведении аварийно-восстановительных работ для возобновления работоспособности Системы; - изменения, связанные с критичными ошибками, блокирующими возможность оказания государственных услуг и/или чтение и внесение данных в Систему 2 Высокий не более 1 часа не более 40 часов - изменения, относящиеся к обеспечению работоспособности основной функциональности Системы, устраняют выявленные дефекты в работе Системы, оказывающие существенное влияние на работу пользователей в Системе; - изменения, затрагивающие три и более подсистемы/модуля Системы для адаптации 3 Средний не более 4 часов не более 72 часов - изменения, связанные с развитием/улучшением/оптимизацией Системы и выводом новой функциональности в штатном режиме для одного-двух модулей/подсистем; - изменения, связанные с развитием интеграционных механизмов Системы, например обновление существующих и/или реализация новых видов сведений СМЭВ, обновление существующих и/или реализация новых API, адаптация и/или изменение механизмов импорта и экспорта данных Системы и т.д. 4 Низкий не более 8 часов не более 160 часов - изменения, связанные с ошибками/корректировкой/изменением в отображении информации в пользовательском графическом интерфейсе Системы (графика, текст, органы управления, элементы интерфейса)

По устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности 1 Критический не более 30 минут не более 24 часов - критические уязвимости, влияющие на возможную полную недоступность ППО, ключевых функций Системы, ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО без возможности восстановления работоспособности Системы. - Критический уровень CVSS > 8.0 2 Высокий не более 1 часа не более 84 часов - критические уязвимости, влияющие на ошибки и сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО. - Высокий уровень CVSS 5.0 - 8.0 3 Средний не более 4 часов не более 120 часов - уязвимости, влияющие на невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым - Средний уровень CVSS 2.0 - 4.9 4 Низкий не более 8 часов не более 160 часов - уязвимости, влияющие на отклонение в работе ППО, не влияющее на корректную работу функций; - другие сбои и ошибки, затрагивающие основные функции ППО - Низкий уровень CVSS < 2.0

Взаимодействие Заказчика и Подрядчика в части регистрации и контроля времени реагирования и решения обращения (заявки) осуществляется через СРО. Заказчик предоставляет Подрядчику доступ к СРО после заключения Контракта. Поступившие от разных пользователей заявки по поводу однотипных инцидентов или имеющие общую причину должны объединяться в одну заявку. Срок выполнения включает время диагностики инцидента, в ходе которого определяется причина инцидента (проблемы) и способ его устранения. Подрядчик должен обеспечить функционирование Модуля СЦ в соответствии с требованиями и параметрами, указанными в настоящем ТЗ и Регламенте оказании услуг. Основные параметры быстродействия типовых операций в Модуле СЦ указаны в таблице ниже (таблица Б.2.2). Таблица Б.2.2 - Параметры быстродействия Модуля СЦ № п/п Наименование параметра Значение (секунд) 1 Среднее время получения сообщения из очереди сообщений 10 2 Среднее время получения ответа от Системы 5 3 Среднее время открытия карточки реестра 5

Приложение В Регламент оказания услуг - Приложение Д Форма Протокола проверки результатов организационно-штатных и подготовительных мероприятий (шаблон) Протокол проверки результатов организационно-штатных и подготовительных мероприятий Настоящий Протокол содержит результаты проверки организационно-штатных и подготовительных мероприятий, проведенных Исполнителем (Таблица Д.1). Таблица Д.1. Протокол проверки результатов № Мероприятия Подготовительного этапа Результат проверки 1. Определить и направить Заказчику документ «Ответственные за взаимодействия в рамках выполнения работ по техническому сопровождению Системы со стороны Исполнителя». Документ содержит контактную информацию (ФИО, должность, адрес электронной рабочей почты, номер телефона) не менее чем о 2 лицах, ответственных за оказание услуг со стороны Подрядчика Выполнено/Не выполнено 2. Обеспечить подключение специалистов Подрядчика к Системе Выполнено/Не выполнено 3. Обеспечить подключение специалистов Подрядчика к СРО Выполнено/Не выполнено Заказчик Подрядчик /Должность/ /Должность/ ____________________ /Ф.И.О/ ___________________ /Ф.И.О/ М.П. М.П. «_____»_______________________202_г. «_____»_______________________202_г - - Значение характеристики не может изменяться участником закупки

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

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

Уровень технической поддержки Организационно-структурная часть технической поддержки, имеющая определённые организационно-нормативными документами зоны ответственности, обязанности, а также временные нормативы, в течение которых эти обязательства должны выполняться либо эскалироваться на следующий уровень технической поддержки Услуги Услуги по технической поддержке Информационно-аналитической системы регулирования на транспорте АСУ ТК ФИО Фамилия, имя, отчество Эскалация Процедура повышения внимания к обращению (заявке) путем повышения его приоритета и/или передачи на следующий уровень технической поддержки, а также привлечение ролей, которые могут принимать решения без передачи на следующий уровень технической поддержки API Англ. Application Programming Interface — программный интерфейс приложения, интерфейс прикладного программирования — описание способов (набор классов, процедур, функций, структур или констант), которыми одна компьютерная программа может взаимодействовать с другой программой

CVSS Англ. Common Vulnerability Scoring System - открытый стандарт, используемый для расчета количественных оценок уязвимости в безопасности компьютерной системы, обычно с целью понять приоритет ее исправления. В современном инструментарии информационной безопасности используется версия 3.0 и выше с дополнительными метриками к базовым оценкам ID Англ. Identifier – идентификатор, уникальный признак объекта, позволяющий отличать его от других объектов, то есть, идентифицировать SLA Англ. Service Level Agreement - утвержденные условия по обработке обращения (заявки) с установленными метриками времени, которые определяют пороговые значения для эскалации в зависимости от статуса обращения (заявки) (например, время реакции – время от регистрации до осуществления первичной обработки, время решения – время от регистрации обращения (заявки) до его решения и т.д.) SQL Англ. Structured Query Language — «язык структурированных запросов», — декларативный язык программирования, применяемый для создания, модификации и управления данными в реляционной базе данных, управляемой соответствующей СУБД

1 Общие сведения 1.1 Полное наименование Услуг Оказание услуг по технической поддержке Модуля СЦ АСУ ТК в 2026 году. 1.2 Предмет Регламента оказания услуг Требования Технического задания

2 Общие положения 2.1 Цель и задачи оказания услуг Целью технической поддержки Системы является обеспечение ее стабильного и безопасного функционирования и эксплуатации, предупреждение, выявление и устранение сбоев в работе Системы и минимизация их неблагоприятного влияния. Для достижения поставленной цели требуется решение следующих задач: 1. Обеспечение информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы. 2. Поддержание параметров функционирования ППО Системы, удовлетворяющих требованиям производственных процессов, включая их непрерывность. 3. Обеспечение бесперебойного функционирования ППО и своевременное устранение сбоев и аварийных ситуаций в Системе. 4. Своевременное устранение уязвимостей при выявлении таковых, в соответствии с требованиями к обеспечению информационной безопасности. 5. Адаптация, конфигурирование, коррекция программного обеспечения в соответствии с изменениями нормативно-правовой базы и запросами уполномоченных сотрудников органов государственной власти, включая выполнение процедур тестирования и участие в обновлениях ППО на стендах Заказчика. 6. Обеспечение сохранения работоспособности ППО в изменяемой среде эксплуатации. 7. Ведение документации по настоящему контракту и инициирование актуализации документации на Систему по результатам обработки запросов Заказчика и внесения соответствующих изменений в ППО

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

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

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

Таблица 1 - Типы обращений (заявок) Тип обращения (заявки) Описание Запрос на обслуживание Подготовка SQL запроса к СУБД для решения прикладной задачи и д р. – запрос на любое действие, не являющееся запросом информации и несовершенный на основе происшествия, прямо или косвенно влияющего на работу Системы Консультация (входит в тип обращения (заявки) «Запрос на обслуживание») «Где взять / куда обратиться...?», «Как сделать / выполнить…», «Как это работает…?» - запрос, имеющий своей целью получение информационной поддержки Инцидент Разбор ошибок/сбоев и подготовка материалов (корректировочных релизов, инструкций) для Заказчика для устранения ошибок/сбоев, которые приводят к частичному и полному нарушению работоспособности всех или отдельных функций ППО. Подготовка изменения и материалов, необходимых для проведения аварийно-восстановительных работ для возобновления работоспособности Системы. ЗНИ Подготовка изменений, связанных с изменением, улучшением/оптимизацией Системы и выводом новой модифицированной функциональности в штатном режиме. Подготовка изменений, связанных с модификацией существующих и/или реализация новых интеграционных механизмов для получения/обработки данных внешних систем. Подготовка изменений графического интерфейса по требованиям Заказчика

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

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

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

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

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

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

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

3.4.1 Инцидент На рисунке 2 представлена функциональная схема регистрации и сопровождения обращений (заявок) типа «Инцидент». Рисунок 2 - Функциональная схема регистрации и сопровождения обращений (заявок) типа «Инцидент» 3.4.2 Запрос на обслуживание На рисунке 3 представлена функциональная схема регистрации и сопровождения обращения (заявки) типа «ЗНО». Рисунок 3 - Функциональная схема регистрации и сопровождения обращения (заявки) типа «ЗНО» 3.4.3 Запрос на изменение На рисунке 4 представлена функциональная схема регистрации и сопровождения обращений (заявок) типа «ЗНИ». Рисунок 4 - Функциональная схема регистрации и сопровождения обращений (заявок) типа «ЗНИ»

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

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

4 Формы обращений (заявок) на оказание услуг по технической поддержке Системы, заполняемые в СРО 4.1. Форма обращения (заявки) на оказание услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы При подаче обращения (заявки) типа «ЗНО» в СРО указывается (Таблица 5): Таблица 5 – Описание атрибутов формы обращения (заявки) на оказание услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 5) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 5) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 5) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 5) Категория обращения: информационно-консультационная поддержка Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 5) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 5) Текст запроса на оказание услуги по информационно-консультационной поддержке сотрудников Заказчика Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 5)

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

4.2. Форма обращения (заявки) на оказание услуги по решению инцидентов, связанных с работой ППО При подаче обращения (заявки) типа «Инцидент» в СРО указывается (Таблица 6): Таблица 6 – Описание атрибутов формы обращения (заявки) на оказание услуги по решению инцидентов, связанных с работой ППО Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 6) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 6) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 6,) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 6) Категория обращения (заявки): инцидент Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 6) Приоритет изменения Время - одно из значений: Низкий, Средний, Высокий или Критический. Определяет, очередность решения обращения (заявки), ресурсы, привлекаемые для решения обращения (заявки), порядок/процедура действий при решении обращения (заявки) – поле СРО «Приоритет» (см. рисунок 6,)

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

На рисунке 6 приведена форма обращения (заявки) типа «Инцидент» в СРО. Рисунок 6 - Форма обращения (заявки) типа «Инцидент» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуги по решению инцидентов, связанных с работой ППО, заполненную в свободной форме

4.3. Форма обращения (заявки) на оказание услуг по адаптационному конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) При подаче обращения (заявки) типа «ЗНИ» в СРО указывается (Таблица 7): Таблица 7 – Описание атрибутов формы обращения (заявки) на оказание услуг по адаптационному, конфигурационному и коррекционному сопровождению Системы Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 10) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 9) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 10) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 10) Категория обращения (заявки): запрос на изменение Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 7) Приоритет изменения Время, очередность решения обращения (заявки), ресурсы, привлекаемые для решения обращения (заявки), порядок/процедура действий при решении обращения (заявки) – поле СРО «Приоритет» (см. рисунок 7) Тип изменения Справочник, классифицирующий типовые запросы характерные для Системы – поле СРО «Предмет обращения» (см. рисунок 7) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 7) Текст запроса на оказание услуги по адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 7)

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

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

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

На рисунке 8 приведена форма обращения (заявки) типа «Инцидент» в СРО. Рисунок 8 - Форма обращения (заявки) типа «Инцидент» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуги по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности, заполненную в свободной форме

Приложение 1 к Регламенту Матрица ответственных за взаимодействия в рамках выполнения работ по техническому сопровождению Системы Таблица 1 – Ответственные за взаимодействия в рамках выполнения работ по техническому сопровождению Системы со стороны Исполнителя ФИО Должность Адрес электронной почты Телефон — — — Общий контакт

Приложение 2 к Регламенту Приоритеты и регламентные сроки решения обращений (заявок) Приоритеты и регламентные сроки решения обращений (заявок) приведены в таблице 1. Таблица 1 – Приоритеты и регламентные сроки решения обращений (заявок) № п/п Приоритет Максимальное время реагирования Время решения (срок выполнения) Описание приоритета

По информационно-консультационной поддержке сотрудников Заказчика и пользователей Системы 1 – не более 1 часа не более 10 часов –

По решению инцидентов, связанных с работой ППО 1 Критический не более 30 минут не более 4 часов – полная недоступность ППО; – недоступность ключевых функций; – ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО; – невозможность информационного обмена с ППО для ИС более 4 часов 2 Высокий не более 1 часа не более 8 часов – ошибки/сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; – снижение быстродействия СПО (время отклика ППО на операции превышает 30 секунд); – невозможность управления правами и ролями пользователей 3 Средний не более 4 часов не более 24 часов – невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым недоступность функции формирования отчетов 4 Низкий не более 8 часов не более 40 часов – отклонение в работе ППО, не влияющее на корректную работу функций; – другие сбои и ошибки, затрагивающие основные функции ППО

По адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) 1 Критический не более 40 минут не более 8 часов – изменения необходимые при проведении аварийно-восстановительных работ для возобновления работоспособности Системы; – изменения, связанные с критичными ошибками, блокирующими возможность оказания государственных услуг и/или чтение и внесение данных в Систему 2 Высокий не более 1 часа не более 40 часов – изменения относящиеся к обеспечению работоспособности основной функциональности Системы, устраняют выявленные дефекты в работе Системы, оказывающие существенное влияние на процесс оказания государственных услуг и работу пользователей в Системе; – изменения, затрагивающие три и более подсистемы/модуля Системы для адаптации 3 Средний не более 4 часов не более 72 часов – изменения, связанные с развитием/улучшением/оптимизацией Системы и выводом новой функциональности в штатном режиме для одного-двух модулей/подсистем; – изменения, связанные с развитием интеграционных механизмов Системы, например, обновление существующих и/или реализация новых видов сведений СМЭВ, обновление существующих и/или реализация новых API, адаптация и/или изменение механизмов импорта и экспорта данных Системы и т.д. 4 Низкий не более 8 часов не более 160 часов – изменения, связанные с ошибками/ корректировкой/изменение в отображении информации в пользовательском графическом интерфейсе Системы (графика, текст, органы управления, элементы интерфейса)

По устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности 1 Критический не более 30 минут не более 24 часов – критические уязвимости, влияющие на возможную полную недоступность ППО, ключевых функций Системы, ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО без возможности восстановления работоспособности Системы; – Критический уровень CVSS > 8.0 2 Высокий не более 1 часа не более 84 часов – критические уязвимости, влияющие на ошибки и сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; – Высокий уровень CVSS 5.0 - 8.0 3 Средний не более 4 часов не более 120 часов – уязвимости, влияющие на невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым; – Средний уровень CVSS 2.0 - 4.9 4 Низкий не более 8 часов не более 160 часов – уязвимости, влияющие на отклонение в работе ППО, не влияющее на корректную работу функций; – другие сбои и ошибки, затрагивающие основные функции ППО; – Низкий уровень CVSS < 2.0

Приложение Г Форма Отчета об оказанных услугах Отчет об оказанных услугах за этап «наименование этапа» в период с «__» _________ по «__» _________. № п/п Наименование услуги Общее количество Номер ОРС Краткое Описание Время реагирования по ТЗ Время реагирования фактическое Время решения по ТЗ Время решения фактическое Результат соблюдения времени реагирования Результат соблюдения времени решения Примечание 1 Услуги по информационно-консультационной поддержке работников Заказчика 2 546782 Консультация по работе Модуля СЦ 1 2 10 часов 11 часов Нет Нет 567123 Консультация по схеме БД 1 1 10 часов 1 час Да Да 2 … … Заказчик Подрядчик /Должность/ /Должность/ ____________________ /Ф.И.О/ ___________________ /Ф.И.О/ М.П. М.П. «_____»_______________________202_г. «_____»_______________________202_г

Приложение 1 к Отчету об оказанных услугах Журнал обращений (заявок) на оказание услуги по информационно-консультационной поддержке пользователей Системы (шаблон) Наименование Исполнителя в этапе «наименование этапа» в период с ________________ по _______________ оказал(о) Услугу по поддержке пользователей Системы в объеме, указанном в Таблице 1 Таблица 1 - Журнал обращений (заявок) пользователей Системы № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. ИТОГО зарегистрировано: Всего обращений (заявок): ________ ИТОГО решено: Всего обращений (заявок): ________

Приложение 2 к Отчету об оказанных услугах Журнал обращений (заявок) по решению инцидентов, связанных с работой ППО (шаблон) Наименование Исполнителя в этапе «наименование этапа» в период с ________________ по _______________ оказал(о) Услугу по решению инцидентов в объеме, указанном в Таблице 1. Таблица 1 - Журнал по решению инцидентов № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. ИТОГО зарегистрировано: Всего инцидентов: ________ ИТОГО решено: Всего инцидентов: ________

Приложение 3 к Отчету об оказанных услугах Журнал обращений (заявок) выполнения адаптационного, конфигурационного и коррекционного сопровождения Системы (шаблон) Журнал выполнения адаптации, конфигурации и коррекции Системы сформирован за этап «наименование этапа» в период с «__» _________ по «__» ____________ и представлен в таблице ниже (Таблица 1). Таблица 1 - Журнал выполнения адаптации, конфигурации и коррекции сопровождения Системы № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. Количество выполненных заявок за этап: ________

Приложение 4 к Отчету об оказанных услугах Журнал обращений (заявок) по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности (шаблон) Журнал обращений (заявок) по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности сформирован за этап «наименование этапа» в период с «__» _________ по «__» ____________ и представлен в таблице ниже (Таблица 1). Таблица 1 - Журнал выполнения заявок по устранению уязвимостей в ППО № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. Количество выполненных заявок за этап: ________

- 62.01.11.000 - Этап№3: Разработка программного обеспечения (1 очередь, пп. 4.2.1, 4.2.6 ТЗ), Предварительные испытания ОКПД2: 62.01.11.000 ОПРЕДЕЛЕНИЯ, ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ Автоматизированная система (АС) Система, состоящая из комплекса средств автоматизации, реализующего информационную технологию выполнения установленных функций, и персонала, обеспечивающего его функционирование (ГОСТ Р 59853-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения») АРМ Автоматизированное рабочее место АСУ ТК, Система Информационно-аналитическая система регулирования на транспорте АТС Автоматическая телефонная станция БД База данных ГИС Государственная информационная система ГОСТ Государственный стандарт ГЦОД СИЦ Минтранса России, ГЦОД Головной центр обработки данных ФГБУ «СИЦ Минтранса России» Дашборд Интерактивная аналитическая панель, графический интерфейс. ЕИС Единая информационная система в сфере закупок ЕСИА Единая система идентификации и аутентификации Заказчик Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» КИИ Критическая информационная инфраструктура Кластер Кла?стер (англ. cluster) – объединение нескольких однородных элементов, которое может рассматриваться как самостоятельная единица, обладающая определёнными свойствами Компонент Часть АС, выделенная по определенному признаку или совокупности признаков и рассматриваемая как единое целое (ГОСТ Р 59853-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения») Контракт Контракт на выполнение работ по развитию и оказанию услуг по технической поддержке Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК в 2026 году, заключаемый по результатам проведения конкурентной процедуры закупки в соответствии с требованиями Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» ... 1. ОБЩИЕ СВЕДЕНИЯ – ГОСТ Р 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 «Информационная технология (ИТ). Оценка программной продукции. Характеристики качества и руководства по их применению»; ... 2. ЦЕЛИ И НАЗНАЧЕНИЕ ВЫПОЛНЕНИЯ РАБОТ 2.1. Назначение АСУ ТК АСУ ТК предназначена для автоматизации и информационно-аналитического обеспечения процессов управления развитием транспортного комплекса Российской Федерации, обеспечения публичности деятельности органов государственного управления транспортным комплексом. Основными целями АСУ ТК являются: – повышение эффективности процессов управления функционированием и развитием транспортного комплекса на основе создания единой информационной среды и комплекса информационно-аналитических услуг на уровне органов государственного управления ТК; – повышение уровня безопасности ТК на базе получения полной, достоверной и оперативной информации о происходящих изменениях, своевременного выявления негативных тенденций и для принятия соответствующих мер по их устранению и ликвидации последствий ... - Условная единица - 1,00 - 22 647 414,58 - 22 647 414,58

- Наименование характеристики Значение характеристики Единица измерения характеристики Инструкция по заполнению характеристик в заявке ОПРЕДЕЛЕНИЯ, ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ Автоматизированная система (АС) Система, состоящая из комплекса средств автоматизации, реализующего информационную технологию выполнения установленных функций, и персонала, обеспечивающего его функционирование (ГОСТ Р 59853-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения») АРМ Автоматизированное рабочее место АСУ ТК, Система Информационно-аналитическая система регулирования на транспорте АТС Автоматическая телефонная станция БД База данных ГИС Государственная информационная система ГОСТ Государственный стандарт ГЦОД СИЦ Минтранса России, ГЦОД Головной центр обработки данных ФГБУ «СИЦ Минтранса России» Дашборд Интерактивная аналитическая панель, графический интерфейс. ЕИС Единая информационная система в сфере закупок ЕСИА Единая система идентификации и аутентификации Заказчик Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» КИИ Критическая информационная инфраструктура Кластер Кла?стер (англ. cluster) – объединение нескольких однородных элементов, которое может рассматриваться как самостоятельная единица, обладающая определёнными свойствами Компонент Часть АС, выделенная по определенному признаку или совокупности признаков и рассматриваемая как единое целое (ГОСТ Р 59853-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения») Контракт Контракт на выполнение работ по развитию и оказанию услуг по технической поддержке Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК в 2026 году, заключаемый по результатам проведения конкурентной процедуры закупки в соответствии с требованиями Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» Значение характеристики не может изменяться участником закупки Модуль iМинтранс Модуль сбора данных и представления показателей деятельности Министерства транспорта Российской Федерации iМинтранс АСУ ТК Модуль СЦ Модуль сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК НС Нештатная ситуация НСИ Нормативно-справочная информация ОТИ Объект транспортной инфраструктуры П-ГИС Геоинформационная подсистема П-ИВ Подсистема информационного взаимодействия П-НСИ Подсистема ведения нормативно-справочной информации и метаданных ПО Программное обеспечение Подрядчик, Исполнитель Организация, с которой будет заключен контракт на выполнение работ по развитию Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК П-СД Подсистема сбора данных Работы Работы по развитию Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК СЗИ Средство защиты информации СМЭВ Система межведомственного электронного взаимодействия СУБД Система управления базами данных ТЗ Техническое задание (настоящий документ) ТС Транспортное средство ТК Транспортный комплекс Учреждение Учреждения в области информационной безопасности ФГБУ «СИЦ Минтранса России» Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации», Заказчик Федеральный закон № 44-ФЗ Федеральный закон от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» ФЗ Функциональная задача ФЗ «Реестр объектов» Функциональная задача «Формирование и ведение единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации» ФСБ России Федеральная служба безопасности Российской Федерации ФСТЭК России Федеральная служба по техническому и экспортному контролю ЧС Чрезвычайная ситуация ЭВМ Электронно-вычислительная машина API От англ. Application Programming Interface – интерфейс прикладного программирования – совокупность инструментов и функций в виде интерфейса для взаимодействия с программой CSS От англ. Cascading Style Sheets — каскадные таблицы стилей FPS От англ. frame per second - количество кадров в секунду HTML От англ. HyperText Markup Language - стандартный язык разметки документов, создающий основу и структуру всех веб-страниц JSON От англ. JavaScript Object Notation – текстовый формат обмена данными, основанный на JavaScript WebAssembly (Wasm) Открытый стандарт, представляющий собой низкоуровневый бинарный формат инструкций, который позволяет выполнять код, написанный на языках C++, Rust или Go, в браузерах с производительностью, близкой к нативной 1. ОБЩИЕ СВЕДЕНИЯ – ГОСТ Р 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.7. Сроки начала и окончания работ Начало работ: с даты заключения Контракта. Окончание работ: не позднее 15.12.2026. Работы выполняются в соответствии с этапами. Сроки выполнения этапов работ по развитию и технической поддержке Модуля СЦ определяются Календарным планом. Календарный план, приведен в разделе 5 настоящего ТЗ 1.8. Общие сведения об источниках и порядке финансирования работ Источником финансирования являются средства субсидии федерального бюджета Российской Федерации, предоставленной в соответствии с абзацем вторым пункта 1 статьи 78.1 Бюджетного кодекса Российской Федерации (код цели 08-01) 1.9. Порядок оформления и предъявления результатов работ Подрядчик должен передать Заказчику результаты работ в порядке, определенном Контрактом в сроки, установленные п. 5 настоящего ТЗ, в соответствии с Календарным планом 1.10. Место выполнения Работ Работы выполняются удаленно на комплексе технических средств Заказчика. Адрес размещения комплекса технических средств Заказчика: Московская обл., Богородский район, пос. Горбуша, Радиоцентр. Техническая возможность удаленного подключения обеспечивается Заказчиком (в части предоставления параметров доступа). Оплата телематических и иных услуг, технических и программных средств, необходимых Подрядчику для удаленного подключения и для выполнения требований по информационной безопасности, осуществляется Подрядчиком самостоятельно за свой счет 1.1. Наименование Системы Полное наименование системы: Информационно-аналитическая система регулирования на транспорте. Условное обозначение системы: АСУ ТК. Полное наименование модуля: Модуль сбора, ведения и анализа информации о нештатных ситуациях на транспорте. Условное обозначение модуля: Модуль СЦ. Модуль СЦ создан в рамках контракта от 05.08.2024 № ОК/24_04 на выполнение работ по развитию АСУ ТК в части создания модуля «Сбора, ведения и анализа информации о нештатных ситуациях на транспорте». Развитие Модуля СЦ осуществлено в рамках контракта от 19.05.2025 № ОК/25_09 на выполнение работ по развитию Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК 1.2. Шифр темы или номер контракта Присваивается Заказчиком по результатам организации закупочных процедур. 1.2.1. Предмет контракта Выполнение работ по развитию Модуля СЦ. Код по ОКПД2: 62.01.11.000 – услуги по проектированию и разработке информационных технологий для прикладных задач и тестированию программного обеспечения. Оказание услуг по технической поддержке Модуля СЦ. Код по ОКПД2: 62.02.30.000 – услуги по технической поддержке информационных технологий. Выполнение работ по развитию Модуля СЦ предусмотрено с учетом ключевых результатов (ОКР) Ведомственной программы цифровой трансформации Минтранса России на 2026-2028 (далее - ВПЦТ Минтранса России) в составе мероприятия № 103.002 «АСУ ТК» ИТ расхода 103.26.000005 «Развитие Информационно-аналитической системы регулирования на транспорте (АСУ ТК)»: · «Обеспечено информационное взаимодействие с Минобороны о происшествиях на транспортных объектах»; · «Обеспечена автоматизация формирования отчетов о нештатных ситуациях на транспорте, в том числе по данным внешних систем». Выполнение работ по технической поддержке АСУ ТК предусмотрено ВПЦТ Минтранса России в составе мероприятия № 103.002 «АСУ ТК» ИТ расхода 103.26.000021 «Эксплуатация Информационно-аналитической системы регулирования на транспорте (АСУ ТК)» 1.3. Заказчик Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» (ФГБУ «СИЦ Минтранса России»). Адрес: 107078, Москва, Садовая-Спасская ул., д.18, стр. 1. Оператором Системы является Заказчик - Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» (ФГБУ «СИЦ Минтранса России) 1.4. Подрядчик Определяется по результатам проведения конкурентной процедуры закупки в соответствии с требованиями Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (далее – Федеральный закон № 44-ФЗ) 1.5. Основания для выполнения работ Работы осуществляются на основании следующих документов: – постановление Правительства Российской Федерации от 30.12.2003 № 794 «О единой государственной системе предупреждения и ликвидации чрезвычайных ситуаций»; – постановление Правительства Российской Федерации от 08.11.2013 № 1007 «О силах и средствах единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций»; – распоряжение Правительства Российской Федерации от 27.11.2021 № 3363-р «О Транспортной стратегии Российской Федерации до 2030 года с прогнозом на период до 2035 года»; – Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 26.08.2025 №ЕФ-3; – Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 27.11.2025 №ЕФ-23; – Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 19.02.2026 №ЕФ-1; – План мероприятий по профилактике случаев непроизводственного травматизма граждан на железнодорожном транспорте, являющийся приложением к постановлению коллегии Министерства транспорта Российской Федерации от 11.03.2026 № 2 1.6. Перечень документов, требования которых должны быть учтены при выполнении работ – Федеральный закон Российской Федерации от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации»; – Федеральный закон Российской Федерации от 27.07.2006 № 152-ФЗ «О персональных данных»; – Федеральный закон Российской Федерации от 06.04.2011 № 63-ФЗ «Об электронной подписи»; – Федеральный закон Российской Федерации от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации»; – Указ Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации»; – Указ Президента Российской Федерации от 01.05.2022 № 250 «О дополнительных мерах по обеспечению информационной безопасности Российской Федерации»; – Указ Президента Российской Федерации от 31.03.2010 № 403 «О создании комплексной системы обеспечения безопасности населения на транспорте»; – постановление Правительства Российской Федерации от 30.07.2004 № 395 «Об утверждении Положения о Министерстве транспорта Российской Федерации»; – постановление Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации»; – постановление Правительства Российской Федерации от 16.11.2015 № 1236 «Об установлении запрета на допуск программного обеспечения, происходящего из иностранных государств, для целей осуществления закупок для обеспечения государственных и муниципальных нужд»; – постановление Правительства Российской Федерации от 23.12.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 Федерального закона «Об электронной подписи»; – постановление Правительства Российской Федерации от 08.06.2011 № 451 «Об инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг и исполнения государственных и муниципальных функций в электронной форме»; – постановление Правительства Российской Федерации от 30.01.2013 № 62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин»; – приказ ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации»; – приказ ФСТЭК России от 11.04.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений»; – приказ ФСБ России от 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 «Национальный стандарт Российской Федерации. Интеллектуальная собственность. Патентные исследования. Содержание и порядок проведения»; 2. ЦЕЛИ И НАЗНАЧЕНИЕ ВЫПОЛНЕНИЯ РАБОТ 2.1. Назначение АСУ ТК АСУ ТК предназначена для автоматизации и информационно-аналитического обеспечения процессов управления развитием транспортного комплекса Российской Федерации, обеспечения публичности деятельности органов государственного управления транспортным комплексом. Основными целями АСУ ТК являются: – повышение эффективности процессов управления функционированием и развитием транспортного комплекса на основе создания единой информационной среды и комплекса информационно-аналитических услуг на уровне органов государственного управления ТК; – повышение уровня безопасности ТК на базе получения полной, достоверной и оперативной информации о происходящих изменениях, своевременного выявления негативных тенденций и для принятия соответствующих мер по их устранению и ликвидации последствий Значение характеристики не может изменяться участником закупки Основными задачами АСУ ТК являются: – автоматизация процессов прогнозирования развития транспортного комплекса и поддержки принятия управленческих решений; – автоматизация процессов мониторинга безопасности и устойчивости транспортного комплекса, управления в чрезвычайных и нештатных ситуациях; – автоматизация процессов управления программами и проектами развития и модернизации транспортного комплекса; – автоматизация процессов мониторинга состояния транспортного комплекса, в том числе с использованием набора ключевых показателей эффективности деятельности транспортного комплекса; – информационно-технологическая поддержка взаимодействия субъектов транспортного комплекса Российской Федерации, органов государственного управления и контроля, международных организаций на основе создания единой технологической среды взаимодействия и управления движением данных (и связанных с ними документов) в транспортном комплексе; – использование в процессах управления транспортным комплексом РФ современных технологий электронного документооборота и электронного обмена данными; – организация межведомственного электронного взаимодействия подразделений Министерства транспорта Российской Федерации, подведомственных агентств и службы с другими организациями 2.2. Назначение и цели развития и технической поддержки Модуля СЦ Назначение Модуля СЦ: – оперативный мониторинг нештатных и чрезвычайных ситуаций на транспорте ; – оповещение заинтересованных лиц и структур о нештатных и чрезвычайных ситуациях; – сбор, обработка и хранение данных о нештатных и чрезвычайных ситуациях. Целями развития Модуля СЦ являются: – расширение состава данных об оперативной обстановке на транспорте; – оптимизация процесса сбора данных об оперативной обстановке на транспорте; – повышение информированности пользователей за счет визуализация данных Модуля СЦ; – автоматизация процесса формирования отчетов о ЧС и нештатной ситуации на транспорте; – обеспечение информационного взаимодействия с заинтересованными организациями по вопросам ведения. Целями оказания услуг по технической поддержке являются: – обеспечение информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы; – поддержание параметров функционирования ППО Системы, удовлетворяющих требованиям производственных процессов, включая их непрерывность; – обеспечение бесперебойного функционирования ППО и своевременное устранение сбоев и аварийных ситуаций в Системе; – своевременное устранение уязвимостей при выявлении таковых, в соответствии с требованиями к обеспечению информационной безопасности; – адаптация, конфигурирование, коррекция программного обеспечения в соответствии с изменениями нормативно-правовой базы и запросами уполномоченных сотрудников органов государственной власти, включая выполнение процедур тестирования и участие в обновлениях ППО на стендах Заказчика; – обеспечение сохранения работоспособности ППО в изменяемой среде эксплуатации; – ведение документации по настоящему ТЗ, инициирование и актуализация документации на Систему по результатам обработки запросов Заказчика и внесении соответствующих изменений в ППО. Модуль СЦ применяется в деятельности Министерства транспорта Российской Федерации, подведомственных агентств и службы и другими организациями в соответствии с соглашениями об информационном обмене 3. ХАРАКТЕРИСТИКА ОБЪЕКТА АВТОМАТИЗАЦИИ 3.1. Описание объекта автоматизации АСУ ТК Объектом автоматизации являются процессы основной и обеспечивающей деятельности, направленные на управление транспортным комплексом, в том числе, процессы информационного взаимодействия с другими организациями и субъектами транспортного комплекса. АСУ ТК относится к государственным информационным системам, а также к информационным системам персональных данных и значимым объектам критической информационной инфраструктуры Российской Федерации. АСУ ТК соответствует требованиям, предъявляемым к: – ГИС второго класса защищенности в соответствии с приказом ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах»; – ИС персональных данных при обеспечении третьего уровня защищенности персональных данных в соответствии с требованиями постановления Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»; – значимым объектам КИИ Российской Федерации второй категории значимости с постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении Правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений». Модуль СЦ является подсистемой АСУ ТК. Перечень платформенных решений и функциональных задач АСУ ТК представлен в Таблице 1 Значение характеристики не может изменяться участником закупки Таблица 1 – Перечень платформенных решений и функциональных задач АСУ ТК № Наименование подсистемы/ функциональной задачи/ модуля Назначение 1 Подсистема сбора данных и централизованного хранилища данных Подсистема обеспечивает выполнение сбора данных в АСУ ТК, и в т. ч., в рамках функциональных задач «Формирование и ведение межрегионального транспортного баланса пассажирских перевозок в дальнем (межрегиональном) сообщении» и «Формирование и ведение транспортного паспорта региона» 2 Подсистема информационного взаимодействия Подсистема информационного предназначена для обеспечения информационного взаимодействия подсистем АСУ ТК, а также, взаимодействия АСУ ТК с АС федеральных органов исполнительной власти 3 Подсистема ведения нормативно-справочной информации и метаданных Подсистема предназначена для автоматизации функций формирования и актуализации справочников, классификаторов, реестров и регистров, необходимых для обеспечения информационной поддержки пользователей НСИ и интеграции подсистем АСУ ТК в части применения НСИ 4 Модуль СМЭВ Модуль взаимодействия со СМЭВ представляет собой набор сервисов взаимодействия: сервис синхронного взаимодействия и сервис отправки, осуществляющих дополнительную обработку сообщений, отправляемых в СМЭВ и принимаемых из СМЭВ 5 Геоинформационная подсистема Программное обеспечение геоинформационной подсистемы предназначено для обеспечения смежных подсистем АСУ ТК возможностью работы с картографической информацией, в том числе, отображения на электронных картах объектов транспортной инфраструктуры и получения информации о местоположении, характеристиках контролируемых транспортных объектов 6 Подсистема информационного портала АСУ ТК Подсистема информационного портала предназначена для отображения и входа в функциональные задачи АСУ ТК 7 Подсистема технического портала АСУ ТК Подсистема технического портала АСУ ТК предназначена для управления заявками пользователей и технологического документооборота заявок 8 Подсистема проектного архива АСУ ТК Подсистема проектного архива АСУ ТК предназначена для автоматизации деловых процессов должностных лиц Министерства транспорта Российской Федерации, подведомственных агентств и службы, в том числе, и процессов информационного взаимодействия внутреннего и внешнего характера 9 ФЗ «Реестр объектов» Функциональная задача предназначена для формирования и ведения единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации 10 ФЗ «СТП» Функциональная задача предназначена для организации информационно-аналитической поддержки процессов территориального планирования Российской Федерации в области федерального транспорта 11 ФЗ «МРТБ ПП» Функциональная задача предназначена для формирования и ведения межрегионального транспортного баланса пассажирских перевозок в дальнем (межрегиональном) сообщении 12 ФЗ «МДД» Функциональная задача предназначена для осуществления мониторинга дорожного движения 13 ФЗ «ТПР» Функциональная задача предназначена для формирования и ведения транспортного паспорта региона 14 ФЗ «Данные по грузообороту» Функциональная задача предназначена для обеспечения подсистем и пользователей АСУ ТК данными по грузообороту между Российской Федерацией и зарубежными странами 15 ФЗ «МЖТ» Функциональная задача предназначена для осуществления мониторинга железнодорожного транспорта 16 ФЗ «МГМП» Функциональная задача предназначена для осуществления мониторинга грузопотоков в морских портах с целью формирования единой цифровой среды мониторинга и планирования перевозок в/из портов Дальнего Востока 17 Модуль ГЭТ Модуль предназначен для получения, хранения данных инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по отдельно взятому предприятию-перевозчику. Формирования отчетов об инвентаризации с детальными данными по каждому разделу инвентаризации с маршрутизацией в муниципалитет / регион / Минтранс. Содержит агрегированные данные инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по всем перевозчикам, относящихся к данному муниципалитету. Формирует сводный отчет по муниципалитету по каждому разделу инвентаризации с маршрутизацией в регион / Минтранс. Формирует агрегированные данные инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по всем перевозчикам, относящиеся к данному региону и по всем муниципалитетам, относящимся к данному региону. Аналитические и статистические данные о состоянии ГЭТ региона. Содержит данные о видах транспорта, цифровых транспортных сервисах и платежных инструментах Региона. Формирует сводный отчет по каждому разделу инвентаризации с маршрутизацией в Минтранс. Формирует агрегированную статистику и аналитику по всем регионам страны в разрезе транспортных средств, маршрутов, пассажиропотоков, инфраструктуры ГЭТ. Данные о рейтинге регионов и перевозчиков на основании выбранных параметров, документооборот с участниками Системы: получение подписанных печатных форм, их утверждение, возврат на доработку. 18 Модуль iМинтранс Модуль создан для отчета по ключевым показателям транспортного комплекса России (Отраслевые и статистические показатели, исполнение бюджета, исполнение поручений, аналитика СМИ, происшествия по видам транспорта). 19 Модуль СЦ Модуль СЦ предназначен для оперативного мониторинга нештатных ситуаций транспортной отрасли, оповещения заинтересованных лиц и структур и предоставления данных о нештатных ситуациях АСУ ТК осуществляет идентификацию и авторизацию посредством Единой системы идентификации и аутентификации (ЕСИА). Информационный обмен с внешними информационными системами осуществляется посредством СМЭВ 3 и СМЭВ 4. АСУ ТК развернута на вычислительных мощностях ГЦОД СИЦ Минтранса России 3.2. Описание и текущее состояние объекта автоматизации Модуля СЦ Объектом автоматизации является процесс организации мониторинга информации о НС и ЧС на транспорте. Предметом деятельности Учреждения являются следующие функции: – информационное обеспечение в области транспортной безопасности, защиты населения и территорий от чрезвычайных ситуаций природного и техногенного характера в транспортном комплексе; – подготовка справочных материалов при угрозе возникновения и возникновении чрезвычайных ситуаций и иных происшествий в транспортном комплексе; – взаимодействие и обмен оперативной информацией с органами управления Единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций; – организация оперативного мониторинга обстановки на объектах транспорта при угрозе и возникновении чрезвычайных ситуаций и иных происшествий. Перечень компонентов Модуля СЦ и выполняемые ими функции представлены в Таблице 2 Таблица 2. Перечень компонентов Модуля СЦ и их функции № п/п Компонент Выполняемые функции 1 Регистрация событий – ведение карточки события; – удаление комментария; – динамическое отображение существующих событий в заданном радиусе и за заданный период; – возможность автоматической проверки вводимых данных в части количества пострадавших; – отображение карточки ОТИ, ТС в соответствии с ФЗ Реестр объектов; – сохранение и отображение версии карточки события; – привязка события к координатам по картографической основе; – указание признака выполнения действия по отработке события; – перевод статуса события; – закрытие карточки события; – публикация информации о событии в канале мессенджера; – возможность перехода из карточки события на картографическую основу для просмотра местоположения события 2 Визуализация – отображение событий на картографической основе в виде пиктограмм; – масштабирование карты; – отображение краткой карточки события при выборе события на картографической основе; – отображение списка событий; – отображение карточки события; – отображение журнала действий пользователя; – отображение дополнительной информации (текстовая информация и приложенные файлы); – отображение справки о событиях и отчета о событиях; – отображение фильтров и количества отфильтрованных объектов; – отображение результатов поиска; – отображение статистики по событиям на экране; – возможность создания события с картографической основы; – отображения картографических слоев в зависимости от примененных фильтров; – возможность настройки шага картографической сети; – возможность настройки географической точки центра карты; – отображение количества непрочитанных сообщений; – возможность перехода к детальной карточке события из краткой карточки события при выборе события на картографической основе 3 Информирование – ведение справочника способов оповещения (веб-интерфейс, мессенджер); – формирование сценария выполнения оповещения (настройка условий, способа, параметров оповещения); – выполнение оповещений пользователей 4 Отчетность – формирование отчета и справки о событиях; – фильтрация событий для выгрузки в справку о событиях или в отчет о событиях 5 Администрирование – ведение ролей пользователей; – ведение учетных данных пользователей; – ведение справочника организаций; – ведение справочника групп системы мгновенного обмена сообщениями; – выполнение исходящего звонка на контактный телефонный номер организации; – формирование матрицы эскалации событий Архитектура Модуля СЦ представлена на рисунке 1. Рисунок 1. Архитектура Модуля СЦ 3.3. Состав используемого ПО Модуля СЦ Программная архитектура Модуля СЦ разработана как трехуровневая клиент-серверная архитектура. Архитектура включает в себя следующие уровни: • уровень представления – презентационный уровень, обеспечивающий взаимодействие с пользователя с клиентскими приложениями с использованием веб-браузера («тонкий» клиент); • уровень приложений – реализован в виде сервисов, обеспечивает обработку запросов, поступающих от клиентских приложений, формирование ответов на запрос в доступном пользователю виде (формирование пользовательских интерфейсов); • уровень хранения данных – реализуется как сервер БД и обеспечивает хранение и целостность хранимых данных, создание резервных копий, ведение журнала транзакций, восстановление данных после сбоев. Программная архитектура Модуля СЦ включает в себя сервисы и интерфейсы, указанные в Таблице 3. Таблица 3. Программная архитектура Модуля СЦ Программный сервис/интерфейс Технологии реализации Уровень представления Интерфейс пользователя и администратора (front-end) Javascript Уровень приложений Сервис (GateWay) Kotlin Сервис геокодирования (geocoding-service) Kotlin Сервис уведомлений (notifiсation-service) Kotlin Сервис работы с файлами (file-service) Kotlin Сервис отчетности (report-service) Kotlin Сервис управления событиями (event-service) Kotlin Сервис информирования через мессенджер (messenger-notifier) Python Сервис внешних интеграций (integration-service) Сбор информации из внешних систем и сервисов Брокер сообщений Kafka Уровень хранения данных Файловое хранилище MinIO S3 СУБД Postgres Pro Enterprise 3.4. Информационное взаимодействие программных сервисов и интерфейсов Модуля СЦ Объект автоматизации функционирует в распределенной информационной среде. Обмен данными осуществляется по защищенным каналам связи (в том числе ведомственным сетям передачи данных). Источники информации включают: · внешние автоматизированные системы (органов государственной власти); · внутренние базы данных (реестры объектов транспортной инфраструктуры, паспорта регионов и пр.); · оперативная информация от персонала, поступающая через автоматизированные рабочие места (АРМ) и мобильные устройства. 3.4.1. Взаимодействие Модуля СЦ со смежными подсистемами АСУ ТК Модуль СЦ входит в состав АСУ ТК и взаимодействует со следующими ее функциональными задачами и подсистемами: · Функциональной задачей «Формирование и ведение единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации» (ФЗ «Реестр объектов»); · Геоинформационной подсистемой АСУ ТК (П-ГИС); · Подсистемой ведения нормативно-справочной информации и метаданных (П-НСИ); · Подсистемой сбора данных и централизованное хранилище данных (П-СД); · Подсистемой информационного взаимодействия (П-ИВ). 3.4.2. Взаимодействие с внешними информационными системами Список внешних информационных систем, с которыми осуществляется взаимодействие Модуля СЦ: · ЕСИА; · мессенджер; · Яндекс Геокодер; · Информационная система «Централизованная система сбора информации систем-112»; · ПВК «Поиск-Море», АИС РПТ; · облачная АТС 3.5. Требования к эксплуатации Применяемое в Системе программное обеспечение, программно-аппаратные и аппаратные комплексы должны соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации» 4. ТРЕБОВАНИЯ К МОДУЛЮ СЦ Таблица 6. Категории обращений и заявок Категория Примеры Запрос на обслуживание Подготовка SQL запроса к СУБД для решения прикладной задачи и д.р. – запрос на любое действие, не являющееся запросом информации и несовершенный на основе происшествия, прямо или косвенно влияющего на работу Модуля СЦ Консультация «Где взять / куда обратиться...?», «Как сделать / выполнить…», «Как это работает…?» - запрос, имеющий своей целью получение информационной поддержки Инцидент Разбор ошибок/сбоев и подготовка материалов (корректировочных релизов, инструкций) для Заказчика для устранения ошибок/сбоев, которые приводят к частичному и полному нарушению работоспособности всех или отдельных функций ППО. Подготовка изменения и материалов, необходимых для проведения аварийно-восстановительных работ для возобновления работоспособности Модуля СЦ ЗНИ Подготовка изменений, связанных с изменением, улучшением/оптимизацией Модуля СЦ и выводом новой модифицированной функциональности в штатном режиме. Подготовка изменений, связанных с модификацией существующих и/или реализация новых интеграционных механизмов для получения/обработки данных внешних систем. Подготовка изменений графического интерфейса по требованиям Заказчика. Перечень статусов обращений (заявок) приведен в пункте 3.3. Регламента оказания Услуг. Назначение обращению (заявке) статуса «Закрыто» осуществляется Заказчиком только после получения от инициатора обращения (заявки) подтверждения о его исполнении или нахождения обращения (заявки) в статусе «Выполнено» и отсутствия повторных вопросов/запросов по данному обращению (заявки) в течение 5 рабочих дней. Категории и статусы обращений (заявок) могут быть скорректированы в процессе оказания услуг исключительно по согласованию с Заказчиком Значение характеристики не может изменяться участником закупки 4.3.6. Требования к услугам технической поддержки 4.3.6.1. Требования к организации третьего уровня технической поддержки Основными задачами организации третьего уровня технической поддержки в рамках оказания услуг по технической поддержке Модуля СЦ являются организация эксплуатационной службы Подрядчика, проверка готовности технических и программных средств для обеспечения непрерывного функционирования ППО Модуля СЦ. Подрядчиком должны быть проведены организационно-штатные и подготовительные мероприятия (в т. ч. технические) в рамках организации технической поддержки Модуля СЦ. Подрядчик в течение 5 (пяти) рабочих дней с даты заключения Контракта должен: – определить и направить Заказчику документ «Перечень уполномоченных специалистов», содержащий контактную информацию (ФИО, должность, адрес рабочей электронной почты) лиц, ответственных за оказание услуг со стороны Подрядчика; – обеспечить подключение специалистов Подрядчика к Системе регистрации обращений (заявок) (СРО предоставляется Заказчиком) для оказания услуг; – согласовать с Заказчиком способ доступа Подрядчика к Модулю СЦ. Результат выполнения мероприятий фиксируется в Протоколе проверки результатов организационно-штатных и подготовительных мероприятий (см. Приложение Д к настоящему ТЗ) 4.3.6.2. Требования к услугам информационно-консультационной поддержки работников Заказчика и пользователей Модуля СЦ Услуги информационно-консультационной поддержки сотрудников Заказчика включают: – обработку обращений и заявок, поступивших от сотрудников Заказчика; – консультирование сотрудников Заказчика и пользователей Модуля СЦ; – актуализацию документации, и других материалов по работе с Модулем СЦ при необходимости. – консультирование и разработку рекомендаций по настройке Модуля СЦ (без изменения программного кода), включая изменение настроек функционирования; – консультации по вопросам использования, настройки и возможностям Модуля СЦ; – консультации по проведению превентивных мер для недопущения аварийных ситуаций в Модуле СЦ; – консультации по предварительной диагностике и локализации возникшей неисправности Модуля СЦ; – консультации по вопросам обеспечения информационной безопасности Модуля СЦ и настройки функций, обеспечивающих корректную работу программного обеспечения для совершения юридически значимых действий в Модуле СЦ; – другие вопросы, связанные с работой Модуля СЦ. 4.3.6.2.1. Требования к порядку оказания услуг информационно-консультационной поддержки работников Заказчика и пользователей Модуля СЦ Подрядчик выполняет консультирование сотрудников Заказчика и пользователей Модуля СЦ. Консультация может быть предоставлена по согласованным с представителем Заказчика каналам коммуникации с регистрацией результата консультации в СРО Подрядчиком. Детальный порядок оказания консультационных услуг определен в Регламенте оказания Услуг 4.3.6.3. Требования к услугам по решению инцидентов, связанных с работой ППО Подрядчик устраняет неисправности Модуля СЦ, связанные с работой ППО, выявленные в рамках оказания услуг согласно настоящему Техническому заданию, при этом в зону ответственности Подрядчика не входит устранение неисправностей, выявленных на стороне Заказчика и на стороне третьих лиц (провайдера связи, поставщика электропитания и т.д.). Первичная диагностика выявленной неисправности проводится на 1 и 2 уровнях технической поддержки и не входит в зону ответственности Подрядчика. Если при проведении первичной диагностики и попытке устранить неисправности на 1 и 2 уровнях технической поддержки, данную неисправность устранить не удалось и в процессе диагностики было выявлено, что проблема связана с работоспособностью ППО, обращение (заявка) назначается сотруднику Подрядчика, ответственному за оказание услуг технической поддержки 3 уровня. Инцидентами вне зоны ответственности Подрядчика являются: – работоспособность функциональности, выходящая за рамки текущей реализации функций в Модуле СЦ и/или являющаяся расширением требований Заказчика к функциям Модуля СЦ; – проведение профилактических и плановых работ, согласованных с Заказчиком; – нарушение работоспособности функций Модуля СЦ, вызванное проведением работ на стороне Заказчика Работы по устранению неисправности приостанавливаются (по согласованию с Заказчиком) в следующих случаях: – если Подрядчиком в результате диагностики выявлено, что неисправность находится в зоне ответственности Заказчика. Подрядчик информирует Заказчика о выявленной неисправности в зоне его ответственности по согласованным каналам связи; – требуется действие со стороны Заказчика – до момента выполнения данного действия Заказчика. Заказчик информируется о необходимых действиях по согласованным каналам связи; – отсутствие возможности связаться со специалистами Заказчика, участие которых необходимо для устранения неисправности; – требуется доставить оборудование на объект – до момента доставки и установки оборудования. В случаях, представленных выше, время приостановки работ не входит в учет продолжительности устранения неисправности. Учет времени устранения неисправности Подрядчиком считается с момента назначения Инцидента специалисту Подрядчика, ответственному за оказание услуг технической поддержки 3 уровня. Подтверждение необходимости приостановления работ находится в зоне ответственности Подрядчика. Приостановление сроков выполнения задач в соответствии с настоящим пунктом подтверждается Заказчиком по мотивированному обращению Подрядчика в СРО, основанному на данных диагностики или на иных фактических обстоятельствах В случае непринятия Подрядчиком необходимых мер по информированию Заказчика (отсутствие надлежащего обращения от Подрядчика или отсутствие уведомления о необходимости осуществления каких-либо действий Заказчиком) не может являться основанием для приостановления работ по устранению неисправности. В отдельных случаях Подрядчику может потребоваться выполнение технологических работ для устранения причин неисправности или недопущения повторения их в будущем. Для обеспечения устранения неисправности Модуля СЦ Заказчиком проводится классификация в соответствии с приоритетами по степени срочности их устранения. Продолжительность устранения неисправности, а также периодичность информирования Подрядчиком Заказчика о ходе устранения неисправности, определены в Регламенте оказания услуг. При подаче обращения (заявки) наивысшего приоритета через СРО Заказчик должен дополнительно проинформировать службу поддержки Подрядчика о созданном обращении (заявки) по телефону уполномоченного сотрудника Подрядчика. При этом временем подачи обращения (заявки) считается время подачи обращения (заявки) через СРО 4.3.6.4.1. Требования к проведению изменений Основанием для внесения изменений является запрос от Заказчика. Все активности по внесению изменений должны быть согласованы с Заказчиком, а действия Подрядчика при оказании данной услуги должны быть зафиксированы. В рамках данного Технического задания изменениями считаются локальные доработки функционала Модуля СЦ, которые не должны приводить к необходимости выполнения дополнительных аттестационных испытаний или переаттестации АСУ ТК в соответствии с п. 33 приказа от 29.04.2021 № 77 «Об утверждении Порядка организации и проведения работ по аттестации объектов информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну». При необходимости внесения изменений в Модуль СЦ, не связанных с критичным инцидентом, существенно нарушающим работоспособность Модуля СЦ, Заказчик направляет Подрядчику обращение (заявку), в котором излагает суть изменения, которое требуется внести в Модуль СЦ. Исполнитель, в течение 3 (трех) рабочих дней с момента поступления соответствующего обращения (заявки), оценивает техническую возможность реализации запрашиваемого изменения и варианты реализации. По итогу проведения оценки Подрядчик направляет Заказчику заключение о возможности реализации данного изменения с описанием возможных вариантов реализации и согласует с Заказчиком проведение данного изменения При проведении работ по изменению и адаптации Подрядчик должен: – обеспечить выполнение требований безопасной разработки программного обеспечения; – обеспечить предварительное проектирование технических решений и согласование с Заказчиком проекта реализации изменения; – использовать семантическое версионирование (SemVer) в работе, передать Заказчику все артефакты разработки (исходный код и сторонние библиотеки, конфигурации, сборочные и собранные образы и др.); – подготовить полноценное описание функционала, включенного в релиз, с необходимыми схемами и пояснениями к обновлению на стендах Заказчика; – обеспечить тестирование разработанного функционала на стендах Заказчика силами Подрядчика; – решение о переносе измененного ППО на продуктивный стенд принимается Заказчиком по итогу результатов проведенного тестирования; – обеспечить техническое сопровождение процедуры тестирования ППО и переноса измененного ППО на продуктивный стенд Заказчика; – обеспечить экстренное внесение соответствующих изменений в случае выявления некорректной работы продуктивного стенда Заказчика после проведения обновления по итогам разработанного изменения в кратчайшие сроки; – актуализировать при необходимости комплект эксплуатационной документации: o руководство пользователя; o руководство администратора; o иные документы (при необходимости). Результат выполнения изменений должен быть отражен в Отчете по оказанию услуг. Типы и приоритеты изменений могут быть скорректированы в процессе оказания услуг исключительно по согласованию с Заказчиком 4.4.7. Требования к программному обеспечению Общесистемное ПО, используемое в составе Модуля СЦ, должно быть зарегистрировано в Едином реестре российских программ для электронных вычислительных машин и баз данных и соответствовать рекомендованным показателям эффективности и соответствующим им значениям индикаторов эффективности перехода подведомственных организаций на использование российского ПО, заданных Приказом Минцифры России от 18.01.2023 № 21 «Об утверждении методических рекомендаций по переходу на использование российского программного обеспечения, в том числе на значимых объектах критической информационной инфраструктуры Российской Федерации, и о реализации мер, направленных на ускоренный переход органов государственной власти и организаций на использование российского программного обеспечения в Российской Федерации». Применяемое в системе программное обеспечение должно соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации, постановления Правительства Российской Федерации от 23 декабря 2024 г. № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц» Прикладное программное обеспечение должно отвечать следующим требованиям: – совместимость программных продуктов в части используемых технических средств, системного программного обеспечения и общесистемной инфраструктуры в пределах требований к техническому обеспечению, а также их информационная совместимость в пределах требований к информационному обмену; – обеспечение трехуровневой архитектуры с разделением на уровень хранения данных (сервер БД), уровень бизнес-логики (сервер приложений) и уровень представления ( 4.4.7.1. Требования к инструментам разработки и процессу контроля версий программного обеспечения 4.4.7.1.1. Система контроля версий Для управления исходным кодом должна использоваться система контроля версий кода, развернутая в инфраструктуре Заказчика. 4.4.7.1.2. Правила именования веток Имя ветки должно соответствовать следующему формату: / / Категории веток: ? feature/ — разработка новой функциональности, а также рефакторинг или удаление существующей; ? fix/ — исправление ошибок; ? hotfix/ — срочные исправления, применяемые в обход стандартного процесса разработки; ? test/ — для проведения экспериментов, не влияющих на основную разработку. Идентификатор задачи: после категории указывается ссылка на задачу (issue) в системе контроля версий кода. Описание: добавляется краткое описание решаемой задачи в формате kebab-case (слова разделяются дефисами, например, add-user-auth). Примеры именования веток: ? feature/#123/add-payment-integration; ? fix/#45/correct-calculation-logic; ? hotfix/#67/urgent-database-connection-patch. 4.4.7.1.3. Правила именования коммитов Сообщение коммита должно соответствовать соглашению Conventional Commits и состоять из категории и описания: : ? fix — исправление ошибки. Примеры сообщений коммитов: ? feat: добавление формы регистрации пользователя; ? fix: исправление ошибки валидации email-адреса; ? refactor: оптимизация алгоритма сортировки данных; ? chore: обновление версий в файле dependencies. 4.4.7.1.4. Модель ветвления В процессе разработки используются следующие основные ветви: ? main / master — стабильная ветка, содержит только код, прошедший полное тестирование и развернутый в продуктивных контурах; ? dev — ветка для интеграции завершенных задач, предназначенная для сборки и тестирования в тестовых средах. Попадание кода в main осуществляется только через Merge Request (MR) из dev 4.5.5. Требования к информационной безопасности Работы по защите информации/информационной безопасности, не включенные в состав настоящего раздела, требуемые в соответствии с требованиями постановления Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации», а также нормативно правовых актов в области защиты персональных данных и обеспечения безопасности объектов критической информационной инфраструктуры, будут проведены в рамках исполнения отдельного контракта, заключенного по результатам отдельной закупочной процедуры (не является частью данного ТЗ), включающего: – определение актуальных угроз безопасности информации и актуализация модели угроз безопасности информации (при необходимости); – выполнение требований о согласовании технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России в установленном порядке; – выполнение требований по устранению Подрядчиком замечаний и недостатков, в случае их выявления при согласовании Заказчиком технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России; – выполнение требований к классу защищенности ГИС, уровню защищенности персональных данных и категории значимости объекта КИИ РФ, установленных для Головного центра обработки данных ФГБУ «СИЦ Минтранса России» (далее – ГЦОД); – определение перечня объектов защиты информационной системы; – описание (актуализированных) требований к системе защиты информации, а также к мерам защиты информации информационной системы в зависимости от установленных классов защищенности, уровня защищенности персональных данных и категории значимости объектов КИИ РФ (приказы ФСТЭК России № 21, 117, 239); – выполнение требований к мерам по защите ГИС от атак, направленных на отказ в обслуживании, в соответствии с пунктами 30, 34, 59, 63 Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений, утвержденных приказом ФСТЭК России от 11.04.2025 № 117; – описание (актуализированных) требований по защите информации, подлежащих реализации в информационно телекоммуникационной инфраструктуре ГЦОД; – выполнение требований о применении сертифицированных средств защиты информации, включая их классы защиты и уровни доверия; – выполнение требований о запрете использования с 01.01.2025 органами (организациями) средств защиты информации странами происхождения, которых являются иностранные государства в соответствии с пунктом 6 Указа Президента Российской Федерации от 01.05.2022 № 250; – выполнение требований по обеспечению непрерывного взаимодействия с ГосСОПКА в установленном порядке; 4.5.9.12. Передача Заказчику комплекта документов, материалов и сведений, предусмотренных нормативными правовыми актами Российской Федерации в сфере информационных технологий, защиты информации, правовой защиты интересов государства в области интеллектуальной собственности, включая документы, подтверждающие отказ авторов (разработчиков) от исключительных прав на передаваемые объекты интеллектуальной собственности в пользу Подрядчика, с проектами заявок на государственную регистрацию в установленном порядке прав Заказчика на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, базы данных, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, осуществляется Подрядчиком в составе отчетной документации, предусмотренной условиями Контракта. 4.5.9.13. По результатам выполнения работ по развитию системы должны быть подготовлены материалы для регистрации доработанной версии Системы (объекта учета) в НФАП в соответствии с требованиями постановления Правительства Российской Федерации от 30 января 2013?г. №?62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин» (с изменениями и дополнениями) в части обязательности размещения результатов работ в национальном фонде алгоритмов и программ для электронных вычислительных машин 4.5.10. Требования по стандартизации и унификации К Модулю СЦ предъявляются следующие требования в части стандартизации и унификации: – работы по развитию Модуля СЦ должны производиться в соответствии с действующими стандартами и нормами Российской Федерации; – при создании и модернизации элементов Модуля СЦ следует руководствоваться действующими в Российской Федерации национальными стандартами и другими нормативно-техническими документами; – используемые оборудование и материалы, подлежащие обязательной сертификации, должны иметь соответствующие сертификаты; – ПО Модуля СЦ должно проектироваться и разрабатываться с учётом обеспечения требований унификации; – применяемые при создании Модуля СЦ технические (форматы данных, протоколы передачи и прочие) и организационные (регламенты, требования, инструкции) решения должны быть доступны и документированы в виде, достаточном для независимой (без обращения к Подрядчику) реализации третьими сторонами; – термины, обозначения и наименования, используемые в ПО, должны быть стандартизованы и унифицированы, выполнены на русском языке; – взаимодействие элементов и их внешнее поведение должно быть реализовано одинаково и производиться по единым правилам 4.3.6.3.1. Требования к порядку оказания услуги по решению инцидентов, связанных с работой ППО При поступлении от Заказчика обращения (заявки), являющегося неисправностью в работе Модуля СЦ (инцидентом), Исполнитель реагирует на инцидент в СРО в срок не более 30 минут с момента поступления. В случае необходимости, для решения инцидента ответственный специалист должен связаться с инициатором обращения (заявки) для уточнения условий воспроизведения проблемы или для получения дополнительных сведений. После получения необходимых сведений от инициатора обращения (заявки) ответственный специалист производит диагностику с целью выявления причины инцидента и возможных путей устранения. В случае, если инцидент невозможно решить без получения дополнительных сведений от инициатора, и не удается связаться с инициатором в течение пяти рабочих дней, обращение (заявка) отклоняется в связи с недостатком данных для его решения, Заказчику направляется уведомление об отклонении обращения (заявки). Время, в течение которого невозможно связаться с инициатором, вычитается из общего времени обработки обращения (заявки). Все попытки связаться с инициатором должны фиксироваться с указанием даты и времени попытки, используемого способа связи (номер телефона, адрес электронной почты) и результата попытки (не удалось дозвониться, абонент недоступен, и т.д.) Факт и время решения инцидента должны быть зафиксированы и отражены в СРО. В случае, если причиной сбоя в работе Модуля СЦ является выход из строя аппаратного обеспечения или неработоспособность смежной информационной системы, время работы над инцидентом приостанавливается до момента устранения неисправности. В ходе решения инцидентов могут быть выявлены дефекты ППО Модуля СЦ. В случае обнаружения дефектов ППО, Подрядчик информирует об этом Заказчика. Исполнитель может быть привлечен к проверке результата устранения дефекта по инициативе Заказчика. Приоритеты инцидентов приведены в Приложении Б к ТЗ. Детальный порядок оказания услуги по решению инцидентов, связанных с работой ППО Модуля СЦ определен в Регламенте оказания Услуг 4.3.6.4. Требования к услугам адаптационного, конфигурационного и коррекционного сопровождения и доработки Модуля СЦ (в рамках действующих программных модулей и функциональностей) Услуги адаптационного, конфигурационного и коррекционного сопровождения и доработки Модуля СЦ включают: – управление изменениями и адаптация функций Модуля СЦ; – изменение настроек функционирования Модуля СЦ; – внесение изменений и/или модификаций Модуля СЦ (в рамках действующих программных модулей и функциональностей), направленных на улучшение их работоспособности и функциональных возможностей; – подготовка и передача Заказчику SQL запросов в СУБД для получения агрегированной информации из Модуля СЦ, которую невозможно получить с использованием графического пользовательского интерфейса; – адаптация модулей интеграций со смежными информационными системами 4.3.6.4.2. Требования к изменению настроек функционирования Изменение настроек функционирования может проводиться в рамках допустимых пределов изменения функционирования, заложенных в архитектуру Модуля СЦ. Изменение настроек функционирования включает в себя изменение данных и справочников, изменение форм документов, формируемых Модулем СЦ, изменение и настройку форматов и версий передачи данных в смежные системы. Доработка программного кода Модуля СЦ может допускаться (в случае необходимости) при выполнении работ по адаптации функций Модуля СЦ в части изменения формата передачи данных в смежные информационные системы при условии соблюдения требований пункта 29.3 приказа ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации» 4.3.6.5. Требования к услугам по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности По запросу Заказчика Подрядчик должен провести работу по приведению ППО в соответствие с требованиями по обеспечению информационной безопасности. Критичность уязвимости оценивается в соответствии в соответствии с Методическим документом ФСТЭК России «Методика оценки уровня критичности уязвимостей программных, программно-аппаратных средств» (утвержден ФСТЭК России 30.06.2025), а также с учетом ГОСТ 56545-2015 и международными стандартами (CVSS 3.0 и выше), и задает необходимый срок устранения. В процессе проведения Заказчиком обследования Модуля СЦ и выявления уязвимостей в ППО, связанных с исходным кодом Модуля СЦ и/или используемыми компонентами (библиотеками), Заказчик направляет Подрядчику обращение (заявку) на устранение, с указанием критичности и срочности принятия мер по устранению в СРО. Подрядчик при оказании услуг по обновлению или устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности должен: – провести анализ уязвимостей и связанных с ними исходным кодом и/или используемыми компонентами (библиотеками); – выработать варианты устранения указанных уязвимостей и согласовать с Заказчиком их реализацию; – своевременно внести изменения в исходный код Модуля СЦ и/или используемые компоненты (библиотеки) и подготовить соответствующее обновление; – провести обновление Модуля СЦ в тестовом контуре Заказчика и проинформировать Заказчика о готовности проведения тестирования; – протестировать успешность обновления или устранения уязвимостей в ППО и корректность функционирования Модуля СЦ на тестовом контуре, совместно с Заказчиком; – при невозможности незамедлительного устранения уязвимости приоритетов «Критический» и «Высокий» Подрядчик обязан предоставить исчерпывающий список причин и согласовать план достаточных компенсирующих мер с ответственными сотрудниками Заказчика. Результат внесения изменений отображается в соответствующей записи в СРО и в составе Отчета об оказанных услугах 4.3.6.5.1. Требования к порядку оказания услуг по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности Подрядчик в соответствии с приоритетами обращений и контрольными сроками исполнения (см. Приложение Б к ТЗ) оценивает техническую возможность и сроки устранения уязвимостей, и реализацию обновления Модуля СЦ. По итогу проведения оценки Подрядчик направляет в заявке СРО Заказчику заключение о возможности устранения уязвимостей и/или обновления в ППО и согласует с Заказчиком проведение данных работ 4.4.7.1.5. Требования к используемым зависимостям (библиотекам) Все внешние зависимости проекта должны быть зафиксированы с указанием точных версий. Для контроля версий зависимостей в репозиторий обязательно должны быть включены следующие файлы: · Для JavaScript: package-lock.json или yarn.lock; · Для Python: requirements.txt (с зафиксированными версиями) или Pipfile.lock; · Для Go: go.mod и go.sum; Загрузка всех зависимостей должна производиться исключительно через внутренний прокси-репозиторий Заказчика, настроенный в соответствующем системе менеджере пакетов. Запрещается: · Использование плавающих версий (например, ^1.2.3, ~4.5.0, latest); · Использование библиотек, содержащих критические уязвимости, в том числе зарегистрированные в реестре CVE (Common Vulnerabilities and Exposures). 4.4.7.1.6. Требования к процессу непрерывной интеграции (CI) Сборка программного обеспечения, включая этапы компиляции, тестирования и анализа кода, должна выполняться исключительно в инфраструктуре непрерывной интеграции Заказчика. 4.4.7.1.7. Требования к хранению артефактов сборки Все артефакты сборки (результирующие пакеты, Docker-образы и т.д.) подлежат обязательному хранению в предназначенной для этого инфраструктуре Заказчика (артефакторий). Запрещается размещение финальных артефактов сборки на сторонних ресурсах 4.4.8. Требования к техническому обеспечению Количество серверов, подключаемых и настраиваемых сервисов, их параметров, схемы соединений и настройки межсетевого взаимодействия должны быть согласованы с Заказчиком на этапе № 1 Техническое проектирование. Доступ к комплексу технических средств предоставляется Заказчиком по письменному запросу Подрядчика. Применяемые в Системе программно-аппаратные и аппаратные комплексы должны соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации», требованиям Постановления Правительства Российской Федерации от 23 декабря 2024 г. № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц». Модуль СЦ, работающий в составе АСУ ТК, развернут на вычислительных мощностях ГЦОД СИЦ Минтранса России 4.5. Общие технические требования 4.5.1. Требования к численности и квалификации персонала и пользователей Модуля СЦ Программное обеспечение Модуля СЦ не должно требовать изменения штатной численности персонала Заказчика. Программное обеспечение Модуля СЦ не должно требовать наличия у пользователей дополнительной квалификации в сфере информационных технологий, кроме базовых знаний в обращении с персональным компьютером, базовых навыков работы в интернет-обозревателях и знаний о Модуле СЦ в объеме документов Руководство пользователя, Руководство администратора – выполнение требований по обеспечению в автоматизированном режиме с Национальной системой противодействия DDoS-атакам (НСПА) Центра мониторинга и управления сетью связи общего пользования ФГУП «ГРЧЦ» в рамках реализации мер по защите ГИС от атак, направленных на отказ в обслуживании; – детализированные требования к составу и содержанию работ по аттестации, а также к их результатам в соответствии с пунктами 13, 15 и 16 требований приказа ФСТЭК России от 29.04.2021 № 77 «Об утверждении Порядка организации и проведения работ по аттестации объектов информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну» 4.5.5.1. Требования к безопасности исходного кода Процесс разработки исходного кода должен соответствовать требованиям законодательства, нормативным правовым актам Российской Федерации, приказу ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по безопасности значимых объектов критической информационной инфраструктуры Российской Федерации», а также учитывать отраслевые практики безопасной разработки. Подрядчик должен предоставить Заказчику Руководство по безопасной разработке программного обеспечения (далее – Руководство), применяемое при разработке исходного кода Модуля СЦ. Руководство должно содержать: · описание процесса безопасной разработки и ролевой модели, отражающей зоны ответственности сотрудников Подрядчика; · описание процессов моделирования, оценки и формирования мер предотвращения угроз, применяемых Подрядчиком; · описание методик, применяемых Подрядчиком при разработке исходного кода (правила написания кода); · описание методик, периодичности проведения и инструментария статического, динамического, композитного и фаззинг тестирования исходного кода, включающего критерии отбора релизных версий ПО, применяемые Подрядчиком в процессе разработки; · описание механизмов безопасности в процессе сборки и доставки (безопасность образов, безопасность секретов, безопасность окружения и сборочной среды), применяемые Подрядчиком; · утвержденные шаблоны отчетной документации (в том числе акты), в соответствии с которыми Заказчик принимает результаты проверок (артефакты сборочного процесса), проведенных Подрядчиком; · описание процедур отслеживания и исправления обнаруженных ошибок и уязвимостей программного обеспечения; · описание способов и сроков доведения Подрядчиком до Заказчика информации об уязвимостях программного обеспечения, о компенсирующих мерах по защите информации или ограничениях по применению программного обеспечения, способов получения пользователями программного обеспечения его обновлений, проверки их целостности и подлинности Подрядчик должен обеспечить реализацию и проведение внутренних проверок мер по разработке безопасного ПО, приведенных в Руководстве. Подрядчик должен провести анализ угроз безопасности информации программного обеспечения в соответствии с ГОСТ 58412-2019 «Защита информации. Разработка безопасного программного обеспечения. Угрозы безопасности информации при разработке программного обеспечения». Подрядчик должен провести испытания по выявлению уязвимостей в программном обеспечении Системы: · проведение статического анализа исходного кода программы; · проведение динамического анализа исходного кода программы; · проведение композитного анализа исходного кода и образов программы; · проведение фаззинг-тестирования программы, направленного на выявление в ней уязвимостей. Испытания по выявлению уязвимостей в программном обеспечении Системы должны быть проведены в рамках: · предварительных испытаний; · опытной эксплуатации; · приемочных испытаний 4.5.11. Требования к показателям назначения 4.5.11.1. Требования к показателям назначения мероприятий по развитию Модуля СЦ В рамках выполнения работ по развитию Модуля СЦ, предусмотренных ТЗ, показатель назначения «Количество пользователей» должен соответствовать значениям, приведенным в данном разделе. Пояснения по показателям, связанным с количеством пользователей, приведены в Таблице 8. Таблица 8. Определения показателей, связанных с количеством пользователей в Модуле СЦ № Показатель Определение Расчетное количество пользователей Количество пользователей, работу которых должен обеспечить Модуль СЦ к моменту сдачи работ по Контракту с учетом достижения всех показателей назначения Расчетное количество одновременно работающих пользователей Количество одновременно работающих пользователей, работу которых должен обеспечивать Модуль СЦ к моменту сдачи работ по Контракту с учетом достижения всех показателей назначения Значения показателей количества пользователей, достижение которых необходимо обеспечить, представлено в Таблице 9 Таблица 9. Значения показателей количества пользователей № Показатель Значение 1. Расчетное количество пользователей 1 000 2. Расчетное среднее количество одновременно работающих пользователей 200 Развитие Модуля СЦ должно быть направлено на достижение следующего эффекта (показателя), подставленного в мероприятии 103.002 «Информационно-аналитическая система регулирования на транспорте (АСУ ТК)» ВПЦТ Минтранса России: Выполнение работ по развитию Модуля СЦ предусмотрено мероприятием по развитию АСУ ТК, приведенном в ВПЦТ Минтранса России на 2026-2028 гг: № 103.002 «АСУ ТК» в составе ИТ расхода 103.26.000005 «Развитие предусматривает реализацию ОКР и эффектов, приведенных в Таблице 10. Таблица 10. ОКР и эффекты, приведенные в ВПЦТ Минтранса России на 2026 г. № ОКР Дата ОКР Эффекты 1 Обеспечено информационное взаимодействие с Минобороны России о происшествиях на транспортных объектах 25.12.2026 Сокращено время сбора и передачи сведений для Минобороны России о ЧС и НС на транспорте с 120 до 10 минут 2 Обеспечена автоматизация формирования отчетов о нештатных ситуациях на транспорте, в том числе по данным внешних систем 25.12.2026 Сокращено время на подготовку отчетов о нештатных ситуациях на транспорте с 20 до 5 минут Реализация остальных ОКР не является предметом данного ТЗ и проводится в рамках отдельного технического задания. 4.5.11.2. Требования к показателям назначения мероприятий по эксплуатации Модуля СЦ. Работы по эксплуатации Модуля СЦ не должны обеспечивать режимы функционирования Модуля СЦ, приведенные в разделе 4.5.2 данного ТЗ При проведении работ по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности необходимо выполнить следующее: – Заказчику сформировать заявку на устранение (обновление) в СРО с полным списком обнаруженных уязвимостей и планируемыми работами; – согласовать в рабочем порядке время начала и завершения работ, перечень работ, выполняемых в рамках обновления или устранения уязвимостей в ППО с Заказчиком; – оповестить Заказчика о начале проведения работ на тестовом контуре; – провести работы по обновлению или устранению уязвимостей в ППО на тестовом контуре Модуля СЦ в установленные сроки; – протестировать выполнение работ в тестовом контуре и проинформировать Заказчика о готовности переноса ППО на продуктивный контур; – силами Заказчика обновить продуктивный контур Модуля СЦ, в соответствии с планом устранения и выполненными работами; – совместно с Заказчиком проверить корректность функционирования Модуля СЦ и устранения уязвимостей в продуктивном контуре Модуля СЦ по результатам обновления; – при необходимости актуализировать документацию (описание архитектуры, анкеты постановки на мониторинг и иные документы). Любые изменения в части обновления или устранения уязвимостей в ППО на промышленном контуре Модуля СЦ должны применяться только в случае успешного проведения аналогичных работ на тестовом контуре. Детальный порядок оказания услуги по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности определен в Регламенте оказания Услуг 4.4. Требования к видам обеспечения 4.4.1. Требования к лингвистическому обеспечению Документация на Модуль СЦ должна разрабатываться на русском языке. Взаимодействие пользователей с Модулем СЦ посредством графического интерфейса должно происходить на русском языке за исключением сообщений, зависящих от настроек системного программного обеспечения, установленного на рабочих местах пользователей. При разработке программных решений Модуля СЦ должно быть предусмотрено использование языков программирования высокого уровня, приведенных в Таблице 7. Таблица 7. Языки и средства разработки, специального программного обеспечения Модуля СЦ Категория Наименование Назначение Языки программирования Kotlin Разработка серверной логики и сервисов (backend) JavaScript / TypeScript Разработка клиентской части (frontend) Python Разработка скриптов интеграции, обработки данных и автоматизации Фреймворки и библиотеки Vue.JS Разработка пользовательских интерфейсов (веб-интерфейсы компонентов визуализации и отчетности) React Разработка пользовательских интерфейсов (при необходимости создания сложных интерактивных компонентов) Решения по лингвистическому обеспечению, включая перечень используемых языков программирования, должны быть согласованы с Заказчиком на этапе технического проектирования 4.4.2. Требования к математическому обеспечению Требования к математическому обеспечению не предъявляются. 4.4.3. Требования к метрологическому обеспечению Требования к метрологическому обеспечению не предъявляются. 4.4.4. Требования к организационному обеспечению Требования к организационному обеспечению не предъявляются. 4.4.5. Требования к методическому обеспечению Задачи методического обеспечения Модуля СЦ должны быть обеспечены за счет использования технологических и методических документов касающихся вопросов функционирования транспортного комплекса и разработки и эксплуатации ПО. 4.4.6. Требования к информационному обеспечению Состав, структура и способы организации информационного обеспечения в Модуле СЦ должны быть определены на этапе технического проектирования. Факты информационного обмена с внешними системами должны фиксироваться в соответствующем журнале 4.5.2. Требования к режимам функционирования Модуля СЦ Модуль СЦ должен предусматривать наличие следующих режимов работы: – штатный; – регламентный (профилактический); – аварийный. Основным режимом функционирования является штатный. В штатном режиме все компоненты корректно и полностью выполняют свои функции. Перерывов в работе как Модуля СЦ в целом, так и одного, либо нескольких компонентов не предусмотрено. Режим регламентного (профилактического) обслуживания предназначен для проведения работ по обновлению и техническому обслуживанию компонентов Модуля СЦ, а также резервному копированию данных. При работе в данном режиме допускаются перерывы в работе Модуля СЦ с предварительным информированием пользователей. Состав процедур по регламентному обслуживанию Модуля СЦ и их периодичность определяются Подрядчиком в процессе выполнения работ по созданию Модуля СЦ. В режиме регламентного (профилактического) обслуживания Модуль СЦ может функционировать с частичным ограничением своих функциональных возможностей, либо без ограничения, но со снижением показателей надежности и производительности. Перевод в данный режим работы должен осуществляться сразу после начала выполнения любой операции, отнесенной к этому режиму, с последующим возвратом в штатный режим функционирования сразу после ее завершения. Перевод в указанный режим должен осуществляться при возникновении необходимости проведения работ по обновлению и техническому обслуживанию компонентов Модуля СЦ, а также резервному копированию данных с условием предварительного оповещения пользователей. Аварийный режим функционирования характеризуется отказом одной или нескольких подсистем, вызванных выходом из строя аппаратного и/или программного обеспечения, а также в случае временной неработоспособности каналов связи между серверами. В аварийном режиме осуществляется поиск неисправностей и проведение работ по их устранению. Перевод в аварийный режим должен осуществляться при возникновении сбоев, аварий и прочих незапланированных воздействий, сразу после наступления одной или нескольких аварийных ситуаций, с последующим возвратом в штатный режим функционирования сразу после окончания восстановительных работ. ПО Модуля СЦ должно обладать надежностью, обеспечивающей работу пользователей в произвольном режиме и оперативное восстановление работоспособности при сбоях. В целях обеспечения надежного функционирования ПО должно предусматривать: – сохранение целостности данных при нештатном завершении работы компонентов Модуля СЦ; – сохранение работоспособности программного обеспечения при некорректных действиях пользователя; – резервное копирование базы данных Модуля СЦ. – время восстановления работоспособности Модуля СЦ после отказа не более 4 часов. – отказоустойчивость на уровне 99% при единовременной количестве не менее 200 пользовательских сессий в Модуле СЦ. Указанные характеристики приведены без учета характеристик надежности инфраструктуры и времени передачи информации по каналам связи. При возникновении сбоев в аппаратном обеспечении, включая аварийное отключение электропитания, Модуль СЦ должен автоматически восстанавливать свою работоспособность (не требовать перенастройки) после устранения сбоев и корректного перезапуска аппаратного обеспечения По результатам анализа угроз безопасности информации программного обеспечения и испытаний по выявлению уязвимостей в программном обеспечении Системы должна быть предоставлена отчетная документация по формам, утвержденным в Руководстве, и артефакты сборочной среды, подтверждающие проведение испытаний по выявлению уязвимостей в программном обеспечении Систем. Уязвимости подлежат устранению в сроки, обозначенные Заказчиком. В случае обнаружения уязвимого компонента Подрядчик должен заменить/обновить библиотеки. В случае, если уязвимость не подлежит исправлению на программном уровне, Подрядчик должен разработать меры предотвращения угроз безопасности, в том числе правила безопасности для наложенных средств защиты, рекомендации по безопасной настройке конфигурации для устранения потенциальных уязвимостей и снижения рисков информационной безопасности. Уязвимости, найденные ФСБ России, ФСТЭК России, Минцифры России, Роскомнадзором в ходе исполнения Контракта, а также в течение гарантийного периода, должны быть устранены Подрядчиком за свой счет в сроки, согласованные с Заказчиком 4.5.6. Требования к эргономике и технической эстетике Взаимодействие пользователей с Модулем СЦ должно осуществляться посредством визуального графического интерфейса. Ввод-вывод данных, прием управляющих команд и отображение результатов их исполнения должны выполняться в интерактивном режиме. Интерфейс должен быть рассчитан на преимущественное использование манипулятора типа «мышь», то есть управление Модулем СЦ должно осуществляться с помощью набора экранных меню, кнопок, значков и т. п. элементов. Клавиатурный режим ввода должен использоваться главным образом при заполнении и/или редактировании текстовых и числовых полей экранных форм. Все надписи экранных форм, а также сообщения, выдаваемые пользователю (кроме системных сообщений), должны быть на русском языке. Модуль СЦ должен обеспечивать проверку вводимых пользователем данных и предупреждать о некорректно введённых значениях Экранные формы должны проектироваться с учетом требований унификации: – все экранные формы пользовательского интерфейса должны быть выполнены в едином графическом дизайне, с одинаковым расположением основных элементов управления и навигации; – для обозначения сходных операций должны использоваться сходные графические элементы, кнопки и другие управляющие (навигационные) элементы. Термины, используемые для обозначения типовых операций, а также последовательности действий пользователя при их выполнении должны быть унифицированы; – внешнее поведение сходных элементов интерфейса (реакция на наведение указателя «мыши», переключение фокуса, нажатие кнопки) должно реализовываться одинаково. Структура размещения информации и представление этой структуры в Модуле СЦ должны соответствовать следующим требованиям: – пункты меню в пользовательском веб-интерфейсе должны быть сгруппированы в соответствии с тематикой информации, функциональными задачами и технологией работы; – каждому пункту меню должна соответствовать только одна выполняемая функция; – при совершении пользователями ошибочных действий должны выдаваться сообщения об ошибках. Эскизы визуального оформления компонента «Интерактивная карта» представлены в Приложении А. Технические меры по обеспечению надежности должны предусматривать: – резервирование критически важных компонентов и данных Системы и отсутствие единой точки отказа; – использование программного резервирования (программной избыточности); – изменение конфигурации используемых средств и применение специализированного ПО, обеспечивающего высокую надёжность. Организационные меры по обеспечению надежности должны быть направлены на минимизацию ошибок пользователей (а также обслуживающего персонала при эксплуатации и проведении работ по обслуживанию), минимизацию времени ремонта или замены вышедших из строя компонентов за счёт: – обеспечения для обслуживающего персонала требуемого уровня квалификации; – регламентации и нормативного обеспечения выполнения работ обслуживающим персоналом; – своевременной диагностики неисправностей. Расчетное значение коэффициента доступности Модуля СЦ должно составлять не менее 0,95. 4.5.3. Требования по диагностированию Модуля СЦ Диагностирование Модуля СЦ должно осуществляться путем анализа записей в системных журналах СУБД, операционных систем серверов, а также с помощью встроенных средств диагностирования общего программного обеспечения Модуля СЦ. Диагностированию подлежат: – сбои и нарушения функционирования технического обеспечения (серверов) Модуля СЦ; – сбои и нарушения функционирования системного программного обеспечения серверов, используемых для работы Модуля СЦ; – сбои и нарушения функционирования прикладного программного обеспечения серверов, используемых для работы Модуля СЦ; – случаи недоступности (отсутствия ответа) или некорректные ответы внешних систем; – сбои и нарушения функционирования СУБД; – сбои при выполнении регламентных операций резервного копирования. При возникновении аварийных ситуаций либо ошибок в программном обеспечении диагностические инструменты должны позволять сохранять набор информации, необходимой для идентификации и устранения проблемы. Модуль СЦ и ее компоненты должны обеспечивать возможность диагностики своей работоспособности с возможностью интеграции с модулем мониторинга АСУ ТК. Набор передаваемых журналов и метрик должен быть определен на этапе технического проектирования 4.5.4. Требования к надежности Должно быть предусмотрено сохранение работоспособности Модуля СЦ при некорректных действиях пользователя и сохранение целостности данных при нештатном завершении работы Модуля СЦ (отказ рабочей станции, потеря сетевого доступа и т.п.). Модуль СЦ должен предоставлять механизмы обеспечения сохранности данных через применение процедур резервного копирования и восстановления, описанных в документации на Систему. Ключевые показатели надежности информационной системы — допустимое время на восстановление работоспособности Модуля СЦ (RTO - recovery time objective) и/или допустимый интервал времени потери изменений в данных при сбоях/отказах (RPO – recovery point objective) должны быть определены Подрядчиком и согласованы с Заказчиком на этапе технического проектирования 4.5.7. Требования по сохранности информации при авариях В случае возникновения аварии или сбоя в процессе выполнения пользовательских задач должно быть обеспечено восстановление баз данных до состояния на момент последней завершенной Модулем СЦ транзакции, и структуры файлового хранилища. Все аварийные ситуации должны обрабатываться программно с выдачей соответствующих сообщений, с корректной обработкой ситуации (завершение транзакций, закрытие файлов и т.п.), без потери обрабатываемой информации. В Модуле СЦ должны быть предусмотрены меры, обеспечивающие целостность данных в случае отказа программного обеспечения или аппаратных средств, исключая случаи физического уничтожения носителя или нарушения функциональности носителя, операционной системы или СУБД по вине их производителя либо обслуживающего персонала. Используемые аппаратные и системные платформы должны обеспечивать сохранность и целостность информации в Модуле СЦ при полном или частичном отключении электропитания, аварии сетей телекоммуникации, полном или частичном отказе технических средств Модуля СЦ. Технические решения должны обеспечивать сохранность информации в случае возникновения следующих событий (аварий, отказов и т.п.): – отказ аппаратного обеспечения на сервере; – отключение питания на сервере; – отказ аппаратного обеспечения на рабочей станции; – отключение питания на рабочей станции администратора; – отказ линий связи, в том числе при осуществлении обмена данными 4.5.8. Требования к защите от влияния внешних воздействий Требования к защите от влияния внешних воздействий не предъявляются 4.5.9. Требования к патентной чистоте и патентоспособности 4.5.9.1. Исключительные права на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, базы данных, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, принадлежат Российской Федерации в лице Заказчика. Право собственности на результаты работ, отчетные документы и материалы, полученные в ходе выполнения работ по Контракту, принадлежат Российской Федерации в лице Заказчика и считаются переданными с момента подписания Сторонами Акта сдачи-приемки выполненных работ. Разработанное программное обеспечение поставляется вместе с исходными кодами. 4.5.9.2. Все проектные и технические решения должны отвечать требованиям четвертой части Гражданского кодекса Российской Федерации. Результаты Работ должны быть свободными от возможности предъявления любых прав и притязаний третьих лиц, основанных на промышленной, интеллектуальной или другой собственности. 4.5.9.3 Результаты выполненных Работ не должны повлечь необходимость осуществления Заказчиком закупок программного обеспечения (как исключительных, так и неисключительных прав) для обеспечения функциональности Системы в соответствии с Техническим заданием. При выполнении работ Подрядчик должен использовать только объекты интеллектуальной собственности, права на которые приобретены (получены) и используются без нарушений прав на интеллектуальную собственность третьих лиц или предоставлены Заказчиком 4.5.9.4. Подрядчик подтверждает, что обладает всеми правами на передачу Заказчику исключительных прав в соответствии с требованиями настоящего раздела Технического задания. В случае, если к Заказчику по вине Подрядчика будут предъявлены претензии в этой части, иски третьих лиц, связанные с нарушением их прав, Подрядчик принимает на себя такие претензии и иски и возмещает Заказчику все расходы и весь ущерб, понесенный в связи с ними. 4.5.9.5. Подрядчик обязан согласовать с Заказчиком необходимость использования при выполнении работ охраняемых результатов интеллектуальной деятельности, права на которые принадлежат Подрядчику или третьим лицам. 4.5.9.6. В случае, если при выполнении Работ используется готовое программное обеспечение (платформа, подсистема, СУБД и т.д.), которое становится частью (компонентом) Системы, Заказчику передаются полные исключительные права, или неисключительные права (путем заключения лицензионного/сублицензионного договора/соглашения) на такое программное обеспечение со следующими возможностями: – права передаются бессрочно (на весь срок действия исключительных прав); – территория действия Российская Федерация; – должно быть обеспечено право Российской Федерации (в лице Заказчика) передавать, дорабатывать, распространять, развивать результаты работ, созданные в процессе исполнения Контракта, а также перерабатывать такое программное обеспечение. Лицензионное (сублицензионное) соглашение (договор), Акт передачи прав, подписанные Подрядчиком, согласие правообладателя, оформленное в соответствии с положениями Гражданского кодекса Российской Федерации (в случае, если Подрядчик не является правообладателем такого программного обеспечения), инструкция по инсталляции, руководство администратора, руководство пользователя передаются Заказчику в сроки, установленные Техническим заданием для соответствующего функционала Системы Лицензионное (сублицензионное) соглашение (договор) не может возлагать на Заказчика какие-либо обязанности (в т.ч. в части конфиденциальности, предоставления отчетности), не предусмотренные Контрактом. 4.5.9.7. Передача Заказчику исключительных прав, или простых (неисключительных) прав не может повлечь увеличение стоимости Контракта и/или изменение иных существенных условий Контракта. 4.5.9.8. Функциональность Модуля СЦ передается в объеме и в сроки, установленные Техническим заданием. 4.5.9.9. Нарушение условий настоящего раздела Технического задания, в т.ч. отсутствие соответствующего лицензионного (сублицензионного) соглашения (или договора), либо предоставление лицензионного (сублицензионного) соглашения (или договора), не соответствующего требованиям действующего законодательства Российской Федерации или требованиям Контракта, является нарушением существенных условий Контракта. 4.5.9.10. В случае, если в соответствии с пунктом 4.5.9.6 Заказчику передается исключительное право, такая передача осуществляется в порядке, установленном Гражданским кодексом Российской Федерации. 4.5.9.11. В случае, если при выполнении Работ положения пунктов 4.5.9.5-4.5.9.6 не применялись, Подрядчик в составе отчетной документации предоставляет об этом декларацию в свободной форме. Декларация должна содержать сведения о полном соответствии результата Работ требованиям Контракта, а также о неприменении при выполнении работ готового программного обеспечения (платформ, подсистем, СУБД и т.д.), которое стало частью (компонентом) Системы 4.1. Требования к структуре Модуля СЦ В процессе работ по развитию Системы должны сохраниться основные требования к построению архитектуры Системы в соответствии с принципами трехуровневой архитектуры: 1. уровень хранения данных или уровень базы данных (сервер СУБД); 2. уровень сервера приложений (сервер аналитической обработки); 3. презентационный уровень, обеспечивающий взаимодействие с клиентскими приложениями. В состав Системы должны входить следующие основные компоненты: 4. сервер баз данных; 5. сервер приложений; 6. веб-сервер. Сервер баз данных должен обеспечивать хранение и целостность хранимых данных, создание резервных копий, ведение журнала транзакций, восстановление данных после сбоев. Сервер приложений должен обеспечивать обработку запросов, поступающих от клиентских приложений (через веб-сервер), формирование ответов на запрос в доступном пользователю виде (формирование пользовательских интерфейсов). Веб-сервер должен обеспечивать взаимодействие с оператором и внешними системами по HTTP / HTTPS протоколу в режиме «запрос-ответ» (получения запросов от пользователя и передачи ответа в виде соответствующей информации, обработанной серверами приложений). Взаимодействие Системы с пользователем должно отвечать требованиям модели «тонкого клиента» (т.е. представлять на стороне клиента (пользователя) лишь графический пользовательский интерфейс). Все составляющие Системы должны использовать единую методологию и отвечать единым принципам взаимодействия, надежности и управления. Перечень компонентов Модуля СЦ представлен в Таблице 4. Таблица 4. Перечень компонентов Модуля СЦ, в отношении которых выполняются работы по развитию № п.п. Наименование компонента Модуля СЦ Раздел ТЗ 1 Компонент регистрации событий 4.2.1. 2 Компонент отчетности 4.2.2 3 Компонент визуализации 4.2.3 4 «Интерактивная карта» (компонент создается) 4.2.4 5 Компонент администрирования 4.2.5 4.2. Требования к дорабатываемым функциям модуля СЦ 4.2.1. Развитие компонента регистрации событий (1 очередь) Должны быть выполнены следующие доработки: – обеспечение логирования действий пользователя, связанных с карточкой события; – доработка объектной модели в части создания новых типов сущностей (карточек) с учетом реализуемых интеграций с информационными ресурсами (силы и средства предупреждения и ликвидации ЧС и нештатных ситуаций на транспорте, ТС, ограничения воздушного пространства, неблагоприятные и опасные природные явления); – реализация механизма установления связи между сущностями в Модуле СЦ автоматизированным и ручным способами (события, природные явления, силы и средства предупреждения и ликвидации ЧС и нештатных ситуаций на транспорте, ограничения воздушного пространства, ОТИ, ТС и др.); – отображение в карточке установленных связей между сущностями. 4.2.2. Развитие компонента отчетности (3 очередь) Должна быть обеспечена автоматизация процессов формирования отчетов о ЧС и нештатных ситуациях на транспорте, в т.ч. на основе данных из внешних систем. Включает следующие доработки: – разработка шаблонов отчетов в различных форматах (табличный, текстовый); – реализация выбора фотоматериалов для включения в справку; – форматирование содержимого справок с учетом правил русского языка в отношении окончаний слов (в зависимости от падежа, склонения, числа и рода); – автоматизированное формирование выводов к содержимому справки на основе настраиваемых критериев; – создание интерфейса выбора параметров (фильтрации) для формирования отчетов: o состав полей для включения в отчёт; o настройка диапазонов значений характеристик и дат; o порядок отображения полей; o настройка заголовка. – реализация способа подготовки отчётов в асинхронном режиме (очереди); – реализация интерфейса компонента формирования отчетности для отображения очереди формирования отчетов и статусов их подготовки; – экспорт отчётов в форматы xlsx, csv и справок в форматы pdf, docx. Необходимо разработать не менее 10 шаблонов отчетов и/или справок. Перечень, структура и содержание шаблонов должны быть согласованы с Заказчиком на этапе технического проектирования. 4.2.3. Развитие компонента визуализации (2 очередь) В рамках развития компонента визуализации должны быть выполнены следующие доработки, обеспечивающие: – вывод перечней (списков) сил и средств предупреждения и ликвидации ЧС и нештатных ситуаций на транспорте с отображением мест их постоянного размещения (дислокации) на карте, включая: o отображение зон ответственности на карте; o возможность их фильтрации (по видам транспорта, регионам и пр.); o реализацию инструмента расчета расстояния (с использованием сети автомобильных и железных дорог) между местом события и местами дислокации сил и средств, а также вывода маршрутов на карте; – отображение зон (полигонов) с установленными ограничениями движения в воздушном пространстве на карте; – отображение термических точек; – реализация возможности отображения данных из паспорта региона, отображаемого в модуле iМинтранс (модуль АСУ ТК); – отображение краткой карточки сущностей и ОТИ (краткой информации и/или динамических характеристик объекта) при выборе объекта на карте с возможностью перехода в полную карточку сущности и ОТИ; – отображение данных от Росгидромета, предусматривающих: o отображение неблагоприятных и опасных природных явлений на карте (с заданным периодом обновления данных); o управление отображением явлений на карте, включая настройку состава отображаемых объектов, поиск, фильтрацию, с использованием соответствующей панели управления; o выведение краткой карточки явления при выборе объекта, с возможностью перехода в полную карточку объекта – отображение на карте связанных сущностей и ОТИ; – реализация функции выбора темного и светлого стилей отображения элементов интерфейса, карточек сущностей, картографической основы и объектов, отображаемых на карте; – реализация механизма для выбора картографической основы в одном из распространенных форматов WMTS, TMS, MVT и др. Должна быть предусмотрена возможность настройки перечня картографических основ и параметров доступа к ним; – настройка базового набора дашбордов, содержащих преднастроенные виджеты о количестве событий в разрезе видов транспорта с возможностью перехода к исходным данным (карточкам событий, ОТИ и т.д.), с фильтрацией по параметрам. Параметры фильтрации должны быть определены на этапе технического проектирования. Должно быть обеспечено автоматическое и принудительное обновление данных, отображаемых на дашбордах 4.2.4. Создание компонента «Интерактивная карта» (2 очередь) В составе создаваемого компонента должны отображаться данные, доступные в компоненте визуализации. Требования к интерфейсу интерактивной карты: – интерактивная карта должна быть представлена в виде объемной карты с учетом макетов, представленных в Приложении А к ТЗ; – интерфейс должен корректно отображаться на экранах мониторов (разрешение Full HD 1920?1080), телевизоров (разрешение 4К 3840?2160), жидкокристаллических панелей для видеостены, используемой Заказчиком, с параметрами каждой панели: диагональ 55 дюймов, разрешение 1920x1080; – интерфейс должен корректно отображаться на планшетных устройствах с диагональю экрана 10-12 дюймов, конкретные требования должны быть уточнены на этапе технического проектирования; – должна быть обеспечена кластеризация и генерализация отображения объектов на карте при изменении масштаба; – должно быть обеспечено отображение основных характеристик объектов при выборе их на карте; – должно быть обеспечено управление отображением слоев на карте; – должна быть обеспечена настройка цветовой индикации отображаемых объектов транспортной инфраструктуры; – должно быть обеспечено отображение легенды карты, содержащей отображаемые объекты на карте; – должна быть обеспечена возможность одновременного отображения не менее 5 000 ОТИ и ТС на карте. На интерактивной карте должны быть отображены подвижные объекты совместно с объектами транспортной инфраструктуры (ОТИ), включая следующие возможности: § отображение местоположения транспортных средств (воздушный, водный и автомобильный транспорт) на карте в режиме реального времени (с заданным периодом обновления данных); § отображение маршрутов движения всех ТС за выбранный период времени, в том числе с использованием эффектов анимации; § отображение маршрутов движения ТС, связанных с карточкой события: ТС, являющихся участниками события, и ТС, находящиеся в заданном радиусе от события; § управление отображением сущностей и ОТИ на карте, включая настройку состава отображаемых объектов, поиск, фильтрацию, с использованием соответствующей панели управления и наглядным представлением результатов; § автоматическое изменение вида отображения объектов (цветовая индикация) по заданным условиям (например, при достижении критических значений параметров, характеризующих функционирование объекта); Должна обеспечиваться производительность обновления изображения на экране в 30 кадров в секунду на тестовой конфигурации пользовательского устройства (модель Бештау AIO2402/B560, входящая в Реестр российской промышленной продукции под номером 10394100 или аналог) при одновременном отображении не менее 5 000 объектов и 200 уникальных моделей объектов. Макеты интерфейсов Модуля СЦ должны быть предварительно согласованы с Заказчиком и разработаны с учетом требований ГОСТ Р ИСО 9241-161-2016 «Элементы графического пользовательского интерфейса» 4.2.4.1. Требования к технической реализации компонента «Интерактивная карта» При реализации компонента «Интерактивная карта» должны учитываться требования, указанные ниже. 4.2.4.1.1. Требования к отображению элементов Повторяющихся элементы карты (ТС, ОТИ, события и пр.) должны отрисовываться с использованием аппаратного создания экземпляров объектов на пользовательском устройстве (WebGL/WebGPU)). Отрисовка каждого объекта отдельным запросом не допускается, должна обеспечиваться возможность одновременного отображения не менее 5 000 объектов без снижения производительности (30 кадров в секунду на тестовой конфигурации). 4.2.4.1.2. Уровни детализации объектов Для управления отображением сложных объектов должно быть создано не менее 3-х уровней детализации, отображаемых при изменении масштаба с возможностью автоматического переключения между уровнями. Все отображаемые объекты должны масштабироваться с учетом разрешения экрана пользователя с сохранением качества детализации. 4.2.4.1.3. Полигональная оптимизация и текстурирование При реализации компонента «Интерактивная карта» должна обеспечиваться технология рельефного тестурирования объектов. Не должны использоваться высокополигональные трехмерные модели. Все повторяющиеся элементы должны генерироваться единоразово и повторно использоваться при последующих отображениях. 4.2.4.1.4. Управление памятью Требуется реализовать потоковую загрузку на устройство пользователя элементов карты и текстур. Загрузка данных целиком при старте приложения не допускается. Необходимо реализовать механизм очистки памяти от элементов, которые находятся вне области видимости камеры в течение заданного времени. 4.2.4.1.5. Требования к взаимодействию пользователя с интерфейсом компонента «Интерактивная карта» Программная реализация механизмов управление камерой (масштабирование и навигация) должна быть выполнена с поддержкой технологии WebAssembly (WASM). Элементы управления должны являться неотъемлемой частью интерактивной карты. 4.2.5. Развитие компонента администрирования (3 очередь) Должна быть выполнена доработка ролевой модели. Ролевая модель должна обеспечивать управление доступом к отдельным объектам Модуля СЦ и их элементам (атрибутам) с разграничением по видам транспорта, регионам и пр., в частности: – определение набора конкретных действий, доступных пользователям (выполняемых над объектом доступа, например, удаление записи, редактирование записи, формирование отчета и др.); – реализация возможности объединения пользователей в группы; – определение прав доступа для групп пользователей; – реализация интерфейса визуальной настройки прав доступа пользователей к объектам Модуля СЦ 4.2.6. Взаимосвязи с внешними автоматизированными системами (1 очередь) Способы взаимодействия с внешними информационными системами должны быть определены на этапе технического проектирования. Должны быть выполнены следующие доработки: – интеграции с информационными ресурсами в целях получения данных о движении подвижных ТС (воздушные суда, суда водного транспорта); – интеграция с информационным ресурсом в целях получения данных о событиях на железнодорожном транспорте. Реализация интеграций должна включать проектирование и реализацию интеграционных механизмов обмена данными с учетом доступных вариантов реализации, обеспечение защищенных способов взаимодействия, настройку отображения отдельных данных на карте (настройка слоев). Взаимодействия, имеющие каналы связи, выходящие за пределы контролируемой зоны взаимодействующих систем, считаются защищенными, если для их защиты используются программные и/или программно-аппаратные шифровальные (криптографические) средства, сертифицированные ФСБ России (далее – СКЗИ). Выбор СКЗИ, схемы подключения и требуемого класса криптостойкости должен производиться в соответствии с Техническими условиями на подключение к информационным ресурсам ФГБУ «СИЦ Минтранса России» и инструкциями по подключению пользователей к ресурсам инфраструктуры Головного центра обработки данных, утвержденных приказом директора ФБГУ «СИЦ Минтранса России» от 24.05.2024 № 21-ОД 4.3. Требования к оказанию услуг по технической поддержке Модуля СЦ 4.3.1. Общие требования к оказанию Услуг Техническая поддержка Модуля СЦ должна осуществляться с учетом требований постановления Правительства Российской Федерации от 06.07.2015 N 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации». Подрядчик обязан выполнять требования законодательства в сфере защиты информации, требования по защите информации, информационной безопасности, указанные в локальных нормативных актах ФГБУ «СИЦ Минтранса России», регламентирующих условия информационного взаимодействия, защиты информации и подключения к информационным ресурсам ФГБУ «СИЦ Минтранса России», участвующих в информационном взаимодействии в рамках оказания услуг по технической поддержке АСУ ТК в 2026 году 4.3.1.1. Требования к составу и содержанию услуг третьего уровня технической поддержки Оказание услуг по технической поддержке Системы осуществляется в рамках этапов в соответствии с календарным планом. Подрядчик в течение 5 рабочих дней с даты заключения Контракта должен предоставить со своей стороны, а Заказчик со своей стороны Матрицу ответственных за взаимодействия в соответствии с Приложением 1 к Регламенту оказания услуг по третьему уровню технической поддержки Модуля СЦ (далее – Регламент, Приложение В). Подрядчик в течение 10 рабочих дней с даты заключения Контракта должен провести мероприятия по организации третьего уровня технической поддержки в соответствии с Регламентом. Услуги по третьему уровню технической поддержки Модуля СЦ должны включать: – организацию Подрядчиком третьего уровня технической поддержки; – информационно-консультационную поддержку работников Заказчика; – решение инцидентов, связанных с работой ППО; – адаптационное, конфигурационное и коррекционное сопровождение Модуля СЦ (в рамках действующих программных модулей и функциональности); – устранение уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности 4.3.1.2. Требования к общему порядку оказания услуг Техническая поддержка Модуля СЦ должна быть организована на трех уровнях: – первый и второй уровни технической поддержки организуется Заказчиком; – третий уровень технической поддержки организуется Подрядчиком. Перечень действий на каждом уровне технической поддержки указан в Таблице 5: Таблица 5 – Перечень действий на каждом уровне технической поддержки Уровень технической поддержки Доступные действия Условия передачи задачи на следующий уровень Первый уровень технической поддержки (далее – 1-й уровень) – принимает обращения (заявки) пользователей Модуля СЦ и работников Заказчика; – регистрирует обращения в Модуле СЦ регистрации обращений; – присваивает уникальный идентификационный номер, классифицирует обращения; – самостоятельно решает обращения, которые связаны с недостаточной квалификацией пользователей или настройками в рамках своей компетенции; – взаимодействует с пользователями Модуля СЦ при решении проблемы Передает обращение на второй уровень поддержки в случае невозможности решения на своем уровне Второй уровень технической поддержки (далее – 2-й уровень) – принимает обращения от 1-го уровня; – уточняет классификацию обращения в результате дополнительного анализа; – самостоятельно решает обращения в рамках своей компетенции; – осуществляет техническую и консультационную поддержку Модуля СЦ; – взаимодействует с сотрудниками 1-го и 3-го уровня и пользователями Модуля СЦ; – формирует заявки для 3-го уровня и контролирует исполнение Передает обращение на третий уровень поддержки в случае невозможности решения на своем уровне Третий уровень технической поддержки (далее – 3-й уровень) – принимает обращения от 2-го уровня; – обеспечивает выполнение требований, предъявляемых Контрактом и настоящим Техническим заданием к Услугам, оказываемым Подрядчиком Все поступающие обращения должны быть исполнены Подрядчиком Для обеспечения взаимодействия с Заказчиком Подрядчик со своей стороны определяет ответственных лиц, уполномоченных в структуре Подрядчика за своевременное и качественное оказание Услуг в рамках настоящего ТЗ, а также контактную информацию ответственных лиц (телефон, электронную почту). Подрядчик должен предоставить Заказчику единый адрес электронной почты для приема обращений (заявок) в течение 3 (трех) рабочих дней после заключения Контракта. Указанный в настоящем пункте адрес электронной почты (способ направления обращений (заявок) применяется в случае сбоя в работе СРО Заказчика. Со своей стороны, Заказчик предоставляет Подрядчику перечень и контактную информацию (телефон, электронную почту) уполномоченных лиц для осуществления взаимодействия с указанием зон ответственности. О любых изменениях в контактной информации ответственных лиц Стороны должны уведомить друг друга в течение 1 (одного) рабочего дня с момента возникновения таких изменений посредством уведомления на электронную почту ответственных лиц и/или в письменной форме. В результате оказания услуг по настоящему ТЗ не должны быть изменены исходные коды, дистрибутивы и иные компоненты Модуля СЦ вне согласованных с Заказчиком изменений. Любые изменения исходных кодов, дистрибутивов и иных компонентов Модуля СЦ должны производиться только после согласования с Заказчиком уполномоченными лицами по электронной почте или иным заранее согласованным способом. Не должна быть ухудшена надежность и производительность Модуля СЦ. Оказание услуг по Контракту не должно нарушать требования к информационной безопасности, описанной в документации на Модуль СЦ Оказание услуг в рамках данного технического задания осуществляется Подрядчиком по обращению (заявке) Заказчика, направляемой посредством СРО Заказчика. Регистрация обращений, поступивших непосредственно в Модуль СЦ регистрации обращений Заказчика, производится сотрудниками Заказчика, которые обеспечивают первый уровень технической поддержки Модуля СЦ. В случае назначения приоритета «Критический» или «Высокий», информация о назначении также дублируется оповещением ответственных представителей Подрядчика посредством звонка на предоставленные номера телефонов. Обращение (заявка) должна содержать следующую информацию: – контакты пользователя/организации; – приоритет обращения, соответствующий Приложению 2 к Регламенту; – время обнаружения; – наименование компонента АСУ ТК - Модуль СЦ; Информация может быть расширена по согласованию с Заказчиком. Обращения (заявки) сотрудников Заказчика должны приниматься Подрядчиком через веб-интерфейс СРО. В процессе обработки обращений (заявок) Подрядчик должен обеспечить выполнение следующих процедур: – прием обращений(заявок) от сотрудников Заказчика; – оказание информационно-консультационной поддержки в соответствии с требованиями настоящего Технического задания; – информирование сотрудников Заказчика о статусе обработки и результатах обработки обращений(заявок). Подрядчик осуществляет обязательную регистрацию и учет всех обращений и заявок, поступивших к Подрядчику от представителей Заказчика в рамках оказания настоящих услуг Примечание: в случае приостановки работы по обращению или заявке (обращение или заявка находится в статусе «Приостановлено»), указываются причины, по которым работы по обращению или заявке приостановлены с указанием перечня действий/информации, запрошенных у инициатора обращения, а также даты, формы и адресата такого запроса. В случае отклонения обращения или заявки (заполняется в случае, если обращению или заявке присваивается статус «Отклонено»), указываются подробно причины такого отклонения, а также фиксируется дата и время перехода в статус «Отклонено». В случае, если обращение или заявка отклонены (отменены) самим Инициатором, то указывается дата и способ, которым от инициатора получено соответствующее уведомление. В случае невыполнения Подрядчиком регламентного времени реагирования или решения обращения (заявки) Заказчик вправе отозвать обращение и направить его Подрядчику повторно. При этом каждое отозванное обращение учитывается в Отчёте об оказанных услугах, как обращение с превышением времени реагирования или решения, но оплате не подлежит. В случае, если обращение (заявка) связано с некачественным выполнением Подрядчиком другой задачи, такое обращение решается в регламентное время, установленное Техническим заданием, при этом оплате такие обращения не подлежат, о чем указывается в Отчете об оказанных услугах в графе «Примечание» 4.3.1.3. Требования к регламенту оказания услуг Подрядчик должен руководствоваться Регламентом оказания услуг по технической поддержке Модуля СЦ. Регламент оказания услуг содержит следующую информацию: – порядок оказания услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Модуля СЦ; – порядок оказания услуги по решению инцидентов, связанных с работой ППО; – порядок оказания услуги адаптационного, конфигурационного и коррекционного сопровождения Модуля СЦ (в рамках действующих программных модулей и функциональностей); – порядок оказания услуги по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности. – Регламент содержит следующие формы заявок на оказание услуг: – форма заявки на оказание услуги по информационно-консультационной поддержке сотрудников Заказчика; – форма заявки на оказание услуги по решению инцидентов, связанных с работой ППО; – форма заявки на оказание услуг адаптационного, конфигурационного и коррекционного сопровождения Модуля СЦ (в рамках действующих программных модулей и функциональностей) (приоритет заявки определяется Заказчиком); – форма заявки на оказание услуги по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности 4.3.2. Требования к режиму обеспечения функционирования Модуля СЦ Режим оказания услуг определен в Приложении Б к настоящему ТЗ. По согласованию с Заказчиком, в целях недопущения остановки функционирования Модуля СЦ в период интенсивной работы пользователей в Модуле СЦ, отдельные услуги могут оказываться по специальному графику (в нерабочее время Подрядчика) в соответствии с заявками Заказчика 4.3.3. Требования к качеству оказываемых услуг Качество оказываемых услуг поддерживается Подрядчиком в соответствии с определяемыми данным ТЗ условиями и правилами и контролируется Заказчиком на постоянной основе, в том числе по соблюдению сроков исполнения и подтверждениям исполнения от инициаторов обращений и другим параметрам. По результатам выполнения работ по устранению инцидента должна быть устранена корневая причина инцидента с окончательным решением, устраняющим причину возникновения проблемы и исключающим вероятность повторного возникновения проблемы (инцидента). Время устранения корневых причин проблемы (инцидента) не должно составлять более 40 рабочих часов 4.3.4. Требования к документированию результатов оказываемых услуг Для обеспечения контроля оказываемых услуг по поддержке Модуля СЦ со стороны Заказчика, по окончании каждого отчетного периода по контракту в соответствии с календарным планом, Подрядчик обязан предоставить Заказчику Отчет об оказанных услугах. Отчет должен содержать детальную информацию об оказанных услугах с указанием даты выполненных мероприятий и приложением обосновывающих документов (заявок, запросов, требований) или ссылкой на такие документы, если они содержатся в Модуле СЦ. Информация о выполненных мероприятиях по заявкам должна быть сформирована на основании соответствующих записей СРО по каждому этапу исполнения Контракта. В случае оказания услуги адаптационного, конфигурационного и коррекционного сопровождения Модуля СЦ, должны быть предоставлены документы, подтверждающие выполнение требований п. 29.3 приказа ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации». Фактическое время реагирования и время решения по всем обращениям, поступившим в СРО, формируется в СРО по итогам отчетного периода в разделе «Отчеты». Фактическое время реагирования и время решения по обращениям учитывает суммарное время, затраченное на реагирование и, соответственно, на работу по обращению с момента назначения обращения специалисту Подрядчика или группе исполнителей, ответственным за оказание услуг технической поддержки 3 уровня от начала до завершения работ Подрядчиком. При этом принимается суммарное время нахождения заявки в соответствующих статусах заявки СРО на стороне Подрядчика 4.3.5. Требования к классификации обращений и заявок Обращения и заявки Заказчика классифицируются в соответствии с приоритетами и регламентными сроками, указанными в Приложении 2 к Регламенту. Регистрация обращений и заявок предусматривает создание новой записи в СРО с присвоением поступившему обращению или заявке (новой записи) уникального идентификатора. Запись в СРО должна содержать вопрос или проблему, которую требуется решить или оказать консультацию. Состав обязательной информации, которую должно содержать обращение или заявка, зафиксирован в Регламенте оказания Услуг. Если обращение или заявка автоматически зарегистрированы в СРО при отправке представителем Заказчика, Подрядчик проверяет корректность классификации обращения или заявки и может обратиться к Заказчику с просьбой корректировки, предоставив обоснования в соответствии с настоящей классификацией (Таблица 6) 5. СОСТАВ И СОДЕРЖАНИЕ РАБОТ ПО РАЗВИТИЮ И ТЕХНИЧЕСКОЙ ПОДДЕРЖКЕ МОДУЛЯ СЦ (КАЛЕНДАРНЫЙ ПЛАН) Сдача-приемка результатов выполненных работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная техническая документация, а также результаты работ предоставляются Заказчику в порядке, предусмотренном Контрактом и ТЗ, до размещения Подрядчиком в ЕИС документа о приемке. Документ о приемке размещается в ЕИС по каждому этапу в соответствии с условиями Контракта. Этапы выполнения работ по развитию Модуля СЦ приведены в Таблице 11. Таблица 11. Этапы выполнения работ по развитию Модуля СЦ. № этапа Наименование этапа Результат (отчетная документация) Срок исполнения этапа Значение характеристики не может изменяться участником закупки 1 Техническое проектирование Сопроводительным письмом предоставляются Заказчику: · Технический проект, включая следующие документы: – Ведомость технического проекта; – Ведомость машинных носителей информации – Пояснительная записка; – Описание информационного обеспечения системы; – Описание автоматизируемых функций; – Схема функциональной структуры; – Описание организации информационной базы; – Описание программного обеспечения; · Макеты экранных форм компонента «Интерактивная карта»; · Руководство по безопасной разработке программного обеспечения; · Документ о приемке Начало: с даты заключения контракта Окончание: не позднее 31.07.2026 2 Услуги по технической поддержке Модуля СЦ (с даты заключения контракта по 10.09.2026) По окончании оказания Услуг сопроводительным письмом предоставляются Заказчику: – Отчет об оказанных Услугах по технической поддержке; – Актуальные на дату окончания оказания Услуг по данному этапу исходные коды прикладного ПО на электронном носителе (в случае внесения изменений); – Инструкция по сборке и развертыванию (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство пользователя (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство администратора (в случае внесения изменений); – Документ о приемке Начало: с даты заключения контракта Окончание: не позднее 10.09.2026 3 Разработка программного обеспечения (1 очередь, пп. 4.2.1, 4.2.6 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ; – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 1 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 1 очереди; – Руководство по резервному копированию; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 16.09.2026 4 Разработка программного обеспечения (2 очередь, пп. 4.2.3, 4.2.4 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ. – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 2 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 2 очереди; – Руководство по резервному копированию; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 25.09.2026 5 Разработка программного обеспечения (3 очередь, пп. 4.2.2, 4.2.5 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ; – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 3 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 3 очереди; – Руководство по резервному копированию; – Описание ролевой модели; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 09.10.2026 6 Опытная эксплуатация (1 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акт о завершении опытной эксплуатации 1 очереди; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке 17.09.2026 Окончание: не позднее 26.10.2026 7 Опытная эксплуатация (2 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акт о завершении опытной эксплуатации 2 очереди; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке 26.09.2026 Окончание: не позднее 26.10.2026 8 Опытная эксплуатация (3 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Акт о завершении опытной эксплуатации 3 очереди; – Документ о приемке Начало: с 10.10.2026 Окончание: не позднее 26.10.2026 9 Приемочные испытания Сопроводительным письмом предоставляются Заказчику: – Программа и методика приёмочных испытаний; – Протокол приемочных испытаний; – Исходные коды и дистрибутивы на электронном носителе (при условии внесения изменений, с учетом доработок по результатам опытной эксплуатации и проведенных испытаний); – Комплект рабочей документации на Модуль СЦ (при условии внесения изменений, с учетом доработок по результатам опытной эксплуатации и проведенных испытаний); – Акт приемки Системы в эксплуатацию; – Акт приемки-передачи исключительных прав на объект; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке; – Документы в соответствии с разделом 4.5.9 ТЗ; – Обеспечение гарантийных обязательств Начало: с 27.10.2026 Окончание: не позднее 10.11.2026 10 Услуги по технической поддержке Модуля СЦ (с 11.09.2026 по 15.12.2026) По окончании оказания Услуг сопроводительным письмом предоставляются Заказчику: – Отчет об оказанных Услугах по технической поддержке; – Актуальные на дату окончания оказания Услуг по данному этапу исходные коды прикладного ПО на электронном носителе (в случае внесения изменений); – Инструкция по сборке и развертыванию (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство пользователя (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство администратора (в случае внесения изменений); – Документ о приемке Начало: с 11.09.2026 Окончание: не позднее 15.12.2026 Работы по развитию Системы (за исключением этапов проведения опытной эксплуатации и услуг по технической поддержке) могут быть выполнены досрочно. При досрочном выполнении работ (этапов работ) Подрядчик в письменной форме уведомляет Заказчика о готовности представить для приемки результаты проведения работ в соответствии с требованиями Контракта. Подрядчик также вправе досрочно приступать к работам в рамках очередного этапа при наличии технической, организационной готовности - при условии получения соответствующего согласования Заказчиком. Сдача-приемка результатов выполненных работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная, техническая документация, а также результаты Работ по каждому этапу предоставляется Заказчику в порядке, предусмотренном Контрактом и настоящим Техническим заданием, до размещения Подрядчиком в Единой информационной системе в сфере закупок документа о приемке. Документ о приемке размещается в ЕИС по каждому этапу в соответствии с условиями Контракта. Согласование документов осуществляется в электронном виде посредством переписки с адресов электронной почты Заказчика и Подрядчика, указанных в контракте. 6. ПОРЯДОК РАЗРАБОТКИ МОДУЛЯ СЦ Проектирование Модуля СЦ должно включать разработку следующих документов: – Ведомость технического проекта; – Ведомость машинных носителей информации – Пояснительная записка; – Описание информационного обеспечения системы; – Описание автоматизируемых функций; – Схема функциональной структуры; – Описание организации информационной базы; – Руководство по безопасной разработке программного обеспечения; – Описание программного обеспечения; – Макеты экранных форм компонента «Интерактивная карта». Структура документов должна соответствовать ГОСТ Р 59795-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов». Разработка Модуля СЦ должна включать в себя: – разработку программного обеспечения в части новых функций Модуля СЦ; – сборка исходного кода, развертывание и настройку доработанного программного обеспечения Модуля СЦ на вычислительных мощностях Заказчика (тестовый контур); – Комплект рабочей документации на Модуль СЦ; – разработку документа «Программа и методика предварительных испытаний»; – разработку документа «Программа и методика приемочных испытаний»; – разработку документа «Программа опытной эксплуатации». Структура документов должна соответствовать ГОСТ Р 59795-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов». В ходе выполнения работ формируется правоустанавливающая, отчетная, рабочая и техническая документация в соответствии с Контрактом и Календарным планом, приведенном в разделе 5. Значение характеристики не может изменяться участником закупки 6.1. Сведения о гарантийном обслуживании Модуля СЦ Под гарантией понимается устранение Подрядчиком своими силами и за свой счет допущенных по его вине недостатков, выявленных после приемки выполненных Работ, как в работе самой Модуля СЦ, так и недостатков в отчетной документации. Если в период гарантийного срока обнаружатся недостатки, то Подрядчик обязан устранить их за свой счет, в сроки, установленные Заказчиком. Гарантийный срок в этом случае продлевается на период устранения недостатков. Срок гарантии: 1 год с даты приемки Заказчиком результатов исполнения Этапа № 9 контракта. Подрядчиком должны быть внесены соответствующие исправления в техническую и рабочую документацию (указанную в пунктах 5 и 6 настоящего ТЗ), связанные с устранением замечаний к работе Модуля СЦ или в случае выявления Заказчиком недостатков в такой документации в период гарантийного срока. Внесение изменений в документацию технического и рабочего проектирования осуществляется в соответствии с ГОСТ 2.503-2023 и ГОСТ Р 2.504-2021. 7. ПОРЯДОК КОНТРОЛЯ И ПРИЕМКИ РЕЗУЛЬТАТОВ ВЫПОЛНЕНИЯ РАБОТ ПО РАЗВИТИЮ МОДУЛЯ СЦ До момента подключения внешних ИС, Подрядчиком могут быть использованы эмуляторы ИС для прохождения предварительных испытаний, опытной эксплуатации и приемочных испытаний. В рамках опытной эксплуатации должны быть проведены мероприятия по нагрузочному тестированию Модуля СЦ. Документ «Программа и методика приемочных испытаний» должен быть разработан с учетом недостатков, выявленных в ходе опытной эксплуатации, утвержден Заказчиком до начала приемочных испытаний, при этом проверки Модуля СЦ в части не устраненных недостатков, выявленных в процессе опытной эксплуатации, должны быть вынесены в отдельный раздел «Программы и методики приемочных испытаний». В процессе приемочных испытаний должно быть проверено устранение недостатков, полученных в ходе опытной эксплуатации. После завершения устранения всех замечаний, препятствующих приемке Системы в эксплуатацию, перечисленных в Протоколе приемочных испытаний, Подрядчик должен письменно уведомить Заказчика о том, что все замечания устранены, после чего приемочные испытания по решению Заказчика могут быть проведены повторно. Процедура приемочных испытаний проводится до подписания Протокола приемочных испытаний, не содержащего замечаний, препятствующих приемке Системы в эксплуатацию. Приемочные испытания Системы считаются завершенными успешно, если Протокол приемочных испытаний не содержит замечаний, препятствующих приемке Системы в эксплуатацию Значение характеристики не может изменяться участником закупки Испытания должны быть организованы и проведены в соответствии с ГОСТ Р 59792-2021 «Информационная технология. Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем». Должны быть проведены следующие виды испытаний: – предварительные испытания; – опытная эксплуатация; – приемочные испытания. Указанные виды испытаний проводятся в отношении не функциональных требований и функциональных возможностей, разрабатываемых в соответствии с настоящим ТЗ. Отдельные виды испытаний проводятся поэтапно в сроки, установленные Календарным планом. Предварительные испытания, опытная эксплуатация, приемочные испытания проводятся комиссией, создаваемой организационно-распорядительным документом Заказчика, который должен определять состав комиссии, порядок ее работы. Методы предварительных испытаний и порядок их проведения должны быть определены в документе «Программа и методика предварительных испытаний», который должен быть утвержден Заказчиком до начала предварительных испытаний. По результатам предварительных испытаний оформляется Протокол предварительных испытания и Акт о приемке в опытную эксплуатацию. Порядок проведения и методы испытаний во время опытной эксплуатации должны быть определены в документе «Программа опытной эксплуатации», который должен быть утвержден Заказчиком до начала опытной эксплуатации. Ход и результаты опытной эксплуатации отражаются в документе «Журнал опытной эксплуатации», и учитываются в ходе приемочных испытаний. По результатам опытной эксплуатации подписывается Акт о завершении опытной эксплуатации 8. ТРЕБОВАНИЯ К СОСТАВУ И СОДЕРЖАНИЮ РАБОТ ПО ПОДГОТОВКЕ МОДУЛЯ СЦ К ВВОДУ В ЭКСПЛУАТАЦИЮ По результатам проведения приемочных испытаний оформляется Протокол приемочных испытаний и Акт приемки в эксплуатацию. В случае, если взаимодействие с внешними системами не может быть проверено на средах постоянной эксплуатации взаимодействующих систем (по причине неготовности со стороны внешней системы или иным причинам), функции взаимодействия, разработанные в соответствии с требованиями ТЗ, должны быть проверены на тестовых данных с использованием программ-имитаторов взаимодействия. По результатам выполнения этапа приемочных испытаний должны быть подготовлены материалы для регистрации доработанной версии Модуля СЦ (объекта учета) в НФАП в соответствии с требованиями постановления Правительства Российской Федерации от 30 января 2013?г. №?62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин» (с изменениями и дополнениями) в части обязательности размещения результатов работ в национальном фонде алгоритмов и программ для электронных вычислительных машин. Сдача-приемка результатов выполнения Работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная, техническая документация, а также программное обеспечение предоставляется Заказчику в порядке, предусмотренном Контрактом и ТЗ до размещения Подрядчиком в Единой информационной системе в сфере закупок документа о приемке. Результаты проведения опытной эксплуатации, предварительных и приемочных испытаний должны быть зафиксированы в соответствующих протоколах и актах. Выявленные отклонения от настоящего ТЗ, оформляются как недостатки Модуля СЦ Значение характеристики не может изменяться участником закупки Протоколы предварительных и приемочных испытаний должны содержать вывод о соответствии Модуля СЦ предъявляемым требованиям, а также сроки устранения замечаний и реализации рекомендаций, сформулированных комиссией в ходе предварительных и приемочных испытаний. Условием для передачи Модуля СЦ в промышленную эксплуатацию является устранение всех замечаний. Документация на Модуль СЦ и ее части (техническая и рабочая) должна содержать исчерпывающее описание принятых проектных решений в объеме, достаточном для ее дальнейшего развития и эксплуатации. Техническая и рабочая документация должна содержать описание разработанных результатов работ, в том числе программ для ЭВМ, прикладных программных интерфейсов, алгоритмов и протоколов информационного взаимодействия, технических требований, спецификаций и форматов обмена данными для взаимодействия с другими информационными системами, в объеме, достаточном для их установки, настройки, эксплуатации и развития в дальнейшем без привлечения Подрядчика. Исходные коды передаются в виде и составе, позволяющем провести: – сборку (компиляцию) Модуля СЦ в контролируемой Заказчиком среде; – установку полученной Модуля СЦ на специально подготовленную контролируемую Заказчиком инфраструктуру; – проверку функциональных возможностей Модуля СЦ; – оформление Модуля СЦ в качестве объекта национального фонда алгоритмов и программ для электронных вычислительных машин 8.1. Требования, предъявляемые в соответствии с Приказом Минцифры России от 17.12.2020 № 715 «Об утверждении типовых условий контрактов на выполнение работ по созданию и (или) развитию (модернизации) государственных (муниципальных) и (или) иных информационных систем» Передача исходных кодов, разработанных в ходе выполнения работ, программ для электронных вычислительных машин (далее – программа для ЭВМ) должна сопровождаться передачей всех необходимых для сборки и запуска программы для ЭВМ библиотек зависимостей, программных сценариев (скриптов) для проведения установки (развертывания) программы для ЭВМ. Подрядчик в процессе сдачи-приемки работ по Контракту должен провести демонстрацию процесса и установки (развертывания) разработанных программ для ЭВМ. Документация на Модуль СЦ должна содержать описание принятых проектных решений в объеме, достаточном для ее дальнейшего развития и эксплуатации 9. ТРЕБОВАНИЯ К ДОКУМЕНТИРОВАНИЮ 9.1. Общие требования Документация на Модуль СЦ должна быть разработана в составе, указанном в разделах 5-8 данного ТЗ, и должна удовлетворять требованиям комплекса стандартов и руководящих документов на автоматизированные системы: – ГОСТ Р 2.105-2019 в части оформления текстовых документов; – ГОСТ 34.201-2020 в части наименования и обозначения документов. Документация на Модуль СЦ должны оформляться на листах формата А4. Допускается для размещения рисунков и таблиц использование листов формата А3 с подшивкой по короткой стороне листа. Документы объемом более 25 (двадцати пяти) листов должны содержать информационную часть, состоящую из аннотации и содержания. Исходные коды должны быть представлены в 1 (одном) экземпляре на электронном носителе, отчетные материалы должны быть представлены в 2 (двух) экземплярах на бумажном носителе (по одному экземпляру для Заказчика и Подрядчика) и в 1 (одном) экземпляре на электронном носителе в формате документов DOCX и PDF. При разработке документов на Модуль СЦ допускается отклонение от требований комплекса стандартов, описанных выше. Документам на Модуль СЦ должны в обязательном порядке присваиваться уникальные децимальные номера в соответствии с порядком, установленном в ГОСТ 34.201-2020. Документ «Программа и методика предварительных испытаний» должен включать приложения с формой протокола предварительных испытаний и формой акта приемки в опытную эксплуатацию. Документ «Программа опытной эксплуатации» должен включать приложение с формой журнала опытной эксплуатации. Документ «Программа и методика приемочных испытаний» должен включать приложения с формой протокола приемочных испытаний и формой акта приемки в эксплуатацию Значение характеристики не может изменяться участником закупки 10. ИСТОЧНИКИ РАЗРАБОТКИ 10.1. Список литературы Специальная литература для разработки ТЗ не использовалась. 10.2. Нормативно-методические документы Список используемых нормативно-методических документов представлен в разделе 1.6 технического задания. ? Приложение А Эскизы визуального оформления компонента «Интерактивная карта» Значение характеристики не может изменяться участником закупки Приложение Б Параметры оказания услуг Б.1. Базовые параметры оказания Услуг Базовые параметры оказания Услуг приведены ниже: – режимы оказания Услуг (таблица Б.1.1); – сроки предоставления отчетности (таблица Б.1.2). Таблица Б.1.1 - Режимы оказания Услуг № п/п Параметр Значение Значение характеристики не может изменяться участником закупки 1 Режим работы Системы Круглосуточно (24х7) 2 Режим доступности информационно-консультационной поддержки пользователей Системы 2.1 Прием и регистрация обращений (заявок) в СРО Регистрация обращений (заявок) производится круглосуточно в режиме 24х7, без праздников и выходных дней. Обработка заявок первой линией поддержки осуществляется в рабочие дни с 9 до 18 часов 2.2 Консультирование сотрудников Заказчика и пользователей Системы в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 3 Режим доступности по решению инцидентов, связанных с работой ППО: 3.1 - приоритет «Критический» Круглосуточно (24х7) 3.2 - приоритет «Высокий» Круглосуточно (24х7) 3.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 3.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4 Режим доступности услуг по адаптации, конфигурации и коррекционному сопровождению Системы 4.1 - приоритет «Критический» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.2 - приоритет «Высокий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 5 Режим доступности по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности 5.1 - приоритет «Критический» Круглосуточно (24х7) 5.2 - приоритет «Высокий» Круглосуточно (24х7) 5.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 5.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) Таблица Б.1.2. Сроки предоставления отчетности, с момента получения запроса № п/п Параметр Значение 1 Предоставление отчета об оказанных услугах за произвольный период 10 рабочих дней 2 Предоставление подробной информации по инциденту с приоритетом «Критический» 16 рабочих часов 3 Предоставление актуализированной документации 10 рабочих дней Б.2. Приоритеты и регламентные сроки решения обращений (заявок) В зависимости от уровня сбоя в работе Системы обращению (заявке) присваивается один из следующих приоритетов, а также в зависимости от приоритета обращения (заявки) устанавливаются следующие контрольные сроки решения в соответствии с таблицей ниже (Таблица Б.2.1). Таблица Б.2.1 – Приоритеты и регламентные сроки решения обращений (заявок) № п/п Приоритет Максимальное время реагирования Время решения (срок выполнения) Описание приоритета По информационно-консультационной поддержке сотрудников Заказчика и пользователей Системы 1 - не более 1 часа не более 10 часов - По решению инцидентов, связанных с работой ППО: 1 Критический не более 30 минут не более 4 часов - полная недоступность ППО; - недоступность ключевых функций - ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО; - невозможность информационного обмена с ППО для ИС более 4 часов 2 Высокий не более 1 часа не более 8 часов - ошибки/сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; - снижение быстродействия СПО (время отклика ППО на операции превышает 30 секунд); - недоступность управления правами и ролями пользователей 3 Средний не более 4 часов не более 24 часов - невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым -недоступность функции формирования отчетов 4 Низкий не более 8 часов не более 40 часов - отклонение в работе ППО, не влияющее на корректную работу функций; - другие сбои и ошибки, затрагивающие основные функции ППО По адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) 1 Критический не более 40 минут не более 8 часов - изменения, необходимые при проведении аварийно-восстановительных работ для возобновления работоспособности Системы; - изменения, связанные с критичными ошибками, блокирующими возможность оказания государственных услуг и/или чтение и внесение данных в Систему 2 Высокий не более 1 часа не более 40 часов - изменения, относящиеся к обеспечению работоспособности основной функциональности Системы, устраняют выявленные дефекты в работе Системы, оказывающие существенное влияние на работу пользователей в Системе; - изменения, затрагивающие три и более подсистемы/модуля Системы для адаптации 3 Средний не более 4 часов не более 72 часов - изменения, связанные с развитием/улучшением/оптимизацией Системы и выводом новой функциональности в штатном режиме для одного-двух модулей/подсистем; - изменения, связанные с развитием интеграционных механизмов Системы, например обновление существующих и/или реализация новых видов сведений СМЭВ, обновление существующих и/или реализация новых API, адаптация и/или изменение механизмов импорта и экспорта данных Системы и т.д. 4 Низкий не более 8 часов не более 160 часов - изменения, связанные с ошибками/корректировкой/изменением в отображении информации в пользовательском графическом интерфейсе Системы (графика, текст, органы управления, элементы интерфейса) По устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности 1 Критический не более 30 минут не более 24 часов - критические уязвимости, влияющие на возможную полную недоступность ППО, ключевых функций Системы, ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО без возможности восстановления работоспособности Системы. - Критический уровень CVSS > 8.0 2 Высокий не более 1 часа не более 84 часов - критические уязвимости, влияющие на ошибки и сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО. - Высокий уровень CVSS 5.0 - 8.0 3 Средний не более 4 часов не более 120 часов - уязвимости, влияющие на невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым - Средний уровень CVSS 2.0 - 4.9 4 Низкий не более 8 часов не более 160 часов - уязвимости, влияющие на отклонение в работе ППО, не влияющее на корректную работу функций; - другие сбои и ошибки, затрагивающие основные функции ППО - Низкий уровень CVSS < 2.0 Взаимодействие Заказчика и Подрядчика в части регистрации и контроля времени реагирования и решения обращения (заявки) осуществляется через СРО. Заказчик предоставляет Подрядчику доступ к СРО после заключения Контракта. Поступившие от разных пользователей заявки по поводу однотипных инцидентов или имеющие общую причину должны объединяться в одну заявку. Срок выполнения включает время диагностики инцидента, в ходе которого определяется причина инцидента (проблемы) и способ его устранения. Подрядчик должен обеспечить функционирование Модуля СЦ в соответствии с требованиями и параметрами, указанными в настоящем ТЗ и Регламенте оказании услуг. Основные параметры быстродействия типовых операций в Модуле СЦ указаны в таблице ниже (таблица Б.2.2). Таблица Б.2.2 - Параметры быстродействия Модуля СЦ № п/п Наименование параметра Значение (секунд) 1 Среднее время получения сообщения из очереди сообщений 10 2 Среднее время получения ответа от Системы 5 3 Среднее время открытия карточки реестра 5 Приложение В Регламент оказания услуг Уровень технической поддержки Организационно-структурная часть технической поддержки, имеющая определённые организационно-нормативными документами зоны ответственности, обязанности, а также временные нормативы, в течение которых эти обязательства должны выполняться либо эскалироваться на следующий уровень технической поддержки Услуги Услуги по технической поддержке Информационно-аналитической системы регулирования на транспорте АСУ ТК ФИО Фамилия, имя, отчество Эскалация Процедура повышения внимания к обращению (заявке) путем повышения его приоритета и/или передачи на следующий уровень технической поддержки, а также привлечение ролей, которые могут принимать решения без передачи на следующий уровень технической поддержки API Англ. Application Programming Interface — программный интерфейс приложения, интерфейс прикладного программирования — описание способов (набор классов, процедур, функций, структур или констант), которыми одна компьютерная программа может взаимодействовать с другой программой Значение характеристики не может изменяться участником закупки CVSS Англ. Common Vulnerability Scoring System - открытый стандарт, используемый для расчета количественных оценок уязвимости в безопасности компьютерной системы, обычно с целью понять приоритет ее исправления. В современном инструментарии информационной безопасности используется версия 3.0 и выше с дополнительными метриками к базовым оценкам ID Англ. Identifier – идентификатор, уникальный признак объекта, позволяющий отличать его от других объектов, то есть, идентифицировать SLA Англ. Service Level Agreement - утвержденные условия по обработке обращения (заявки) с установленными метриками времени, которые определяют пороговые значения для эскалации в зависимости от статуса обращения (заявки) (например, время реакции – время от регистрации до осуществления первичной обработки, время решения – время от регистрации обращения (заявки) до его решения и т.д.) SQL Англ. Structured Query Language — «язык структурированных запросов», — декларативный язык программирования, применяемый для создания, модификации и управления данными в реляционной базе данных, управляемой соответствующей СУБД 1 Общие сведения 1.1 Полное наименование Услуг Оказание услуг по технической поддержке Модуля СЦ АСУ ТК в 2026 году. 1.2 Предмет Регламента оказания услуг Требования Технического задания 2 Общие положения 2.1 Цель и задачи оказания услуг Целью технической поддержки Системы является обеспечение ее стабильного и безопасного функционирования и эксплуатации, предупреждение, выявление и устранение сбоев в работе Системы и минимизация их неблагоприятного влияния. Для достижения поставленной цели требуется решение следующих задач: 1. Обеспечение информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы. 2. Поддержание параметров функционирования ППО Системы, удовлетворяющих требованиям производственных процессов, включая их непрерывность. 3. Обеспечение бесперебойного функционирования ППО и своевременное устранение сбоев и аварийных ситуаций в Системе. 4. Своевременное устранение уязвимостей при выявлении таковых, в соответствии с требованиями к обеспечению информационной безопасности. 5. Адаптация, конфигурирование, коррекция программного обеспечения в соответствии с изменениями нормативно-правовой базы и запросами уполномоченных сотрудников органов государственной власти, включая выполнение процедур тестирования и участие в обновлениях ППО на стендах Заказчика. 6. Обеспечение сохранения работоспособности ППО в изменяемой среде эксплуатации. 7. Ведение документации по настоящему контракту и инициирование актуализации документации на Систему по результатам обработки запросов Заказчика и внесения соответствующих изменений в ППО Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 8) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 8) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 8) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 8) Категория обращения (заявки): инцидент Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 8) Приоритет Время, очередность решения обращения (заявки), ресурсы, привлекаемые для решения обращения (заявки), порядок/процедура действий при решении обращения (заявки) – поле СРО «Приоритет» (см. рисунок 8) Тип изменения Справочник, классифицирующий типовые запросы характерные для Системы – поле СРО «Предмет обращения» (см. рисунок 8) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 8) Текст запроса на оказание услуги по обновлению или удалению уязвимых компонентов (библиотек) ППО в соответствии с требованиями к обеспечению информационной безопасности Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 8) На рисунке 8 приведена форма обращения (заявки) типа «Инцидент» в СРО. Рисунок 8 - Форма обращения (заявки) типа «Инцидент» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуги по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности, заполненную в свободной форме Приложение 1 к Регламенту Матрица ответственных за взаимодействия в рамках выполнения работ по техническому сопровождению Системы Таблица 1 – Ответственные за взаимодействия в рамках выполнения работ по техническому сопровождению Системы со стороны Исполнителя ФИО Должность Адрес электронной почты Телефон — — — Общий контакт Приложение 2 к Регламенту Приоритеты и регламентные сроки решения обращений (заявок) Приоритеты и регламентные сроки решения обращений (заявок) приведены в таблице 1. Таблица 1 – Приоритеты и регламентные сроки решения обращений (заявок) № п/п Приоритет Максимальное время реагирования Время решения (срок выполнения) Описание приоритета По информационно-консультационной поддержке сотрудников Заказчика и пользователей Системы 1 – не более 1 часа не более 10 часов – 2.2 Общее описание процесса оказания сопровождения (технической поддержки) Системы Процесс оказания технической поддержки Системы включает: 1. Поступление обращений (заявок) от пользователей и их регистрацию. 2. Сопровождение обращений (заявок) в соответствии с их классификацией и приоритизацией, в том числе, с их последующей эскалацией. 3. Определение ролей и регламент их взаимодействия при осуществлении деятельности по процессу. 4. Решение обращений (заявок) в установленные настоящим Регламентом сроки. 5. Взаимодействие между 1-м, 2-м и 3-м уровнями технической поддержки, в том числе, с формированием заданий для сопровождения Системы. 6. Контроль качества выполняемых Исполнителем работ, состоящий из проверки сценария, приводящего к ошибке, зафиксированной в Инциденте, и/или к ошибке воспроизведения, а также тестирование внесенных изменений в рамках ЗНИ. 7. Обеспечение мониторинга и проведение анализа процесса обработки поступающих в техническую поддержку обращений (заявок). Техническая поддержка реализуется путем проведения ответственными сотрудниками соответствующей информационно-консультационной деятельности в соответствии с определенными ролями, а также выполнения Исполнителем конкретных действий по своевременному выявлению причин сбоев и аварийных ситуаций и их устранению, а также по адаптации, конфигурированию, корректировке Системы, включая выполнение процедур тестирования и участия в обновлениях Системы. Все роли подразделяются на уровни поддержки, взаимодействующие между собой в соответствии с блок-схемой процесса технической поддержки. Общая схема процесса рассмотрения обращений (заявок) в соответствии с видами технической поддержки представлена на рисунке 1. . Рисунок 1 - Общая схема процесса рассмотрения обращений (заявок) в соответствии с видами технической поддержки 2.3 Каналы связи Должна быть предусмотрена омниканальность в части приема обращений (заявок). Получение обращений (заявок) технической поддержкой происходит по следующим каналам связи: – СРО; – электронная почта; – телефонная линия. Исполнитель обеспечивает прием обращений (заявок) от Заказчика и предоставляет информацию в рамках оказания услуг по техническому сопровождению Системы, руководствуясь матрицей взаимодействия, приведенной в Приложении 1 к настоящему Регламенту 3 Порядок оказания Услуг 3.1 Типы обращений (заявок) Обращения и заявки Заказчика классифицируются в соответствии с приоритетами и регламентными сроками, указанными в Приложении 2 к настоящему Регламенту. Регистрация обращений и заявок предусматривает создание новой записи в СРО с присвоением поступившему обращению или заявке (новой записи) уникального идентификатора. Запись в СРО должна содержать вопрос или проблему, которую требуется решить или оказать консультацию. Если обращение или заявка автоматически зарегистрированы в СРО при отправке представителем Заказчика, Исполнитель проверяет корректность указанного типа обращения (заявки) и может обратиться к Заказчику с просьбой корректировки, предоставив обоснования в соответствии с настоящей классификацией (Таблица 1) По решению инцидентов, связанных с работой ППО 1 Критический не более 30 минут не более 4 часов – полная недоступность ППО; – недоступность ключевых функций; – ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО; – невозможность информационного обмена с ППО для ИС более 4 часов 2 Высокий не более 1 часа не более 8 часов – ошибки/сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; – снижение быстродействия СПО (время отклика ППО на операции превышает 30 секунд); – невозможность управления правами и ролями пользователей 3 Средний не более 4 часов не более 24 часов – невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым недоступность функции формирования отчетов 4 Низкий не более 8 часов не более 40 часов – отклонение в работе ППО, не влияющее на корректную работу функций; – другие сбои и ошибки, затрагивающие основные функции ППО По адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) 1 Критический не более 40 минут не более 8 часов – изменения необходимые при проведении аварийно-восстановительных работ для возобновления работоспособности Системы; – изменения, связанные с критичными ошибками, блокирующими возможность оказания государственных услуг и/или чтение и внесение данных в Систему 2 Высокий не более 1 часа не более 40 часов – изменения относящиеся к обеспечению работоспособности основной функциональности Системы, устраняют выявленные дефекты в работе Системы, оказывающие существенное влияние на процесс оказания государственных услуг и работу пользователей в Системе; – изменения, затрагивающие три и более подсистемы/модуля Системы для адаптации 3 Средний не более 4 часов не более 72 часов – изменения, связанные с развитием/улучшением/оптимизацией Системы и выводом новой функциональности в штатном режиме для одного-двух модулей/подсистем; – изменения, связанные с развитием интеграционных механизмов Системы, например, обновление существующих и/или реализация новых видов сведений СМЭВ, обновление существующих и/или реализация новых API, адаптация и/или изменение механизмов импорта и экспорта данных Системы и т.д. 4 Низкий не более 8 часов не более 160 часов – изменения, связанные с ошибками/ корректировкой/изменение в отображении информации в пользовательском графическом интерфейсе Системы (графика, текст, органы управления, элементы интерфейса) По устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности 1 Критический не более 30 минут не более 24 часов – критические уязвимости, влияющие на возможную полную недоступность ППО, ключевых функций Системы, ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО без возможности восстановления работоспособности Системы; – Критический уровень CVSS > 8.0 2 Высокий не более 1 часа не более 84 часов – критические уязвимости, влияющие на ошибки и сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; – Высокий уровень CVSS 5.0 - 8.0 3 Средний не более 4 часов не более 120 часов – уязвимости, влияющие на невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым; – Средний уровень CVSS 2.0 - 4.9 4 Низкий не более 8 часов не более 160 часов – уязвимости, влияющие на отклонение в работе ППО, не влияющее на корректную работу функций; – другие сбои и ошибки, затрагивающие основные функции ППО; – Низкий уровень CVSS < 2.0 Таблица 1 - Типы обращений (заявок) Тип обращения (заявки) Описание Запрос на обслуживание Подготовка SQL запроса к СУБД для решения прикладной задачи и д р. – запрос на любое действие, не являющееся запросом информации и несовершенный на основе происшествия, прямо или косвенно влияющего на работу Системы Консультация (входит в тип обращения (заявки) «Запрос на обслуживание») «Где взять / куда обратиться...?», «Как сделать / выполнить…», «Как это работает…?» - запрос, имеющий своей целью получение информационной поддержки Инцидент Разбор ошибок/сбоев и подготовка материалов (корректировочных релизов, инструкций) для Заказчика для устранения ошибок/сбоев, которые приводят к частичному и полному нарушению работоспособности всех или отдельных функций ППО. Подготовка изменения и материалов, необходимых для проведения аварийно-восстановительных работ для возобновления работоспособности Системы. ЗНИ Подготовка изменений, связанных с изменением, улучшением/оптимизацией Системы и выводом новой модифицированной функциональности в штатном режиме. Подготовка изменений, связанных с модификацией существующих и/или реализация новых интеграционных механизмов для получения/обработки данных внешних систем. Подготовка изменений графического интерфейса по требованиям Заказчика 3.2 Участники технической поддержки, осуществляющие сопровождение обращений (заявок) Техническая поддержка Системы должна быть организована на трех уровнях: 1. Первый и второй уровни технической поддержки организуется Заказчиком. 2. Третий уровень технической поддержки организуется Исполнителем. Зона ответственности каждого уровня технической поддержки указана в Таблице 2. Таблица 2 - Зона ответственности каждого уровня технической поддержки Участники технической поддержки Описание Первый уровень технической поддержки (далее – 1-й уровень) Группа ответственных сотрудников 1-го уровня Заказчика, осуществляющая прием и первичную обработку обращений (заявок) (описание предмета обращения, первичная классификация и приоритизация, определение назначения, маршрутизация обращений (заявок) по назначению), руководствуется в своей работе настоящим Регламентом и БЗ, наполняемой 2-м уровнем поддержки, самостоятельно решает часть обращений (заявок), связанных с недостаточной квалификацией пользователей или настройками в рамках своей компетенции. В случае невозможности решения обращений (заявок) на 1-ом уровне ответственный сотрудник передает ее на 2-й уровень Второй уровень технической поддержки (далее – 2-й уровень) Группа ответственных сотрудников 2-го уровня Заказчика по установленным компетенциям (информационная безопасность, сопровождение и эксплуатация информационно-аналитических систем, развитие информационно-аналитических систем, техническая поддержка информационно-аналитических систем) отвечает за поддержание работоспособности Системы, обработку обращений (заявок) и их решение в регламентные сроки в соответствии с установленными приоритетами. Осуществляет информационно-консультационную поддержку пользователей Системы в рамках своей компетенции. Оказывает экспертную помощь ответственным сотрудникам 1-го уровня в части формирования БЗ, содержащей ответы на часто задаваемые вопросы пользователей, с целью передачи знаний, навыков и инструментария на 1-й уровень для ускорения решения обращений (заявок). В случае невозможности решения обращения (заявки) на 2-ом уровне ответственный сотрудник передает его на 3-й уровень. При выявлении необходимости изменений в ППО Системы инициирует формирование обращения (заявки) и направляет его на группу ответственных сотрудников 3-го уровня по соответствующему классификатору (ЗНО, ЗНИ, и т.д.) Приложение Г Форма Отчета об оказанных услугах Отчет об оказанных услугах за этап «наименование этапа» в период с «__» _________ по «__» _________. № п/п Наименование услуги Общее количество Номер ОРС Краткое Описание Время реагирования по ТЗ Время реагирования фактическое Время решения по ТЗ Время решения фактическое Результат соблюдения времени реагирования Результат соблюдения времени решения Примечание 1 Услуги по информационно-консультационной поддержке работников Заказчика 2 546782 Консультация по работе Модуля СЦ 1 2 10 часов 11 часов Нет Нет 567123 Консультация по схеме БД 1 1 10 часов 1 час Да Да 2 … … Заказчик Подрядчик /Должность/ /Должность/ ____________________ /Ф.И.О/ ___________________ /Ф.И.О/ М.П. М.П. «_____»_______________________202_г. «_____»_______________________202_г Приложение 1 к Отчету об оказанных услугах Журнал обращений (заявок) на оказание услуги по информационно-консультационной поддержке пользователей Системы (шаблон) Наименование Исполнителя в этапе «наименование этапа» в период с ________________ по _______________ оказал(о) Услугу по поддержке пользователей Системы в объеме, указанном в Таблице 1 Таблица 1 - Журнал обращений (заявок) пользователей Системы № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. ИТОГО зарегистрировано: Всего обращений (заявок): ________ ИТОГО решено: Всего обращений (заявок): ________ Приложение 2 к Отчету об оказанных услугах Журнал обращений (заявок) по решению инцидентов, связанных с работой ППО (шаблон) Наименование Исполнителя в этапе «наименование этапа» в период с ________________ по _______________ оказал(о) Услугу по решению инцидентов в объеме, указанном в Таблице 1. Таблица 1 - Журнал по решению инцидентов № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. ИТОГО зарегистрировано: Всего инцидентов: ________ ИТОГО решено: Всего инцидентов: ________ Приложение 3 к Отчету об оказанных услугах Журнал обращений (заявок) выполнения адаптационного, конфигурационного и коррекционного сопровождения Системы (шаблон) Журнал выполнения адаптации, конфигурации и коррекции Системы сформирован за этап «наименование этапа» в период с «__» _________ по «__» ____________ и представлен в таблице ниже (Таблица 1). Таблица 1 - Журнал выполнения адаптации, конфигурации и коррекции сопровождения Системы № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. Количество выполненных заявок за этап: ________ Приложение 4 к Отчету об оказанных услугах Журнал обращений (заявок) по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности (шаблон) Журнал обращений (заявок) по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности сформирован за этап «наименование этапа» в период с «__» _________ по «__» ____________ и представлен в таблице ниже (Таблица 1). Таблица 1 - Журнал выполнения заявок по устранению уязвимостей в ППО № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. Количество выполненных заявок за этап: ________ Третий уровень технической поддержки (далее – 3-й уровень) Группа ответственных сотрудников Исполнителя, отвечающая за устранение сбоев и аварий, проведение информационно-консультационной поддержки пользователей Системы, проведение адаптации и конфигурирования Системы в объемах действующих контрактов на оказание технической поддержки 3.3 Перечень и описание статусов обращений (заявок) В Таблице 3 приведен перечень статусов обращений (заявок), действующий в СРО, и их описание. Таблица 3 - Перечень статусов обращений (заявок) и их описание Статус Описание Зарегистрирован Обращение (заявка) принято и зарегистрировано Направлен в группу Присваивается при назначении ответственными сотрудниками 1-го уровня группе ответственных сотрудников 2-го уровня по тематике обращения (заявки) после заполнения всей необходимой информации и полей обращения (заявки), а также при его передаче между группами 2-го уровня Передан в группу Присваивается при передаче обращения (заявки) ответственными сотрудниками 2-го уровня на группу ответственных сотрудников 3-го уровня Назначен Присваивается при назначении обращения (заявки) на ответственного сотрудника для его решения в рамках компетенции В работе Присваивается при приеме обращения (заявки) в работу ответственным сотрудником для его решения Решен Присваивается ответственным сотрудником, выполнившим работы по обращению (заявке) Закрыт Присваивается автоматически при решении запроса по обращению (заявке), а также отсутствии дополнительных запросов пользователя в соответствии с действующим SLA, или при подтверждении решения обращения (заявки) со стороны пользователя Запрос доп. информации Присваивается при необходимости запроса дополнительной информации и/или уточнения предмета обращения по обращению (заявке) у пользователя Ответ предоставлен Присваивается после ответа пользователем на запрос дополнительной информации Отклонен Присваивается, если обращение (заявка) не актуальна (по информации от пользователя), отсутствует техническая возможность решения обращения (заявки), предмет обращения не входит в компетенции технической поддержки, или существует влияние доработки на другие компоненты, что нарушает общий порядок работы Системы Согласование Присваивается при необходимости согласования направления обращения (заявки) ответственным сотрудником Заказчика на 3-й уровень Анализ Присваивается при проведении анализа на предмет возможности внесения изменений, связанных с развитием/улучшением/оптимизацией Системы и выводом новой функциональности и оценке ресурсоемкости Тестирование Присваивается Исполнителем при завершении разработки и проведенном предварительном тестировании для последующего осуществления приемочного тестирования Специалистом 2-го уровня Релиз Присваивается ответственным сотрудником Заказчика при принятии решения о возможности вывода доработки в продуктивную среду Утверждение заказчиком Присваивается при согласовании группой профильных специалистов на 2-м уровне поддержки с пользователем технического задания для внесения изменений, связанных с развитием/улучшением/оптимизацией Системы и выводом новой функциональности Доработка Присваивается в случае несогласования Заказчиком работ, проведенных Исполнителем в рамках контрактных обязательств, по внесению изменений, связанных с развитием/улучшением/оптимизацией Системы и выводом новой функциональности в штатном режиме, и необходимости последующего направления Исполнителю для ее доработки Отложен Присваивается в случае невозможности выполнения запроса, изложенного в обращении (заявке), в связи с необходимостью запроса дополнительной информации у третьих сторон Приложение Д Форма Протокола проверки результатов организационно-штатных и подготовительных мероприятий (шаблон) Протокол проверки результатов организационно-штатных и подготовительных мероприятий Настоящий Протокол содержит результаты проверки организационно-штатных и подготовительных мероприятий, проведенных Исполнителем (Таблица Д.1). Таблица Д.1. Протокол проверки результатов № Мероприятия Подготовительного этапа Результат проверки 1. Определить и направить Заказчику документ «Ответственные за взаимодействия в рамках выполнения работ по техническому сопровождению Системы со стороны Исполнителя». Документ содержит контактную информацию (ФИО, должность, адрес электронной рабочей почты, номер телефона) не менее чем о 2 лицах, ответственных за оказание услуг со стороны Подрядчика Выполнено/Не выполнено 2. Обеспечить подключение специалистов Подрядчика к Системе Выполнено/Не выполнено 3. Обеспечить подключение специалистов Подрядчика к СРО Выполнено/Не выполнено Заказчик Подрядчик /Должность/ /Должность/ ____________________ /Ф.И.О/ ___________________ /Ф.И.О/ М.П. М.П. «_____»_______________________202_г. «_____»_______________________202_г 3.4 Порядок регистрации и сопровождения Заявок Порядок регистрации и сопровождения обращений (заявок) в рамках оказываемых услуг по технической поддержке Системы зависит от типа обращения (заявки): 1. Услуга по решению инцидентов, связанных с работой ППО – тип обращения (заявки) «Инцидент». 2. Услуга по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности – тип обращения (заявки) «Инцидент». 3. Услуга информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы – тип обращения (заявки) «Запрос на обслуживание» (в том числе, консультационный запрос). 4. Услуга адаптационного, конфигурационного и коррекционного сопровождения Системы (в рамках действующих программных модулей и функциональностей) – тип обращения (заявки) «Запрос на изменение». В случае недоступности СРО взаимодействие и информирование Исполнителем о ходе оказания услуги по обращению (заявке), изменению статусов обращений (заявок) осуществляется по согласованию с Заказчиком в соответствии с матрицей взаимодействия, представленной в Приложении 1 к настоящему Регламенту. 3.4.1 Инцидент На рисунке 2 представлена функциональная схема регистрации и сопровождения обращений (заявок) типа «Инцидент». Рисунок 2 - Функциональная схема регистрации и сопровождения обращений (заявок) типа «Инцидент» 3.4.2 Запрос на обслуживание На рисунке 3 представлена функциональная схема регистрации и сопровождения обращения (заявки) типа «ЗНО». Рисунок 3 - Функциональная схема регистрации и сопровождения обращения (заявки) типа «ЗНО» 3.4.3 Запрос на изменение На рисунке 4 представлена функциональная схема регистрации и сопровождения обращений (заявок) типа «ЗНИ». Рисунок 4 - Функциональная схема регистрации и сопровождения обращений (заявок) типа «ЗНИ» 3.5 Порядок классификации и приоритизации обращений (заявок) Классификация является начальной стадией процесса оказания технической поддержки, необходимой для идентификации обращения (заявки) и определения соответствующих действий для его обработки. Для проведения первичной классификации необходимо получить от пользователя и зафиксировать в описании обращения (заявки) подробные сведения о сути запроса, в том числе, для Инцидентов зафиксировать сценарий воспроизведения обнаруженной ошибки. Для проведения вторичной классификации необходимо провести анализ и диагностику для определения корневой причины и затронутой Инцидентом функциональной области (инфраструктура, сеть, ППО). В процессе классификации осуществляется первичная диагностика и оценка проблемы, описанной пользователем Системы в обращении (заявке), в части функционирования и/или удобства использования Системы. Корректная классификация позволяет увеличить скорость обработки обращения (заявки) и решения описанной в обращении (заявке) проблемы при минимальном привлечении ресурсов, в частности, за счет использования известных решений для типовых обращений (заявок), которые должны описываться в БЗ СРО. Классификация позволяет произвести первоначальное назначение обращения (заявки) на ответственного сотрудника и выставить приоритет с учетом приоритизации. Приоритизация применяется для определения критичности описанной в обращении (заявке) проблемы для функционирования ППО Системы. Приоритет рассмотрения обращения (заявки) определяется в процессе ее классификации на основании ряда параметров, вводимых при заполнении обращения (заявки). Приоритизация используется для того, чтобы при одновременном наличии нескольких обращений (заявок) в первую очередь рассматривалась обращения (заявки) с наивысшим приоритетом и не позднее установленных для данного приоритета сроков Изменение приоритета уже зарегистрированного обращения (заявки) используется в случае появления новых обстоятельств, которые ведут к изменению влияния и/или срочности существующего обращения (заявки). При регистрации обращения (заявки) необходимо провести его приоритизацию. В процессе управления обращениями (заявками) каждому обращению (заявке) присваивается приоритет, принимающий одно из значений: Низкий, Средний, Высокий или Критический. В соответствии с приоритетом определяется время, очередность устранения, , ресурсы, привлекаемые для работ по обращению (заявке), а также может определяться порядок/процедура действий при работе с обращением (заявкой). Заказчиком в зависимости от уровня сбоя в работе Системы обращению (заявке) присваивается приоритет с указанием максимального времени реакции и решения в соответствии с требованиями, указанными в Приложении 2 к настоящему Регламенту 4 Формы обращений (заявок) на оказание услуг по технической поддержке Системы, заполняемые в СРО 4.1. Форма обращения (заявки) на оказание услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы При подаче обращения (заявки) типа «ЗНО» в СРО указывается (Таблица 5): Таблица 5 – Описание атрибутов формы обращения (заявки) на оказание услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 5) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 5) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 5) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 5) Категория обращения: информационно-консультационная поддержка Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 5) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 5) Текст запроса на оказание услуги по информационно-консультационной поддержке сотрудников Заказчика Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 5) На рисунке 5 приведена форма обращения (заявки) типа «ЗНО» в СРО. Рисунок 5 - Форма обращения (заявки) типа «ЗНО» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы, заполненную в свободной форме. Термины и сокращения В настоящем регламенте используются следующие термины и сокращения на русском и английском языках: Термины/сокращения Полное наименование/описание БЗ (База знаний) База данных Системы регистрации обращений (заявок), созданная для сбора, хранения и поиска способов решения известных проблем в рамках Системы Жизненный цикл обращения (заявки) Совокупность статусов, по которым проходит обращение (заявка), и правила перехода обращения (заявки) из одного статуса в другой Заказчик ФГБУ «СИЦ Минтранса России» – Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» ЗНИ Запрос на изменение – тип заявки, предполагающий внесение изменений в прикладное программное обеспечение Системы ЗНО Запрос на обслуживание – тип заявки, предполагающий работы по предоставлению консультации, предоставление доступа к Системе или стандартизированные типовые изменения конфигураций Системы Инцидент Тип заявки, классифицируемый как нештатное событие в работе компонентов функциональных задач Системы, которое привело или может привести к нарушению или снижению качества функционирования Системы ИС Информационная система Исполнитель Организация, которая определяется по результатам конкурсных процедур Классификация Анализ и заполнение классификационных полей справочными значениями, определяющими последовательность действий и этапов жизненного цикла заявки, а также порядок рассмотрения заявок Консультация Разъяснения по алгоритму работы, требуемых настроек прикладного программного обеспечения и технологии обработки данных при работе с Системой, предоставление информации Маршрутизация Определение процесса движения обращения (заявки) в Системе управления заявками между уровнями технической поддержки и организационными структурами на уровнях поддержки путем назначения обращения (заявки) в соответствии с его классификацией и выставленным приоритетом Обращение (заявка) Устное или письменное обращение пользователя АСУ ТК с вопросом, касающимся работоспособности АСУ ТК, по одному из определённых каналов связи: электронная почта, Система регистрации обращений (заявок) Пользователь Инициатор обращения (заявки) или пользователь Системы ППО Прикладное программное обеспечение Предмет обращения Справочник, классифицирующий типовые запросы в Системе регистрации обращений (заявок), характерные для Системы, выбранное значение определяет маршрутизацию обращения (заявки) (группу ответственных сотрудников) Приоритизация Значение, определяющее время, очередность решения обращений (заявок), ресурсы, привлекаемые для решения обращений (заявок), . Приоритет устанавливается в соответствии с масштабом выявленной проблемы, которая привела или может привести к нарушению или снижению качества функционирования Системы Релиз Выпуск версии прикладного программного обеспечения Системы, от разработки до тестирования и планового обновления Системы на продуктивной среде для установки изменений, связанных с развитием/улучшением/оптимизацией Системы Система, АСУ ТК, Информационно-аналитическая система регулирования на транспорте Информационно-аналитическая система, предназначенная для автоматизации и информационно-аналитического обеспечения процессов управления развитием транспортного комплекса Российской Федерации, обеспечения публичности деятельности органов государственного управления транспортным комплексом, а также обеспечения процессов оказания государственных услуг в электронном виде в сфере транспорта СМЭВ Система межведомственного электронного взаимодействия СПО Системное программное обеспечение СРО Система регистрации обращений (заявок) Статус обращения (заявки) Текущее состояние обращения (заявки) в жизненном цикле процесса оказания технической поддержки Системы СУБД Система управления базами данных 4.2. Форма обращения (заявки) на оказание услуги по решению инцидентов, связанных с работой ППО При подаче обращения (заявки) типа «Инцидент» в СРО указывается (Таблица 6): Таблица 6 – Описание атрибутов формы обращения (заявки) на оказание услуги по решению инцидентов, связанных с работой ППО Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 6) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 6) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 6,) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 6) Категория обращения (заявки): инцидент Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 6) Приоритет изменения Время - одно из значений: Низкий, Средний, Высокий или Критический. Определяет, очередность решения обращения (заявки), ресурсы, привлекаемые для решения обращения (заявки), порядок/процедура действий при решении обращения (заявки) – поле СРО «Приоритет» (см. рисунок 6,) Тип изменения Справочник, классифицирующий типовые запросы характерные для Системы – поле СРО «Предмет обращения» (см. рисунок 6) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 6) Полное описание инцидента, включая скриншоты и описание шагов, приведших к неисправности Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 6) Однократность/неоднократность Круг пользователей или компьютеров, затронутых данным инцидентом Действия, предпринятые для самостоятельного решения инцидента (при наличии) Версии используемого программного обеспечения на клиентской рабочей станции, где воспроизводится ошибка (операционная система, прикладное программное обеспечение) Дополнительная информация На рисунке 6 приведена форма обращения (заявки) типа «Инцидент» в СРО. Рисунок 6 - Форма обращения (заявки) типа «Инцидент» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуги по решению инцидентов, связанных с работой ППО, заполненную в свободной форме 4.3. Форма обращения (заявки) на оказание услуг по адаптационному конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) При подаче обращения (заявки) типа «ЗНИ» в СРО указывается (Таблица 7): Таблица 7 – Описание атрибутов формы обращения (заявки) на оказание услуг по адаптационному, конфигурационному и коррекционному сопровождению Системы Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 10) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 9) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 10) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 10) Категория обращения (заявки): запрос на изменение Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 7) Приоритет изменения Время, очередность решения обращения (заявки), ресурсы, привлекаемые для решения обращения (заявки), порядок/процедура действий при решении обращения (заявки) – поле СРО «Приоритет» (см. рисунок 7) Тип изменения Справочник, классифицирующий типовые запросы характерные для Системы – поле СРО «Предмет обращения» (см. рисунок 7) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 7) Текст запроса на оказание услуги по адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 7) На рисунке 7 приведена форма обращения (заявки) типа «ЗНИ» в СРО. Рисунок 7 - Форма обращения (заявки) типа «ЗНИ» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуг по адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей), заполненную в свободной форме 4.4. Форма обращения (заявки) на оказание услуги по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности При подаче обращения (заявки) типа «Инцидент» в СРО указывается (Таблица 8): Таблица 8 – Описание атрибутов формы обращения (заявки) на оказание услуг по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности - Наименование характеристики - Значение характеристики - Единица измерения характеристики - Инструкция по заполнению характеристик в заявке - ОПРЕДЕЛЕНИЯ, ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ - Автоматизированная система (АС) Система, состоящая из комплекса средств автоматизации, реализующего информационную технологию выполнения установленных функций, и персонала, обеспечивающего его функционирование (ГОСТ Р 59853-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения») АРМ Автоматизированное рабочее место АСУ ТК, Система Информационно-аналитическая система регулирования на транспорте АТС Автоматическая телефонная станция БД База данных ГИС Государственная информационная система ГОСТ Государственный стандарт ГЦОД СИЦ Минтранса России, ГЦОД Головной центр обработки данных ФГБУ «СИЦ Минтранса России» Дашборд Интерактивная аналитическая панель, графический интерфейс. ЕИС Единая информационная система в сфере закупок ЕСИА Единая система идентификации и аутентификации Заказчик Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» КИИ Критическая информационная инфраструктура Кластер Кла?стер (англ. cluster) – объединение нескольких однородных элементов, которое может рассматриваться как самостоятельная единица, обладающая определёнными свойствами Компонент Часть АС, выделенная по определенному признаку или совокупности признаков и рассматриваемая как единое целое (ГОСТ Р 59853-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения») Контракт Контракт на выполнение работ по развитию и оказанию услуг по технической поддержке Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК в 2026 году, заключаемый по результатам проведения конкурентной процедуры закупки в соответствии с требованиями Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» - - Значение характеристики не может изменяться участником закупки - Модуль iМинтранс Модуль сбора данных и представления показателей деятельности Министерства транспорта Российской Федерации iМинтранс АСУ ТК Модуль СЦ Модуль сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК НС Нештатная ситуация НСИ Нормативно-справочная информация ОТИ Объект транспортной инфраструктуры П-ГИС Геоинформационная подсистема П-ИВ Подсистема информационного взаимодействия П-НСИ Подсистема ведения нормативно-справочной информации и метаданных ПО Программное обеспечение Подрядчик, Исполнитель Организация, с которой будет заключен контракт на выполнение работ по развитию Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК П-СД Подсистема сбора данных Работы Работы по развитию Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК СЗИ Средство защиты информации СМЭВ Система межведомственного электронного взаимодействия СУБД Система управления базами данных ТЗ Техническое задание (настоящий документ) ТС Транспортное средство ТК Транспортный комплекс Учреждение Учреждения в области информационной безопасности - ФГБУ «СИЦ Минтранса России» Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации», Заказчик Федеральный закон № 44-ФЗ Федеральный закон от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» ФЗ Функциональная задача ФЗ «Реестр объектов» Функциональная задача «Формирование и ведение единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации» ФСБ России Федеральная служба безопасности Российской Федерации ФСТЭК России Федеральная служба по техническому и экспортному контролю ЧС Чрезвычайная ситуация ЭВМ Электронно-вычислительная машина API От англ. Application Programming Interface – интерфейс прикладного программирования – совокупность инструментов и функций в виде интерфейса для взаимодействия с программой CSS От англ. Cascading Style Sheets — каскадные таблицы стилей FPS От англ. frame per second - количество кадров в секунду HTML От англ. HyperText Markup Language - стандартный язык разметки документов, создающий основу и структуру всех веб-страниц JSON От англ. JavaScript Object Notation – текстовый формат обмена данными, основанный на JavaScript WebAssembly (Wasm) Открытый стандарт, представляющий собой низкоуровневый бинарный формат инструкций, который позволяет выполнять код, написанный на языках C++, Rust или Go, в браузерах с производительностью, близкой к нативной - 1. ОБЩИЕ СВЕДЕНИЯ - – ГОСТ Р 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.7. Сроки начала и окончания работ Начало работ: с даты заключения Контракта. Окончание работ: не позднее 15.12.2026. Работы выполняются в соответствии с этапами. Сроки выполнения этапов работ по развитию и технической поддержке Модуля СЦ определяются Календарным планом. Календарный план, приведен в разделе 5 настоящего ТЗ - 1.8. Общие сведения об источниках и порядке финансирования работ Источником финансирования являются средства субсидии федерального бюджета Российской Федерации, предоставленной в соответствии с абзацем вторым пункта 1 статьи 78.1 Бюджетного кодекса Российской Федерации (код цели 08-01) - 1.9. Порядок оформления и предъявления результатов работ Подрядчик должен передать Заказчику результаты работ в порядке, определенном Контрактом в сроки, установленные п. 5 настоящего ТЗ, в соответствии с Календарным планом - 1.10. Место выполнения Работ Работы выполняются удаленно на комплексе технических средств Заказчика. Адрес размещения комплекса технических средств Заказчика: Московская обл., Богородский район, пос. Горбуша, Радиоцентр. Техническая возможность удаленного подключения обеспечивается Заказчиком (в части предоставления параметров доступа). Оплата телематических и иных услуг, технических и программных средств, необходимых Подрядчику для удаленного подключения и для выполнения требований по информационной безопасности, осуществляется Подрядчиком самостоятельно за свой счет - 1.1. Наименование Системы Полное наименование системы: Информационно-аналитическая система регулирования на транспорте. Условное обозначение системы: АСУ ТК. Полное наименование модуля: Модуль сбора, ведения и анализа информации о нештатных ситуациях на транспорте. Условное обозначение модуля: Модуль СЦ. Модуль СЦ создан в рамках контракта от 05.08.2024 № ОК/24_04 на выполнение работ по развитию АСУ ТК в части создания модуля «Сбора, ведения и анализа информации о нештатных ситуациях на транспорте». Развитие Модуля СЦ осуществлено в рамках контракта от 19.05.2025 № ОК/25_09 на выполнение работ по развитию Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК - 1.2. Шифр темы или номер контракта Присваивается Заказчиком по результатам организации закупочных процедур. 1.2.1. Предмет контракта Выполнение работ по развитию Модуля СЦ. Код по ОКПД2: 62.01.11.000 – услуги по проектированию и разработке информационных технологий для прикладных задач и тестированию программного обеспечения. Оказание услуг по технической поддержке Модуля СЦ. Код по ОКПД2: 62.02.30.000 – услуги по технической поддержке информационных технологий. Выполнение работ по развитию Модуля СЦ предусмотрено с учетом ключевых результатов (ОКР) Ведомственной программы цифровой трансформации Минтранса России на 2026-2028 (далее - ВПЦТ Минтранса России) в составе мероприятия № 103.002 «АСУ ТК» ИТ расхода 103.26.000005 «Развитие Информационно-аналитической системы регулирования на транспорте (АСУ ТК)»: · «Обеспечено информационное взаимодействие с Минобороны о происшествиях на транспортных объектах»; · «Обеспечена автоматизация формирования отчетов о нештатных ситуациях на транспорте, в том числе по данным внешних систем». Выполнение работ по технической поддержке АСУ ТК предусмотрено ВПЦТ Минтранса России в составе мероприятия № 103.002 «АСУ ТК» ИТ расхода 103.26.000021 «Эксплуатация Информационно-аналитической системы регулирования на транспорте (АСУ ТК)» - 1.3. Заказчик Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» (ФГБУ «СИЦ Минтранса России»). Адрес: 107078, Москва, Садовая-Спасская ул., д.18, стр. 1. Оператором Системы является Заказчик - Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» (ФГБУ «СИЦ Минтранса России) - 1.4. Подрядчик Определяется по результатам проведения конкурентной процедуры закупки в соответствии с требованиями Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (далее – Федеральный закон № 44-ФЗ) - 1.5. Основания для выполнения работ Работы осуществляются на основании следующих документов: – постановление Правительства Российской Федерации от 30.12.2003 № 794 «О единой государственной системе предупреждения и ликвидации чрезвычайных ситуаций»; – постановление Правительства Российской Федерации от 08.11.2013 № 1007 «О силах и средствах единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций»; – распоряжение Правительства Российской Федерации от 27.11.2021 № 3363-р «О Транспортной стратегии Российской Федерации до 2030 года с прогнозом на период до 2035 года»; – Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 26.08.2025 №ЕФ-3; – Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 27.11.2025 №ЕФ-23; - – Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 19.02.2026 №ЕФ-1; – План мероприятий по профилактике случаев непроизводственного травматизма граждан на железнодорожном транспорте, являющийся приложением к постановлению коллегии Министерства транспорта Российской Федерации от 11.03.2026 № 2 - 1.6. Перечень документов, требования которых должны быть учтены при выполнении работ – Федеральный закон Российской Федерации от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации»; – Федеральный закон Российской Федерации от 27.07.2006 № 152-ФЗ «О персональных данных»; – Федеральный закон Российской Федерации от 06.04.2011 № 63-ФЗ «Об электронной подписи»; – Федеральный закон Российской Федерации от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации»; – Указ Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации»; – Указ Президента Российской Федерации от 01.05.2022 № 250 «О дополнительных мерах по обеспечению информационной безопасности Российской Федерации»; – Указ Президента Российской Федерации от 31.03.2010 № 403 «О создании комплексной системы обеспечения безопасности населения на транспорте»; – постановление Правительства Российской Федерации от 30.07.2004 № 395 «Об утверждении Положения о Министерстве транспорта Российской Федерации»; – постановление Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации»; – постановление Правительства Российской Федерации от 16.11.2015 № 1236 «Об установлении запрета на допуск программного обеспечения, происходящего из иностранных государств, для целей осуществления закупок для обеспечения государственных и муниципальных нужд»; – постановление Правительства Российской Федерации от 23.12.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 Федерального закона «Об электронной подписи»; - – постановление Правительства Российской Федерации от 08.06.2011 № 451 «Об инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг и исполнения государственных и муниципальных функций в электронной форме»; – постановление Правительства Российской Федерации от 30.01.2013 № 62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин»; – приказ ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации»; – приказ ФСТЭК России от 11.04.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений»; – приказ ФСБ России от 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 «Национальный стандарт Российской Федерации. Интеллектуальная собственность. Патентные исследования. Содержание и порядок проведения»; - 2. ЦЕЛИ И НАЗНАЧЕНИЕ ВЫПОЛНЕНИЯ РАБОТ - 2.1. Назначение АСУ ТК АСУ ТК предназначена для автоматизации и информационно-аналитического обеспечения процессов управления развитием транспортного комплекса Российской Федерации, обеспечения публичности деятельности органов государственного управления транспортным комплексом. Основными целями АСУ ТК являются: – повышение эффективности процессов управления функционированием и развитием транспортного комплекса на основе создания единой информационной среды и комплекса информационно-аналитических услуг на уровне органов государственного управления ТК; – повышение уровня безопасности ТК на базе получения полной, достоверной и оперативной информации о происходящих изменениях, своевременного выявления негативных тенденций и для принятия соответствующих мер по их устранению и ликвидации последствий - - Значение характеристики не может изменяться участником закупки - Основными задачами АСУ ТК являются: – автоматизация процессов прогнозирования развития транспортного комплекса и поддержки принятия управленческих решений; – автоматизация процессов мониторинга безопасности и устойчивости транспортного комплекса, управления в чрезвычайных и нештатных ситуациях; – автоматизация процессов управления программами и проектами развития и модернизации транспортного комплекса; – автоматизация процессов мониторинга состояния транспортного комплекса, в том числе с использованием набора ключевых показателей эффективности деятельности транспортного комплекса; – информационно-технологическая поддержка взаимодействия субъектов транспортного комплекса Российской Федерации, органов государственного управления и контроля, международных организаций на основе создания единой технологической среды взаимодействия и управления движением данных (и связанных с ними документов) в транспортном комплексе; – использование в процессах управления транспортным комплексом РФ современных технологий электронного документооборота и электронного обмена данными; – организация межведомственного электронного взаимодействия подразделений Министерства транспорта Российской Федерации, подведомственных агентств и службы с другими организациями - 2.2. Назначение и цели развития и технической поддержки Модуля СЦ Назначение Модуля СЦ: – оперативный мониторинг нештатных и чрезвычайных ситуаций на транспорте ; – оповещение заинтересованных лиц и структур о нештатных и чрезвычайных ситуациях; – сбор, обработка и хранение данных о нештатных и чрезвычайных ситуациях. Целями развития Модуля СЦ являются: – расширение состава данных об оперативной обстановке на транспорте; – оптимизация процесса сбора данных об оперативной обстановке на транспорте; – повышение информированности пользователей за счет визуализация данных Модуля СЦ; – автоматизация процесса формирования отчетов о ЧС и нештатной ситуации на транспорте; – обеспечение информационного взаимодействия с заинтересованными организациями по вопросам ведения. - Целями оказания услуг по технической поддержке являются: – обеспечение информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы; – поддержание параметров функционирования ППО Системы, удовлетворяющих требованиям производственных процессов, включая их непрерывность; – обеспечение бесперебойного функционирования ППО и своевременное устранение сбоев и аварийных ситуаций в Системе; – своевременное устранение уязвимостей при выявлении таковых, в соответствии с требованиями к обеспечению информационной безопасности; – адаптация, конфигурирование, коррекция программного обеспечения в соответствии с изменениями нормативно-правовой базы и запросами уполномоченных сотрудников органов государственной власти, включая выполнение процедур тестирования и участие в обновлениях ППО на стендах Заказчика; – обеспечение сохранения работоспособности ППО в изменяемой среде эксплуатации; – ведение документации по настоящему ТЗ, инициирование и актуализация документации на Систему по результатам обработки запросов Заказчика и внесении соответствующих изменений в ППО. Модуль СЦ применяется в деятельности Министерства транспорта Российской Федерации, подведомственных агентств и службы и другими организациями в соответствии с соглашениями об информационном обмене - 3. ХАРАКТЕРИСТИКА ОБЪЕКТА АВТОМАТИЗАЦИИ - 3.1. Описание объекта автоматизации АСУ ТК Объектом автоматизации являются процессы основной и обеспечивающей деятельности, направленные на управление транспортным комплексом, в том числе, процессы информационного взаимодействия с другими организациями и субъектами транспортного комплекса. АСУ ТК относится к государственным информационным системам, а также к информационным системам персональных данных и значимым объектам критической информационной инфраструктуры Российской Федерации. АСУ ТК соответствует требованиям, предъявляемым к: – ГИС второго класса защищенности в соответствии с приказом ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах»; – ИС персональных данных при обеспечении третьего уровня защищенности персональных данных в соответствии с требованиями постановления Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»; – значимым объектам КИИ Российской Федерации второй категории значимости с постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении Правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений». Модуль СЦ является подсистемой АСУ ТК. Перечень платформенных решений и функциональных задач АСУ ТК представлен в Таблице 1 - - Значение характеристики не может изменяться участником закупки - Таблица 1 – Перечень платформенных решений и функциональных задач АСУ ТК № Наименование подсистемы/ функциональной задачи/ модуля Назначение 1 Подсистема сбора данных и централизованного хранилища данных Подсистема обеспечивает выполнение сбора данных в АСУ ТК, и в т. ч., в рамках функциональных задач «Формирование и ведение межрегионального транспортного баланса пассажирских перевозок в дальнем (межрегиональном) сообщении» и «Формирование и ведение транспортного паспорта региона» 2 Подсистема информационного взаимодействия Подсистема информационного предназначена для обеспечения информационного взаимодействия подсистем АСУ ТК, а также, взаимодействия АСУ ТК с АС федеральных органов исполнительной власти 3 Подсистема ведения нормативно-справочной информации и метаданных Подсистема предназначена для автоматизации функций формирования и актуализации справочников, классификаторов, реестров и регистров, необходимых для обеспечения информационной поддержки пользователей НСИ и интеграции подсистем АСУ ТК в части применения НСИ 4 Модуль СМЭВ Модуль взаимодействия со СМЭВ представляет собой набор сервисов взаимодействия: сервис синхронного взаимодействия и сервис отправки, осуществляющих дополнительную обработку сообщений, отправляемых в СМЭВ и принимаемых из СМЭВ 5 Геоинформационная подсистема Программное обеспечение геоинформационной подсистемы предназначено для обеспечения смежных подсистем АСУ ТК возможностью работы с картографической информацией, в том числе, отображения на электронных картах объектов транспортной инфраструктуры и получения информации о местоположении, характеристиках контролируемых транспортных объектов 6 Подсистема информационного портала АСУ ТК Подсистема информационного портала предназначена для отображения и входа в функциональные задачи АСУ ТК 7 Подсистема технического портала АСУ ТК Подсистема технического портала АСУ ТК предназначена для управления заявками пользователей и технологического документооборота заявок - 8 Подсистема проектного архива АСУ ТК Подсистема проектного архива АСУ ТК предназначена для автоматизации деловых процессов должностных лиц Министерства транспорта Российской Федерации, подведомственных агентств и службы, в том числе, и процессов информационного взаимодействия внутреннего и внешнего характера 9 ФЗ «Реестр объектов» Функциональная задача предназначена для формирования и ведения единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации 10 ФЗ «СТП» Функциональная задача предназначена для организации информационно-аналитической поддержки процессов территориального планирования Российской Федерации в области федерального транспорта 11 ФЗ «МРТБ ПП» Функциональная задача предназначена для формирования и ведения межрегионального транспортного баланса пассажирских перевозок в дальнем (межрегиональном) сообщении 12 ФЗ «МДД» Функциональная задача предназначена для осуществления мониторинга дорожного движения 13 ФЗ «ТПР» Функциональная задача предназначена для формирования и ведения транспортного паспорта региона 14 ФЗ «Данные по грузообороту» Функциональная задача предназначена для обеспечения подсистем и пользователей АСУ ТК данными по грузообороту между Российской Федерацией и зарубежными странами 15 ФЗ «МЖТ» Функциональная задача предназначена для осуществления мониторинга железнодорожного транспорта 16 ФЗ «МГМП» Функциональная задача предназначена для осуществления мониторинга грузопотоков в морских портах с целью формирования единой цифровой среды мониторинга и планирования перевозок в/из портов Дальнего Востока - 17 Модуль ГЭТ Модуль предназначен для получения, хранения данных инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по отдельно взятому предприятию-перевозчику. Формирования отчетов об инвентаризации с детальными данными по каждому разделу инвентаризации с маршрутизацией в муниципалитет / регион / Минтранс. Содержит агрегированные данные инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по всем перевозчикам, относящихся к данному муниципалитету. Формирует сводный отчет по муниципалитету по каждому разделу инвентаризации с маршрутизацией в регион / Минтранс. Формирует агрегированные данные инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по всем перевозчикам, относящиеся к данному региону и по всем муниципалитетам, относящимся к данному региону. Аналитические и статистические данные о состоянии ГЭТ региона. Содержит данные о видах транспорта, цифровых транспортных сервисах и платежных инструментах Региона. Формирует сводный отчет по каждому разделу инвентаризации с маршрутизацией в Минтранс. Формирует агрегированную статистику и аналитику по всем регионам страны в разрезе транспортных средств, маршрутов, пассажиропотоков, инфраструктуры ГЭТ. Данные о рейтинге регионов и перевозчиков на основании выбранных параметров, документооборот с участниками Системы: получение подписанных печатных форм, их утверждение, возврат на доработку. 18 Модуль iМинтранс Модуль создан для отчета по ключевым показателям транспортного комплекса России (Отраслевые и статистические показатели, исполнение бюджета, исполнение поручений, аналитика СМИ, происшествия по видам транспорта). 19 Модуль СЦ Модуль СЦ предназначен для оперативного мониторинга нештатных ситуаций транспортной отрасли, оповещения заинтересованных лиц и структур и предоставления данных о нештатных ситуациях - АСУ ТК осуществляет идентификацию и авторизацию посредством Единой системы идентификации и аутентификации (ЕСИА). Информационный обмен с внешними информационными системами осуществляется посредством СМЭВ 3 и СМЭВ 4. АСУ ТК развернута на вычислительных мощностях ГЦОД СИЦ Минтранса России - 3.2. Описание и текущее состояние объекта автоматизации Модуля СЦ Объектом автоматизации является процесс организации мониторинга информации о НС и ЧС на транспорте. Предметом деятельности Учреждения являются следующие функции: – информационное обеспечение в области транспортной безопасности, защиты населения и территорий от чрезвычайных ситуаций природного и техногенного характера в транспортном комплексе; – подготовка справочных материалов при угрозе возникновения и возникновении чрезвычайных ситуаций и иных происшествий в транспортном комплексе; – взаимодействие и обмен оперативной информацией с органами управления Единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций; – организация оперативного мониторинга обстановки на объектах транспорта при угрозе и возникновении чрезвычайных ситуаций и иных происшествий. Перечень компонентов Модуля СЦ и выполняемые ими функции представлены в Таблице 2 - Таблица 2. Перечень компонентов Модуля СЦ и их функции № п/п Компонент Выполняемые функции 1 Регистрация событий – ведение карточки события; – удаление комментария; – динамическое отображение существующих событий в заданном радиусе и за заданный период; – возможность автоматической проверки вводимых данных в части количества пострадавших; – отображение карточки ОТИ, ТС в соответствии с ФЗ Реестр объектов; – сохранение и отображение версии карточки события; – привязка события к координатам по картографической основе; – указание признака выполнения действия по отработке события; – перевод статуса события; – закрытие карточки события; – публикация информации о событии в канале мессенджера; – возможность перехода из карточки события на картографическую основу для просмотра местоположения события 2 Визуализация – отображение событий на картографической основе в виде пиктограмм; – масштабирование карты; – отображение краткой карточки события при выборе события на картографической основе; – отображение списка событий; – отображение карточки события; – отображение журнала действий пользователя; – отображение дополнительной информации (текстовая информация и приложенные файлы); – отображение справки о событиях и отчета о событиях; – отображение фильтров и количества отфильтрованных объектов; – отображение результатов поиска; – отображение статистики по событиям на экране; – возможность создания события с картографической основы; – отображения картографических слоев в зависимости от примененных фильтров; – возможность настройки шага картографической сети; – возможность настройки географической точки центра карты; – отображение количества непрочитанных сообщений; – возможность перехода к детальной карточке события из краткой карточки события при выборе события на картографической основе - 3 Информирование – ведение справочника способов оповещения (веб-интерфейс, мессенджер); – формирование сценария выполнения оповещения (настройка условий, способа, параметров оповещения); – выполнение оповещений пользователей 4 Отчетность – формирование отчета и справки о событиях; – фильтрация событий для выгрузки в справку о событиях или в отчет о событиях 5 Администрирование – ведение ролей пользователей; – ведение учетных данных пользователей; – ведение справочника организаций; – ведение справочника групп системы мгновенного обмена сообщениями; – выполнение исходящего звонка на контактный телефонный номер организации; – формирование матрицы эскалации событий Архитектура Модуля СЦ представлена на рисунке 1. Рисунок 1. Архитектура Модуля СЦ - 3.3. Состав используемого ПО Модуля СЦ Программная архитектура Модуля СЦ разработана как трехуровневая клиент-серверная архитектура. Архитектура включает в себя следующие уровни: • уровень представления – презентационный уровень, обеспечивающий взаимодействие с пользователя с клиентскими приложениями с использованием веб-браузера («тонкий» клиент); • уровень приложений – реализован в виде сервисов, обеспечивает обработку запросов, поступающих от клиентских приложений, формирование ответов на запрос в доступном пользователю виде (формирование пользовательских интерфейсов); • уровень хранения данных – реализуется как сервер БД и обеспечивает хранение и целостность хранимых данных, создание резервных копий, ведение журнала транзакций, восстановление данных после сбоев. Программная архитектура Модуля СЦ включает в себя сервисы и интерфейсы, указанные в Таблице 3. Таблица 3. Программная архитектура Модуля СЦ Программный сервис/интерфейс Технологии реализации Уровень представления Интерфейс пользователя и администратора (front-end) Javascript Уровень приложений Сервис (GateWay) Kotlin Сервис геокодирования (geocoding-service) Kotlin Сервис уведомлений (notifiсation-service) Kotlin Сервис работы с файлами (file-service) Kotlin Сервис отчетности (report-service) Kotlin Сервис управления событиями (event-service) Kotlin Сервис информирования через мессенджер (messenger-notifier) Python Сервис внешних интеграций (integration-service) Сбор информации из внешних систем и сервисов Брокер сообщений Kafka Уровень хранения данных Файловое хранилище MinIO S3 СУБД Postgres Pro Enterprise - 3.4. Информационное взаимодействие программных сервисов и интерфейсов Модуля СЦ Объект автоматизации функционирует в распределенной информационной среде. Обмен данными осуществляется по защищенным каналам связи (в том числе ведомственным сетям передачи данных). Источники информации включают: · внешние автоматизированные системы (органов государственной власти); · внутренние базы данных (реестры объектов транспортной инфраструктуры, паспорта регионов и пр.); · оперативная информация от персонала, поступающая через автоматизированные рабочие места (АРМ) и мобильные устройства. 3.4.1. Взаимодействие Модуля СЦ со смежными подсистемами АСУ ТК Модуль СЦ входит в состав АСУ ТК и взаимодействует со следующими ее функциональными задачами и подсистемами: · Функциональной задачей «Формирование и ведение единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации» (ФЗ «Реестр объектов»); · Геоинформационной подсистемой АСУ ТК (П-ГИС); · Подсистемой ведения нормативно-справочной информации и метаданных (П-НСИ); · Подсистемой сбора данных и централизованное хранилище данных (П-СД); · Подсистемой информационного взаимодействия (П-ИВ). 3.4.2. Взаимодействие с внешними информационными системами Список внешних информационных систем, с которыми осуществляется взаимодействие Модуля СЦ: · ЕСИА; · мессенджер; · Яндекс Геокодер; · Информационная система «Централизованная система сбора информации систем-112»; · ПВК «Поиск-Море», АИС РПТ; · облачная АТС - 3.5. Требования к эксплуатации Применяемое в Системе программное обеспечение, программно-аппаратные и аппаратные комплексы должны соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации» - 4. ТРЕБОВАНИЯ К МОДУЛЮ СЦ - Таблица 6. Категории обращений и заявок Категория Примеры Запрос на обслуживание Подготовка SQL запроса к СУБД для решения прикладной задачи и д.р. – запрос на любое действие, не являющееся запросом информации и несовершенный на основе происшествия, прямо или косвенно влияющего на работу Модуля СЦ Консультация «Где взять / куда обратиться...?», «Как сделать / выполнить…», «Как это работает…?» - запрос, имеющий своей целью получение информационной поддержки Инцидент Разбор ошибок/сбоев и подготовка материалов (корректировочных релизов, инструкций) для Заказчика для устранения ошибок/сбоев, которые приводят к частичному и полному нарушению работоспособности всех или отдельных функций ППО. Подготовка изменения и материалов, необходимых для проведения аварийно-восстановительных работ для возобновления работоспособности Модуля СЦ ЗНИ Подготовка изменений, связанных с изменением, улучшением/оптимизацией Модуля СЦ и выводом новой модифицированной функциональности в штатном режиме. Подготовка изменений, связанных с модификацией существующих и/или реализация новых интеграционных механизмов для получения/обработки данных внешних систем. Подготовка изменений графического интерфейса по требованиям Заказчика. Перечень статусов обращений (заявок) приведен в пункте 3.3. Регламента оказания Услуг. Назначение обращению (заявке) статуса «Закрыто» осуществляется Заказчиком только после получения от инициатора обращения (заявки) подтверждения о его исполнении или нахождения обращения (заявки) в статусе «Выполнено» и отсутствия повторных вопросов/запросов по данному обращению (заявки) в течение 5 рабочих дней. Категории и статусы обращений (заявок) могут быть скорректированы в процессе оказания услуг исключительно по согласованию с Заказчиком - - Значение характеристики не может изменяться участником закупки - 4.3.6. Требования к услугам технической поддержки 4.3.6.1. Требования к организации третьего уровня технической поддержки Основными задачами организации третьего уровня технической поддержки в рамках оказания услуг по технической поддержке Модуля СЦ являются организация эксплуатационной службы Подрядчика, проверка готовности технических и программных средств для обеспечения непрерывного функционирования ППО Модуля СЦ. Подрядчиком должны быть проведены организационно-штатные и подготовительные мероприятия (в т. ч. технические) в рамках организации технической поддержки Модуля СЦ. Подрядчик в течение 5 (пяти) рабочих дней с даты заключения Контракта должен: – определить и направить Заказчику документ «Перечень уполномоченных специалистов», содержащий контактную информацию (ФИО, должность, адрес рабочей электронной почты) лиц, ответственных за оказание услуг со стороны Подрядчика; – обеспечить подключение специалистов Подрядчика к Системе регистрации обращений (заявок) (СРО предоставляется Заказчиком) для оказания услуг; – согласовать с Заказчиком способ доступа Подрядчика к Модулю СЦ. Результат выполнения мероприятий фиксируется в Протоколе проверки результатов организационно-штатных и подготовительных мероприятий (см. Приложение Д к настоящему ТЗ) - 4.3.6.2. Требования к услугам информационно-консультационной поддержки работников Заказчика и пользователей Модуля СЦ Услуги информационно-консультационной поддержки сотрудников Заказчика включают: – обработку обращений и заявок, поступивших от сотрудников Заказчика; – консультирование сотрудников Заказчика и пользователей Модуля СЦ; – актуализацию документации, и других материалов по работе с Модулем СЦ при необходимости. – консультирование и разработку рекомендаций по настройке Модуля СЦ (без изменения программного кода), включая изменение настроек функционирования; – консультации по вопросам использования, настройки и возможностям Модуля СЦ; – консультации по проведению превентивных мер для недопущения аварийных ситуаций в Модуле СЦ; – консультации по предварительной диагностике и локализации возникшей неисправности Модуля СЦ; – консультации по вопросам обеспечения информационной безопасности Модуля СЦ и настройки функций, обеспечивающих корректную работу программного обеспечения для совершения юридически значимых действий в Модуле СЦ; – другие вопросы, связанные с работой Модуля СЦ. 4.3.6.2.1. Требования к порядку оказания услуг информационно-консультационной поддержки работников Заказчика и пользователей Модуля СЦ Подрядчик выполняет консультирование сотрудников Заказчика и пользователей Модуля СЦ. Консультация может быть предоставлена по согласованным с представителем Заказчика каналам коммуникации с регистрацией результата консультации в СРО Подрядчиком. Детальный порядок оказания консультационных услуг определен в Регламенте оказания Услуг - 4.3.6.3. Требования к услугам по решению инцидентов, связанных с работой ППО Подрядчик устраняет неисправности Модуля СЦ, связанные с работой ППО, выявленные в рамках оказания услуг согласно настоящему Техническому заданию, при этом в зону ответственности Подрядчика не входит устранение неисправностей, выявленных на стороне Заказчика и на стороне третьих лиц (провайдера связи, поставщика электропитания и т.д.). Первичная диагностика выявленной неисправности проводится на 1 и 2 уровнях технической поддержки и не входит в зону ответственности Подрядчика. Если при проведении первичной диагностики и попытке устранить неисправности на 1 и 2 уровнях технической поддержки, данную неисправность устранить не удалось и в процессе диагностики было выявлено, что проблема связана с работоспособностью ППО, обращение (заявка) назначается сотруднику Подрядчика, ответственному за оказание услуг технической поддержки 3 уровня. Инцидентами вне зоны ответственности Подрядчика являются: – работоспособность функциональности, выходящая за рамки текущей реализации функций в Модуле СЦ и/или являющаяся расширением требований Заказчика к функциям Модуля СЦ; – проведение профилактических и плановых работ, согласованных с Заказчиком; – нарушение работоспособности функций Модуля СЦ, вызванное проведением работ на стороне Заказчика - Работы по устранению неисправности приостанавливаются (по согласованию с Заказчиком) в следующих случаях: – если Подрядчиком в результате диагностики выявлено, что неисправность находится в зоне ответственности Заказчика. Подрядчик информирует Заказчика о выявленной неисправности в зоне его ответственности по согласованным каналам связи; – требуется действие со стороны Заказчика – до момента выполнения данного действия Заказчика. Заказчик информируется о необходимых действиях по согласованным каналам связи; – отсутствие возможности связаться со специалистами Заказчика, участие которых необходимо для устранения неисправности; – требуется доставить оборудование на объект – до момента доставки и установки оборудования. В случаях, представленных выше, время приостановки работ не входит в учет продолжительности устранения неисправности. Учет времени устранения неисправности Подрядчиком считается с момента назначения Инцидента специалисту Подрядчика, ответственному за оказание услуг технической поддержки 3 уровня. Подтверждение необходимости приостановления работ находится в зоне ответственности Подрядчика. Приостановление сроков выполнения задач в соответствии с настоящим пунктом подтверждается Заказчиком по мотивированному обращению Подрядчика в СРО, основанному на данных диагностики или на иных фактических обстоятельствах - В случае непринятия Подрядчиком необходимых мер по информированию Заказчика (отсутствие надлежащего обращения от Подрядчика или отсутствие уведомления о необходимости осуществления каких-либо действий Заказчиком) не может являться основанием для приостановления работ по устранению неисправности. В отдельных случаях Подрядчику может потребоваться выполнение технологических работ для устранения причин неисправности или недопущения повторения их в будущем. Для обеспечения устранения неисправности Модуля СЦ Заказчиком проводится классификация в соответствии с приоритетами по степени срочности их устранения. Продолжительность устранения неисправности, а также периодичность информирования Подрядчиком Заказчика о ходе устранения неисправности, определены в Регламенте оказания услуг. При подаче обращения (заявки) наивысшего приоритета через СРО Заказчик должен дополнительно проинформировать службу поддержки Подрядчика о созданном обращении (заявки) по телефону уполномоченного сотрудника Подрядчика. При этом временем подачи обращения (заявки) считается время подачи обращения (заявки) через СРО - 4.3.6.4.1. Требования к проведению изменений Основанием для внесения изменений является запрос от Заказчика. Все активности по внесению изменений должны быть согласованы с Заказчиком, а действия Подрядчика при оказании данной услуги должны быть зафиксированы. В рамках данного Технического задания изменениями считаются локальные доработки функционала Модуля СЦ, которые не должны приводить к необходимости выполнения дополнительных аттестационных испытаний или переаттестации АСУ ТК в соответствии с п. 33 приказа от 29.04.2021 № 77 «Об утверждении Порядка организации и проведения работ по аттестации объектов информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну». При необходимости внесения изменений в Модуль СЦ, не связанных с критичным инцидентом, существенно нарушающим работоспособность Модуля СЦ, Заказчик направляет Подрядчику обращение (заявку), в котором излагает суть изменения, которое требуется внести в Модуль СЦ. Исполнитель, в течение 3 (трех) рабочих дней с момента поступления соответствующего обращения (заявки), оценивает техническую возможность реализации запрашиваемого изменения и варианты реализации. По итогу проведения оценки Подрядчик направляет Заказчику заключение о возможности реализации данного изменения с описанием возможных вариантов реализации и согласует с Заказчиком проведение данного изменения - При проведении работ по изменению и адаптации Подрядчик должен: – обеспечить выполнение требований безопасной разработки программного обеспечения; – обеспечить предварительное проектирование технических решений и согласование с Заказчиком проекта реализации изменения; – использовать семантическое версионирование (SemVer) в работе, передать Заказчику все артефакты разработки (исходный код и сторонние библиотеки, конфигурации, сборочные и собранные образы и др.); – подготовить полноценное описание функционала, включенного в релиз, с необходимыми схемами и пояснениями к обновлению на стендах Заказчика; – обеспечить тестирование разработанного функционала на стендах Заказчика силами Подрядчика; – решение о переносе измененного ППО на продуктивный стенд принимается Заказчиком по итогу результатов проведенного тестирования; – обеспечить техническое сопровождение процедуры тестирования ППО и переноса измененного ППО на продуктивный стенд Заказчика; – обеспечить экстренное внесение соответствующих изменений в случае выявления некорректной работы продуктивного стенда Заказчика после проведения обновления по итогам разработанного изменения в кратчайшие сроки; – актуализировать при необходимости комплект эксплуатационной документации: o руководство пользователя; o руководство администратора; o иные документы (при необходимости). Результат выполнения изменений должен быть отражен в Отчете по оказанию услуг. Типы и приоритеты изменений могут быть скорректированы в процессе оказания услуг исключительно по согласованию с Заказчиком - 4.4.7. Требования к программному обеспечению Общесистемное ПО, используемое в составе Модуля СЦ, должно быть зарегистрировано в Едином реестре российских программ для электронных вычислительных машин и баз данных и соответствовать рекомендованным показателям эффективности и соответствующим им значениям индикаторов эффективности перехода подведомственных организаций на использование российского ПО, заданных Приказом Минцифры России от 18.01.2023 № 21 «Об утверждении методических рекомендаций по переходу на использование российского программного обеспечения, в том числе на значимых объектах критической информационной инфраструктуры Российской Федерации, и о реализации мер, направленных на ускоренный переход органов государственной власти и организаций на использование российского программного обеспечения в Российской Федерации». Применяемое в системе программное обеспечение должно соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации, постановления Правительства Российской Федерации от 23 декабря 2024 г. № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц» - Прикладное программное обеспечение должно отвечать следующим требованиям: – совместимость программных продуктов в части используемых технических средств, системного программного обеспечения и общесистемной инфраструктуры в пределах требований к техническому обеспечению, а также их информационная совместимость в пределах требований к информационному обмену; – обеспечение трехуровневой архитектуры с разделением на уровень хранения данных (сервер БД), уровень бизнес-логики (сервер приложений) и уровень представления ( - 4.4.7.1. Требования к инструментам разработки и процессу контроля версий программного обеспечения 4.4.7.1.1. Система контроля версий Для управления исходным кодом должна использоваться система контроля версий кода, развернутая в инфраструктуре Заказчика. 4.4.7.1.2. Правила именования веток Имя ветки должно соответствовать следующему формату: / / Категории веток: ? feature/ — разработка новой функциональности, а также рефакторинг или удаление существующей; ? fix/ — исправление ошибок; ? hotfix/ — срочные исправления, применяемые в обход стандартного процесса разработки; ? test/ — для проведения экспериментов, не влияющих на основную разработку. Идентификатор задачи: после категории указывается ссылка на задачу (issue) в системе контроля версий кода. Описание: добавляется краткое описание решаемой задачи в формате kebab-case (слова разделяются дефисами, например, add-user-auth). Примеры именования веток: ? feature/#123/add-payment-integration; ? fix/#45/correct-calculation-logic; ? hotfix/#67/urgent-database-connection-patch. 4.4.7.1.3. Правила именования коммитов Сообщение коммита должно соответствовать соглашению Conventional Commits и состоять из категории и описания: : ? fix — исправление ошибки. Примеры сообщений коммитов: ? feat: добавление формы регистрации пользователя; ? fix: исправление ошибки валидации email-адреса; ? refactor: оптимизация алгоритма сортировки данных; ? chore: обновление версий в файле dependencies. 4.4.7.1.4. Модель ветвления В процессе разработки используются следующие основные ветви: ? main / master — стабильная ветка, содержит только код, прошедший полное тестирование и развернутый в продуктивных контурах; ? dev — ветка для интеграции завершенных задач, предназначенная для сборки и тестирования в тестовых средах. Попадание кода в main осуществляется только через Merge Request (MR) из dev - 4.5.5. Требования к информационной безопасности Работы по защите информации/информационной безопасности, не включенные в состав настоящего раздела, требуемые в соответствии с требованиями постановления Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации», а также нормативно правовых актов в области защиты персональных данных и обеспечения безопасности объектов критической информационной инфраструктуры, будут проведены в рамках исполнения отдельного контракта, заключенного по результатам отдельной закупочной процедуры (не является частью данного ТЗ), включающего: – определение актуальных угроз безопасности информации и актуализация модели угроз безопасности информации (при необходимости); – выполнение требований о согласовании технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России в установленном порядке; – выполнение требований по устранению Подрядчиком замечаний и недостатков, в случае их выявления при согласовании Заказчиком технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России; – выполнение требований к классу защищенности ГИС, уровню защищенности персональных данных и категории значимости объекта КИИ РФ, установленных для Головного центра обработки данных ФГБУ «СИЦ Минтранса России» (далее – ГЦОД); - – определение перечня объектов защиты информационной системы; – описание (актуализированных) требований к системе защиты информации, а также к мерам защиты информации информационной системы в зависимости от установленных классов защищенности, уровня защищенности персональных данных и категории значимости объектов КИИ РФ (приказы ФСТЭК России № 21, 117, 239); – выполнение требований к мерам по защите ГИС от атак, направленных на отказ в обслуживании, в соответствии с пунктами 30, 34, 59, 63 Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений, утвержденных приказом ФСТЭК России от 11.04.2025 № 117; – описание (актуализированных) требований по защите информации, подлежащих реализации в информационно телекоммуникационной инфраструктуре ГЦОД; – выполнение требований о применении сертифицированных средств защиты информации, включая их классы защиты и уровни доверия; – выполнение требований о запрете использования с 01.01.2025 органами (организациями) средств защиты информации странами происхождения, которых являются иностранные государства в соответствии с пунктом 6 Указа Президента Российской Федерации от 01.05.2022 № 250; – выполнение требований по обеспечению непрерывного взаимодействия с ГосСОПКА в установленном порядке; - 4.5.9.12. Передача Заказчику комплекта документов, материалов и сведений, предусмотренных нормативными правовыми актами Российской Федерации в сфере информационных технологий, защиты информации, правовой защиты интересов государства в области интеллектуальной собственности, включая документы, подтверждающие отказ авторов (разработчиков) от исключительных прав на передаваемые объекты интеллектуальной собственности в пользу Подрядчика, с проектами заявок на государственную регистрацию в установленном порядке прав Заказчика на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, базы данных, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, осуществляется Подрядчиком в составе отчетной документации, предусмотренной условиями Контракта. 4.5.9.13. По результатам выполнения работ по развитию системы должны быть подготовлены материалы для регистрации доработанной версии Системы (объекта учета) в НФАП в соответствии с требованиями постановления Правительства Российской Федерации от 30 января 2013?г. №?62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин» (с изменениями и дополнениями) в части обязательности размещения результатов работ в национальном фонде алгоритмов и программ для электронных вычислительных машин - 4.5.10. Требования по стандартизации и унификации К Модулю СЦ предъявляются следующие требования в части стандартизации и унификации: – работы по развитию Модуля СЦ должны производиться в соответствии с действующими стандартами и нормами Российской Федерации; – при создании и модернизации элементов Модуля СЦ следует руководствоваться действующими в Российской Федерации национальными стандартами и другими нормативно-техническими документами; – используемые оборудование и материалы, подлежащие обязательной сертификации, должны иметь соответствующие сертификаты; – ПО Модуля СЦ должно проектироваться и разрабатываться с учётом обеспечения требований унификации; – применяемые при создании Модуля СЦ технические (форматы данных, протоколы передачи и прочие) и организационные (регламенты, требования, инструкции) решения должны быть доступны и документированы в виде, достаточном для независимой (без обращения к Подрядчику) реализации третьими сторонами; – термины, обозначения и наименования, используемые в ПО, должны быть стандартизованы и унифицированы, выполнены на русском языке; – взаимодействие элементов и их внешнее поведение должно быть реализовано одинаково и производиться по единым правилам - 4.3.6.3.1. Требования к порядку оказания услуги по решению инцидентов, связанных с работой ППО При поступлении от Заказчика обращения (заявки), являющегося неисправностью в работе Модуля СЦ (инцидентом), Исполнитель реагирует на инцидент в СРО в срок не более 30 минут с момента поступления. В случае необходимости, для решения инцидента ответственный специалист должен связаться с инициатором обращения (заявки) для уточнения условий воспроизведения проблемы или для получения дополнительных сведений. После получения необходимых сведений от инициатора обращения (заявки) ответственный специалист производит диагностику с целью выявления причины инцидента и возможных путей устранения. В случае, если инцидент невозможно решить без получения дополнительных сведений от инициатора, и не удается связаться с инициатором в течение пяти рабочих дней, обращение (заявка) отклоняется в связи с недостатком данных для его решения, Заказчику направляется уведомление об отклонении обращения (заявки). Время, в течение которого невозможно связаться с инициатором, вычитается из общего времени обработки обращения (заявки). Все попытки связаться с инициатором должны фиксироваться с указанием даты и времени попытки, используемого способа связи (номер телефона, адрес электронной почты) и результата попытки (не удалось дозвониться, абонент недоступен, и т.д.) - Факт и время решения инцидента должны быть зафиксированы и отражены в СРО. В случае, если причиной сбоя в работе Модуля СЦ является выход из строя аппаратного обеспечения или неработоспособность смежной информационной системы, время работы над инцидентом приостанавливается до момента устранения неисправности. В ходе решения инцидентов могут быть выявлены дефекты ППО Модуля СЦ. В случае обнаружения дефектов ППО, Подрядчик информирует об этом Заказчика. Исполнитель может быть привлечен к проверке результата устранения дефекта по инициативе Заказчика. Приоритеты инцидентов приведены в Приложении Б к ТЗ. Детальный порядок оказания услуги по решению инцидентов, связанных с работой ППО Модуля СЦ определен в Регламенте оказания Услуг - 4.3.6.4. Требования к услугам адаптационного, конфигурационного и коррекционного сопровождения и доработки Модуля СЦ (в рамках действующих программных модулей и функциональностей) Услуги адаптационного, конфигурационного и коррекционного сопровождения и доработки Модуля СЦ включают: – управление изменениями и адаптация функций Модуля СЦ; – изменение настроек функционирования Модуля СЦ; – внесение изменений и/или модификаций Модуля СЦ (в рамках действующих программных модулей и функциональностей), направленных на улучшение их работоспособности и функциональных возможностей; – подготовка и передача Заказчику SQL запросов в СУБД для получения агрегированной информации из Модуля СЦ, которую невозможно получить с использованием графического пользовательского интерфейса; – адаптация модулей интеграций со смежными информационными системами - 4.3.6.4.2. Требования к изменению настроек функционирования Изменение настроек функционирования может проводиться в рамках допустимых пределов изменения функционирования, заложенных в архитектуру Модуля СЦ. Изменение настроек функционирования включает в себя изменение данных и справочников, изменение форм документов, формируемых Модулем СЦ, изменение и настройку форматов и версий передачи данных в смежные системы. Доработка программного кода Модуля СЦ может допускаться (в случае необходимости) при выполнении работ по адаптации функций Модуля СЦ в части изменения формата передачи данных в смежные информационные системы при условии соблюдения требований пункта 29.3 приказа ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации» - 4.3.6.5. Требования к услугам по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности По запросу Заказчика Подрядчик должен провести работу по приведению ППО в соответствие с требованиями по обеспечению информационной безопасности. Критичность уязвимости оценивается в соответствии в соответствии с Методическим документом ФСТЭК России «Методика оценки уровня критичности уязвимостей программных, программно-аппаратных средств» (утвержден ФСТЭК России 30.06.2025), а также с учетом ГОСТ 56545-2015 и международными стандартами (CVSS 3.0 и выше), и задает необходимый срок устранения. В процессе проведения Заказчиком обследования Модуля СЦ и выявления уязвимостей в ППО, связанных с исходным кодом Модуля СЦ и/или используемыми компонентами (библиотеками), Заказчик направляет Подрядчику обращение (заявку) на устранение, с указанием критичности и срочности принятия мер по устранению в СРО. - Подрядчик при оказании услуг по обновлению или устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности должен: – провести анализ уязвимостей и связанных с ними исходным кодом и/или используемыми компонентами (библиотеками); – выработать варианты устранения указанных уязвимостей и согласовать с Заказчиком их реализацию; – своевременно внести изменения в исходный код Модуля СЦ и/или используемые компоненты (библиотеки) и подготовить соответствующее обновление; – провести обновление Модуля СЦ в тестовом контуре Заказчика и проинформировать Заказчика о готовности проведения тестирования; – протестировать успешность обновления или устранения уязвимостей в ППО и корректность функционирования Модуля СЦ на тестовом контуре, совместно с Заказчиком; – при невозможности незамедлительного устранения уязвимости приоритетов «Критический» и «Высокий» Подрядчик обязан предоставить исчерпывающий список причин и согласовать план достаточных компенсирующих мер с ответственными сотрудниками Заказчика. Результат внесения изменений отображается в соответствующей записи в СРО и в составе Отчета об оказанных услугах - 4.3.6.5.1. Требования к порядку оказания услуг по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности Подрядчик в соответствии с приоритетами обращений и контрольными сроками исполнения (см. Приложение Б к ТЗ) оценивает техническую возможность и сроки устранения уязвимостей, и реализацию обновления Модуля СЦ. По итогу проведения оценки Подрядчик направляет в заявке СРО Заказчику заключение о возможности устранения уязвимостей и/или обновления в ППО и согласует с Заказчиком проведение данных работ - 4.4.7.1.5. Требования к используемым зависимостям (библиотекам) Все внешние зависимости проекта должны быть зафиксированы с указанием точных версий. Для контроля версий зависимостей в репозиторий обязательно должны быть включены следующие файлы: · Для JavaScript: package-lock.json или yarn.lock; · Для Python: requirements.txt (с зафиксированными версиями) или Pipfile.lock; · Для Go: go.mod и go.sum; Загрузка всех зависимостей должна производиться исключительно через внутренний прокси-репозиторий Заказчика, настроенный в соответствующем системе менеджере пакетов. Запрещается: · Использование плавающих версий (например, ^1.2.3, ~4.5.0, latest); · Использование библиотек, содержащих критические уязвимости, в том числе зарегистрированные в реестре CVE (Common Vulnerabilities and Exposures). 4.4.7.1.6. Требования к процессу непрерывной интеграции (CI) Сборка программного обеспечения, включая этапы компиляции, тестирования и анализа кода, должна выполняться исключительно в инфраструктуре непрерывной интеграции Заказчика. 4.4.7.1.7. Требования к хранению артефактов сборки Все артефакты сборки (результирующие пакеты, Docker-образы и т.д.) подлежат обязательному хранению в предназначенной для этого инфраструктуре Заказчика (артефакторий). Запрещается размещение финальных артефактов сборки на сторонних ресурсах - 4.4.8. Требования к техническому обеспечению Количество серверов, подключаемых и настраиваемых сервисов, их параметров, схемы соединений и настройки межсетевого взаимодействия должны быть согласованы с Заказчиком на этапе № 1 Техническое проектирование. Доступ к комплексу технических средств предоставляется Заказчиком по письменному запросу Подрядчика. Применяемые в Системе программно-аппаратные и аппаратные комплексы должны соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации», требованиям Постановления Правительства Российской Федерации от 23 декабря 2024 г. № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц». Модуль СЦ, работающий в составе АСУ ТК, развернут на вычислительных мощностях ГЦОД СИЦ Минтранса России - 4.5. Общие технические требования 4.5.1. Требования к численности и квалификации персонала и пользователей Модуля СЦ Программное обеспечение Модуля СЦ не должно требовать изменения штатной численности персонала Заказчика. Программное обеспечение Модуля СЦ не должно требовать наличия у пользователей дополнительной квалификации в сфере информационных технологий, кроме базовых знаний в обращении с персональным компьютером, базовых навыков работы в интернет-обозревателях и знаний о Модуле СЦ в объеме документов Руководство пользователя, Руководство администратора - – выполнение требований по обеспечению в автоматизированном режиме с Национальной системой противодействия DDoS-атакам (НСПА) Центра мониторинга и управления сетью связи общего пользования ФГУП «ГРЧЦ» в рамках реализации мер по защите ГИС от атак, направленных на отказ в обслуживании; – детализированные требования к составу и содержанию работ по аттестации, а также к их результатам в соответствии с пунктами 13, 15 и 16 требований приказа ФСТЭК России от 29.04.2021 № 77 «Об утверждении Порядка организации и проведения работ по аттестации объектов информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну» - 4.5.5.1. Требования к безопасности исходного кода Процесс разработки исходного кода должен соответствовать требованиям законодательства, нормативным правовым актам Российской Федерации, приказу ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по безопасности значимых объектов критической информационной инфраструктуры Российской Федерации», а также учитывать отраслевые практики безопасной разработки. Подрядчик должен предоставить Заказчику Руководство по безопасной разработке программного обеспечения (далее – Руководство), применяемое при разработке исходного кода Модуля СЦ. Руководство должно содержать: · описание процесса безопасной разработки и ролевой модели, отражающей зоны ответственности сотрудников Подрядчика; · описание процессов моделирования, оценки и формирования мер предотвращения угроз, применяемых Подрядчиком; · описание методик, применяемых Подрядчиком при разработке исходного кода (правила написания кода); · описание методик, периодичности проведения и инструментария статического, динамического, композитного и фаззинг тестирования исходного кода, включающего критерии отбора релизных версий ПО, применяемые Подрядчиком в процессе разработки; · описание механизмов безопасности в процессе сборки и доставки (безопасность образов, безопасность секретов, безопасность окружения и сборочной среды), применяемые Подрядчиком; · утвержденные шаблоны отчетной документации (в том числе акты), в соответствии с которыми Заказчик принимает результаты проверок (артефакты сборочного процесса), проведенных Подрядчиком; · описание процедур отслеживания и исправления обнаруженных ошибок и уязвимостей программного обеспечения; · описание способов и сроков доведения Подрядчиком до Заказчика информации об уязвимостях программного обеспечения, о компенсирующих мерах по защите информации или ограничениях по применению программного обеспечения, способов получения пользователями программного обеспечения его обновлений, проверки их целостности и подлинности - Подрядчик должен обеспечить реализацию и проведение внутренних проверок мер по разработке безопасного ПО, приведенных в Руководстве. Подрядчик должен провести анализ угроз безопасности информации программного обеспечения в соответствии с ГОСТ 58412-2019 «Защита информации. Разработка безопасного программного обеспечения. Угрозы безопасности информации при разработке программного обеспечения». Подрядчик должен провести испытания по выявлению уязвимостей в программном обеспечении Системы: · проведение статического анализа исходного кода программы; · проведение динамического анализа исходного кода программы; · проведение композитного анализа исходного кода и образов программы; · проведение фаззинг-тестирования программы, направленного на выявление в ней уязвимостей. Испытания по выявлению уязвимостей в программном обеспечении Системы должны быть проведены в рамках: · предварительных испытаний; · опытной эксплуатации; · приемочных испытаний - 4.5.11. Требования к показателям назначения 4.5.11.1. Требования к показателям назначения мероприятий по развитию Модуля СЦ В рамках выполнения работ по развитию Модуля СЦ, предусмотренных ТЗ, показатель назначения «Количество пользователей» должен соответствовать значениям, приведенным в данном разделе. Пояснения по показателям, связанным с количеством пользователей, приведены в Таблице 8. Таблица 8. Определения показателей, связанных с количеством пользователей в Модуле СЦ № Показатель Определение Расчетное количество пользователей Количество пользователей, работу которых должен обеспечить Модуль СЦ к моменту сдачи работ по Контракту с учетом достижения всех показателей назначения Расчетное количество одновременно работающих пользователей Количество одновременно работающих пользователей, работу которых должен обеспечивать Модуль СЦ к моменту сдачи работ по Контракту с учетом достижения всех показателей назначения Значения показателей количества пользователей, достижение которых необходимо обеспечить, представлено в Таблице 9 - Таблица 9. Значения показателей количества пользователей № Показатель Значение 1. Расчетное количество пользователей 1 000 2. Расчетное среднее количество одновременно работающих пользователей 200 Развитие Модуля СЦ должно быть направлено на достижение следующего эффекта (показателя), подставленного в мероприятии 103.002 «Информационно-аналитическая система регулирования на транспорте (АСУ ТК)» ВПЦТ Минтранса России: Выполнение работ по развитию Модуля СЦ предусмотрено мероприятием по развитию АСУ ТК, приведенном в ВПЦТ Минтранса России на 2026-2028 гг: № 103.002 «АСУ ТК» в составе ИТ расхода 103.26.000005 «Развитие предусматривает реализацию ОКР и эффектов, приведенных в Таблице 10. Таблица 10. ОКР и эффекты, приведенные в ВПЦТ Минтранса России на 2026 г. № ОКР Дата ОКР Эффекты 1 Обеспечено информационное взаимодействие с Минобороны России о происшествиях на транспортных объектах 25.12.2026 Сокращено время сбора и передачи сведений для Минобороны России о ЧС и НС на транспорте с 120 до 10 минут 2 Обеспечена автоматизация формирования отчетов о нештатных ситуациях на транспорте, в том числе по данным внешних систем 25.12.2026 Сокращено время на подготовку отчетов о нештатных ситуациях на транспорте с 20 до 5 минут Реализация остальных ОКР не является предметом данного ТЗ и проводится в рамках отдельного технического задания. - 4.5.11.2. Требования к показателям назначения мероприятий по эксплуатации Модуля СЦ. Работы по эксплуатации Модуля СЦ не должны обеспечивать режимы функционирования Модуля СЦ, приведенные в разделе 4.5.2 данного ТЗ - При проведении работ по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности необходимо выполнить следующее: – Заказчику сформировать заявку на устранение (обновление) в СРО с полным списком обнаруженных уязвимостей и планируемыми работами; – согласовать в рабочем порядке время начала и завершения работ, перечень работ, выполняемых в рамках обновления или устранения уязвимостей в ППО с Заказчиком; – оповестить Заказчика о начале проведения работ на тестовом контуре; – провести работы по обновлению или устранению уязвимостей в ППО на тестовом контуре Модуля СЦ в установленные сроки; – протестировать выполнение работ в тестовом контуре и проинформировать Заказчика о готовности переноса ППО на продуктивный контур; – силами Заказчика обновить продуктивный контур Модуля СЦ, в соответствии с планом устранения и выполненными работами; – совместно с Заказчиком проверить корректность функционирования Модуля СЦ и устранения уязвимостей в продуктивном контуре Модуля СЦ по результатам обновления; – при необходимости актуализировать документацию (описание архитектуры, анкеты постановки на мониторинг и иные документы). Любые изменения в части обновления или устранения уязвимостей в ППО на промышленном контуре Модуля СЦ должны применяться только в случае успешного проведения аналогичных работ на тестовом контуре. Детальный порядок оказания услуги по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности определен в Регламенте оказания Услуг - 4.4. Требования к видам обеспечения 4.4.1. Требования к лингвистическому обеспечению Документация на Модуль СЦ должна разрабатываться на русском языке. Взаимодействие пользователей с Модулем СЦ посредством графического интерфейса должно происходить на русском языке за исключением сообщений, зависящих от настроек системного программного обеспечения, установленного на рабочих местах пользователей. При разработке программных решений Модуля СЦ должно быть предусмотрено использование языков программирования высокого уровня, приведенных в Таблице 7. Таблица 7. Языки и средства разработки, специального программного обеспечения Модуля СЦ Категория Наименование Назначение Языки программирования Kotlin Разработка серверной логики и сервисов (backend) JavaScript / TypeScript Разработка клиентской части (frontend) Python Разработка скриптов интеграции, обработки данных и автоматизации Фреймворки и библиотеки Vue.JS Разработка пользовательских интерфейсов (веб-интерфейсы компонентов визуализации и отчетности) React Разработка пользовательских интерфейсов (при необходимости создания сложных интерактивных компонентов) Решения по лингвистическому обеспечению, включая перечень используемых языков программирования, должны быть согласованы с Заказчиком на этапе технического проектирования - 4.4.2. Требования к математическому обеспечению Требования к математическому обеспечению не предъявляются. 4.4.3. Требования к метрологическому обеспечению Требования к метрологическому обеспечению не предъявляются. 4.4.4. Требования к организационному обеспечению Требования к организационному обеспечению не предъявляются. 4.4.5. Требования к методическому обеспечению Задачи методического обеспечения Модуля СЦ должны быть обеспечены за счет использования технологических и методических документов касающихся вопросов функционирования транспортного комплекса и разработки и эксплуатации ПО. 4.4.6. Требования к информационному обеспечению Состав, структура и способы организации информационного обеспечения в Модуле СЦ должны быть определены на этапе технического проектирования. Факты информационного обмена с внешними системами должны фиксироваться в соответствующем журнале - 4.5.2. Требования к режимам функционирования Модуля СЦ Модуль СЦ должен предусматривать наличие следующих режимов работы: – штатный; – регламентный (профилактический); – аварийный. Основным режимом функционирования является штатный. В штатном режиме все компоненты корректно и полностью выполняют свои функции. Перерывов в работе как Модуля СЦ в целом, так и одного, либо нескольких компонентов не предусмотрено. Режим регламентного (профилактического) обслуживания предназначен для проведения работ по обновлению и техническому обслуживанию компонентов Модуля СЦ, а также резервному копированию данных. При работе в данном режиме допускаются перерывы в работе Модуля СЦ с предварительным информированием пользователей. Состав процедур по регламентному обслуживанию Модуля СЦ и их периодичность определяются Подрядчиком в процессе выполнения работ по созданию Модуля СЦ. В режиме регламентного (профилактического) обслуживания Модуль СЦ может функционировать с частичным ограничением своих функциональных возможностей, либо без ограничения, но со снижением показателей надежности и производительности. Перевод в данный режим работы должен осуществляться сразу после начала выполнения любой операции, отнесенной к этому режиму, с последующим возвратом в штатный режим функционирования сразу после ее завершения. Перевод в указанный режим должен осуществляться при возникновении необходимости проведения работ по обновлению и техническому обслуживанию компонентов Модуля СЦ, а также резервному копированию данных с условием предварительного оповещения пользователей. Аварийный режим функционирования характеризуется отказом одной или нескольких подсистем, вызванных выходом из строя аппаратного и/или программного обеспечения, а также в случае временной неработоспособности каналов связи между серверами. - В аварийном режиме осуществляется поиск неисправностей и проведение работ по их устранению. Перевод в аварийный режим должен осуществляться при возникновении сбоев, аварий и прочих незапланированных воздействий, сразу после наступления одной или нескольких аварийных ситуаций, с последующим возвратом в штатный режим функционирования сразу после окончания восстановительных работ. ПО Модуля СЦ должно обладать надежностью, обеспечивающей работу пользователей в произвольном режиме и оперативное восстановление работоспособности при сбоях. В целях обеспечения надежного функционирования ПО должно предусматривать: – сохранение целостности данных при нештатном завершении работы компонентов Модуля СЦ; – сохранение работоспособности программного обеспечения при некорректных действиях пользователя; – резервное копирование базы данных Модуля СЦ. – время восстановления работоспособности Модуля СЦ после отказа не более 4 часов. – отказоустойчивость на уровне 99% при единовременной количестве не менее 200 пользовательских сессий в Модуле СЦ. Указанные характеристики приведены без учета характеристик надежности инфраструктуры и времени передачи информации по каналам связи. При возникновении сбоев в аппаратном обеспечении, включая аварийное отключение электропитания, Модуль СЦ должен автоматически восстанавливать свою работоспособность (не требовать перенастройки) после устранения сбоев и корректного перезапуска аппаратного обеспечения - По результатам анализа угроз безопасности информации программного обеспечения и испытаний по выявлению уязвимостей в программном обеспечении Системы должна быть предоставлена отчетная документация по формам, утвержденным в Руководстве, и артефакты сборочной среды, подтверждающие проведение испытаний по выявлению уязвимостей в программном обеспечении Систем. Уязвимости подлежат устранению в сроки, обозначенные Заказчиком. В случае обнаружения уязвимого компонента Подрядчик должен заменить/обновить библиотеки. В случае, если уязвимость не подлежит исправлению на программном уровне, Подрядчик должен разработать меры предотвращения угроз безопасности, в том числе правила безопасности для наложенных средств защиты, рекомендации по безопасной настройке конфигурации для устранения потенциальных уязвимостей и снижения рисков информационной безопасности. Уязвимости, найденные ФСБ России, ФСТЭК России, Минцифры России, Роскомнадзором в ходе исполнения Контракта, а также в течение гарантийного периода, должны быть устранены Подрядчиком за свой счет в сроки, согласованные с Заказчиком - 4.5.6. Требования к эргономике и технической эстетике Взаимодействие пользователей с Модулем СЦ должно осуществляться посредством визуального графического интерфейса. Ввод-вывод данных, прием управляющих команд и отображение результатов их исполнения должны выполняться в интерактивном режиме. Интерфейс должен быть рассчитан на преимущественное использование манипулятора типа «мышь», то есть управление Модулем СЦ должно осуществляться с помощью набора экранных меню, кнопок, значков и т. п. элементов. Клавиатурный режим ввода должен использоваться главным образом при заполнении и/или редактировании текстовых и числовых полей экранных форм. Все надписи экранных форм, а также сообщения, выдаваемые пользователю (кроме системных сообщений), должны быть на русском языке. Модуль СЦ должен обеспечивать проверку вводимых пользователем данных и предупреждать о некорректно введённых значениях - Экранные формы должны проектироваться с учетом требований унификации: – все экранные формы пользовательского интерфейса должны быть выполнены в едином графическом дизайне, с одинаковым расположением основных элементов управления и навигации; – для обозначения сходных операций должны использоваться сходные графические элементы, кнопки и другие управляющие (навигационные) элементы. Термины, используемые для обозначения типовых операций, а также последовательности действий пользователя при их выполнении должны быть унифицированы; – внешнее поведение сходных элементов интерфейса (реакция на наведение указателя «мыши», переключение фокуса, нажатие кнопки) должно реализовываться одинаково. Структура размещения информации и представление этой структуры в Модуле СЦ должны соответствовать следующим требованиям: – пункты меню в пользовательском веб-интерфейсе должны быть сгруппированы в соответствии с тематикой информации, функциональными задачами и технологией работы; – каждому пункту меню должна соответствовать только одна выполняемая функция; – при совершении пользователями ошибочных действий должны выдаваться сообщения об ошибках. Эскизы визуального оформления компонента «Интерактивная карта» представлены в Приложении А. - Технические меры по обеспечению надежности должны предусматривать: – резервирование критически важных компонентов и данных Системы и отсутствие единой точки отказа; – использование программного резервирования (программной избыточности); – изменение конфигурации используемых средств и применение специализированного ПО, обеспечивающего высокую надёжность. Организационные меры по обеспечению надежности должны быть направлены на минимизацию ошибок пользователей (а также обслуживающего персонала при эксплуатации и проведении работ по обслуживанию), минимизацию времени ремонта или замены вышедших из строя компонентов за счёт: – обеспечения для обслуживающего персонала требуемого уровня квалификации; – регламентации и нормативного обеспечения выполнения работ обслуживающим персоналом; – своевременной диагностики неисправностей. Расчетное значение коэффициента доступности Модуля СЦ должно составлять не менее 0,95. - 4.5.3. Требования по диагностированию Модуля СЦ Диагностирование Модуля СЦ должно осуществляться путем анализа записей в системных журналах СУБД, операционных систем серверов, а также с помощью встроенных средств диагностирования общего программного обеспечения Модуля СЦ. Диагностированию подлежат: – сбои и нарушения функционирования технического обеспечения (серверов) Модуля СЦ; – сбои и нарушения функционирования системного программного обеспечения серверов, используемых для работы Модуля СЦ; – сбои и нарушения функционирования прикладного программного обеспечения серверов, используемых для работы Модуля СЦ; – случаи недоступности (отсутствия ответа) или некорректные ответы внешних систем; – сбои и нарушения функционирования СУБД; – сбои при выполнении регламентных операций резервного копирования. При возникновении аварийных ситуаций либо ошибок в программном обеспечении диагностические инструменты должны позволять сохранять набор информации, необходимой для идентификации и устранения проблемы. Модуль СЦ и ее компоненты должны обеспечивать возможность диагностики своей работоспособности с возможностью интеграции с модулем мониторинга АСУ ТК. Набор передаваемых журналов и метрик должен быть определен на этапе технического проектирования - 4.5.4. Требования к надежности Должно быть предусмотрено сохранение работоспособности Модуля СЦ при некорректных действиях пользователя и сохранение целостности данных при нештатном завершении работы Модуля СЦ (отказ рабочей станции, потеря сетевого доступа и т.п.). Модуль СЦ должен предоставлять механизмы обеспечения сохранности данных через применение процедур резервного копирования и восстановления, описанных в документации на Систему. Ключевые показатели надежности информационной системы — допустимое время на восстановление работоспособности Модуля СЦ (RTO - recovery time objective) и/или допустимый интервал времени потери изменений в данных при сбоях/отказах (RPO – recovery point objective) должны быть определены Подрядчиком и согласованы с Заказчиком на этапе технического проектирования - 4.5.7. Требования по сохранности информации при авариях В случае возникновения аварии или сбоя в процессе выполнения пользовательских задач должно быть обеспечено восстановление баз данных до состояния на момент последней завершенной Модулем СЦ транзакции, и структуры файлового хранилища. Все аварийные ситуации должны обрабатываться программно с выдачей соответствующих сообщений, с корректной обработкой ситуации (завершение транзакций, закрытие файлов и т.п.), без потери обрабатываемой информации. В Модуле СЦ должны быть предусмотрены меры, обеспечивающие целостность данных в случае отказа программного обеспечения или аппаратных средств, исключая случаи физического уничтожения носителя или нарушения функциональности носителя, операционной системы или СУБД по вине их производителя либо обслуживающего персонала. Используемые аппаратные и системные платформы должны обеспечивать сохранность и целостность информации в Модуле СЦ при полном или частичном отключении электропитания, аварии сетей телекоммуникации, полном или частичном отказе технических средств Модуля СЦ. Технические решения должны обеспечивать сохранность информации в случае возникновения следующих событий (аварий, отказов и т.п.): – отказ аппаратного обеспечения на сервере; – отключение питания на сервере; – отказ аппаратного обеспечения на рабочей станции; – отключение питания на рабочей станции администратора; – отказ линий связи, в том числе при осуществлении обмена данными - 4.5.8. Требования к защите от влияния внешних воздействий Требования к защите от влияния внешних воздействий не предъявляются - 4.5.9. Требования к патентной чистоте и патентоспособности 4.5.9.1. Исключительные права на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, базы данных, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, принадлежат Российской Федерации в лице Заказчика. Право собственности на результаты работ, отчетные документы и материалы, полученные в ходе выполнения работ по Контракту, принадлежат Российской Федерации в лице Заказчика и считаются переданными с момента подписания Сторонами Акта сдачи-приемки выполненных работ. Разработанное программное обеспечение поставляется вместе с исходными кодами. 4.5.9.2. Все проектные и технические решения должны отвечать требованиям четвертой части Гражданского кодекса Российской Федерации. Результаты Работ должны быть свободными от возможности предъявления любых прав и притязаний третьих лиц, основанных на промышленной, интеллектуальной или другой собственности. 4.5.9.3 Результаты выполненных Работ не должны повлечь необходимость осуществления Заказчиком закупок программного обеспечения (как исключительных, так и неисключительных прав) для обеспечения функциональности Системы в соответствии с Техническим заданием. При выполнении работ Подрядчик должен использовать только объекты интеллектуальной собственности, права на которые приобретены (получены) и используются без нарушений прав на интеллектуальную собственность третьих лиц или предоставлены Заказчиком - 4.5.9.4. Подрядчик подтверждает, что обладает всеми правами на передачу Заказчику исключительных прав в соответствии с требованиями настоящего раздела Технического задания. В случае, если к Заказчику по вине Подрядчика будут предъявлены претензии в этой части, иски третьих лиц, связанные с нарушением их прав, Подрядчик принимает на себя такие претензии и иски и возмещает Заказчику все расходы и весь ущерб, понесенный в связи с ними. 4.5.9.5. Подрядчик обязан согласовать с Заказчиком необходимость использования при выполнении работ охраняемых результатов интеллектуальной деятельности, права на которые принадлежат Подрядчику или третьим лицам. 4.5.9.6. В случае, если при выполнении Работ используется готовое программное обеспечение (платформа, подсистема, СУБД и т.д.), которое становится частью (компонентом) Системы, Заказчику передаются полные исключительные права, или неисключительные права (путем заключения лицензионного/сублицензионного договора/соглашения) на такое программное обеспечение со следующими возможностями: – права передаются бессрочно (на весь срок действия исключительных прав); – территория действия Российская Федерация; – должно быть обеспечено право Российской Федерации (в лице Заказчика) передавать, дорабатывать, распространять, развивать результаты работ, созданные в процессе исполнения Контракта, а также перерабатывать такое программное обеспечение. Лицензионное (сублицензионное) соглашение (договор), Акт передачи прав, подписанные Подрядчиком, согласие правообладателя, оформленное в соответствии с положениями Гражданского кодекса Российской Федерации (в случае, если Подрядчик не является правообладателем такого программного обеспечения), инструкция по инсталляции, руководство администратора, руководство пользователя передаются Заказчику в сроки, установленные Техническим заданием для соответствующего функционала Системы - Лицензионное (сублицензионное) соглашение (договор) не может возлагать на Заказчика какие-либо обязанности (в т.ч. в части конфиденциальности, предоставления отчетности), не предусмотренные Контрактом. 4.5.9.7. Передача Заказчику исключительных прав, или простых (неисключительных) прав не может повлечь увеличение стоимости Контракта и/или изменение иных существенных условий Контракта. 4.5.9.8. Функциональность Модуля СЦ передается в объеме и в сроки, установленные Техническим заданием. 4.5.9.9. Нарушение условий настоящего раздела Технического задания, в т.ч. отсутствие соответствующего лицензионного (сублицензионного) соглашения (или договора), либо предоставление лицензионного (сублицензионного) соглашения (или договора), не соответствующего требованиям действующего законодательства Российской Федерации или требованиям Контракта, является нарушением существенных условий Контракта. 4.5.9.10. В случае, если в соответствии с пунктом 4.5.9.6 Заказчику передается исключительное право, такая передача осуществляется в порядке, установленном Гражданским кодексом Российской Федерации. 4.5.9.11. В случае, если при выполнении Работ положения пунктов 4.5.9.5-4.5.9.6 не применялись, Подрядчик в составе отчетной документации предоставляет об этом декларацию в свободной форме. Декларация должна содержать сведения о полном соответствии результата Работ требованиям Контракта, а также о неприменении при выполнении работ готового программного обеспечения (платформ, подсистем, СУБД и т.д.), которое стало частью (компонентом) Системы - 4.1. Требования к структуре Модуля СЦ В процессе работ по развитию Системы должны сохраниться основные требования к построению архитектуры Системы в соответствии с принципами трехуровневой архитектуры: 1. уровень хранения данных или уровень базы данных (сервер СУБД); 2. уровень сервера приложений (сервер аналитической обработки); 3. презентационный уровень, обеспечивающий взаимодействие с клиентскими приложениями. В состав Системы должны входить следующие основные компоненты: 4. сервер баз данных; 5. сервер приложений; 6. веб-сервер. Сервер баз данных должен обеспечивать хранение и целостность хранимых данных, создание резервных копий, ведение журнала транзакций, восстановление данных после сбоев. Сервер приложений должен обеспечивать обработку запросов, поступающих от клиентских приложений (через веб-сервер), формирование ответов на запрос в доступном пользователю виде (формирование пользовательских интерфейсов). Веб-сервер должен обеспечивать взаимодействие с оператором и внешними системами по HTTP / HTTPS протоколу в режиме «запрос-ответ» (получения запросов от пользователя и передачи ответа в виде соответствующей информации, обработанной серверами приложений). Взаимодействие Системы с пользователем должно отвечать требованиям модели «тонкого клиента» (т.е. представлять на стороне клиента (пользователя) лишь графический пользовательский интерфейс). Все составляющие Системы должны использовать единую методологию и отвечать единым принципам взаимодействия, надежности и управления. Перечень компонентов Модуля СЦ представлен в Таблице 4. Таблица 4. Перечень компонентов Модуля СЦ, в отношении которых выполняются работы по развитию № п.п. Наименование компонента Модуля СЦ Раздел ТЗ 1 Компонент регистрации событий 4.2.1. 2 Компонент отчетности 4.2.2 3 Компонент визуализации 4.2.3 4 «Интерактивная карта» (компонент создается) 4.2.4 5 Компонент администрирования 4.2.5 - 4.2. Требования к дорабатываемым функциям модуля СЦ 4.2.1. Развитие компонента регистрации событий (1 очередь) Должны быть выполнены следующие доработки: – обеспечение логирования действий пользователя, связанных с карточкой события; – доработка объектной модели в части создания новых типов сущностей (карточек) с учетом реализуемых интеграций с информационными ресурсами (силы и средства предупреждения и ликвидации ЧС и нештатных ситуаций на транспорте, ТС, ограничения воздушного пространства, неблагоприятные и опасные природные явления); – реализация механизма установления связи между сущностями в Модуле СЦ автоматизированным и ручным способами (события, природные явления, силы и средства предупреждения и ликвидации ЧС и нештатных ситуаций на транспорте, ограничения воздушного пространства, ОТИ, ТС и др.); – отображение в карточке установленных связей между сущностями. - 4.2.2. Развитие компонента отчетности (3 очередь) Должна быть обеспечена автоматизация процессов формирования отчетов о ЧС и нештатных ситуациях на транспорте, в т.ч. на основе данных из внешних систем. Включает следующие доработки: – разработка шаблонов отчетов в различных форматах (табличный, текстовый); – реализация выбора фотоматериалов для включения в справку; – форматирование содержимого справок с учетом правил русского языка в отношении окончаний слов (в зависимости от падежа, склонения, числа и рода); – автоматизированное формирование выводов к содержимому справки на основе настраиваемых критериев; – создание интерфейса выбора параметров (фильтрации) для формирования отчетов: o состав полей для включения в отчёт; o настройка диапазонов значений характеристик и дат; o порядок отображения полей; o настройка заголовка. – реализация способа подготовки отчётов в асинхронном режиме (очереди); – реализация интерфейса компонента формирования отчетности для отображения очереди формирования отчетов и статусов их подготовки; – экспорт отчётов в форматы xlsx, csv и справок в форматы pdf, docx. Необходимо разработать не менее 10 шаблонов отчетов и/или справок. Перечень, структура и содержание шаблонов должны быть согласованы с Заказчиком на этапе технического проектирования. - 4.2.3. Развитие компонента визуализации (2 очередь) В рамках развития компонента визуализации должны быть выполнены следующие доработки, обеспечивающие: – вывод перечней (списков) сил и средств предупреждения и ликвидации ЧС и нештатных ситуаций на транспорте с отображением мест их постоянного размещения (дислокации) на карте, включая: o отображение зон ответственности на карте; o возможность их фильтрации (по видам транспорта, регионам и пр.); o реализацию инструмента расчета расстояния (с использованием сети автомобильных и железных дорог) между местом события и местами дислокации сил и средств, а также вывода маршрутов на карте; – отображение зон (полигонов) с установленными ограничениями движения в воздушном пространстве на карте; – отображение термических точек; – реализация возможности отображения данных из паспорта региона, отображаемого в модуле iМинтранс (модуль АСУ ТК); – отображение краткой карточки сущностей и ОТИ (краткой информации и/или динамических характеристик объекта) при выборе объекта на карте с возможностью перехода в полную карточку сущности и ОТИ; – отображение данных от Росгидромета, предусматривающих: o отображение неблагоприятных и опасных природных явлений на карте (с заданным периодом обновления данных); o управление отображением явлений на карте, включая настройку состава отображаемых объектов, поиск, фильтрацию, с использованием соответствующей панели управления; o выведение краткой карточки явления при выборе объекта, с возможностью перехода в полную карточку объекта - – отображение на карте связанных сущностей и ОТИ; – реализация функции выбора темного и светлого стилей отображения элементов интерфейса, карточек сущностей, картографической основы и объектов, отображаемых на карте; – реализация механизма для выбора картографической основы в одном из распространенных форматов WMTS, TMS, MVT и др. Должна быть предусмотрена возможность настройки перечня картографических основ и параметров доступа к ним; – настройка базового набора дашбордов, содержащих преднастроенные виджеты о количестве событий в разрезе видов транспорта с возможностью перехода к исходным данным (карточкам событий, ОТИ и т.д.), с фильтрацией по параметрам. Параметры фильтрации должны быть определены на этапе технического проектирования. Должно быть обеспечено автоматическое и принудительное обновление данных, отображаемых на дашбордах - 4.2.4. Создание компонента «Интерактивная карта» (2 очередь) В составе создаваемого компонента должны отображаться данные, доступные в компоненте визуализации. Требования к интерфейсу интерактивной карты: – интерактивная карта должна быть представлена в виде объемной карты с учетом макетов, представленных в Приложении А к ТЗ; – интерфейс должен корректно отображаться на экранах мониторов (разрешение Full HD 1920?1080), телевизоров (разрешение 4К 3840?2160), жидкокристаллических панелей для видеостены, используемой Заказчиком, с параметрами каждой панели: диагональ 55 дюймов, разрешение 1920x1080; – интерфейс должен корректно отображаться на планшетных устройствах с диагональю экрана 10-12 дюймов, конкретные требования должны быть уточнены на этапе технического проектирования; – должна быть обеспечена кластеризация и генерализация отображения объектов на карте при изменении масштаба; – должно быть обеспечено отображение основных характеристик объектов при выборе их на карте; – должно быть обеспечено управление отображением слоев на карте; – должна быть обеспечена настройка цветовой индикации отображаемых объектов транспортной инфраструктуры; – должно быть обеспечено отображение легенды карты, содержащей отображаемые объекты на карте; – должна быть обеспечена возможность одновременного отображения не менее 5 000 ОТИ и ТС на карте. - На интерактивной карте должны быть отображены подвижные объекты совместно с объектами транспортной инфраструктуры (ОТИ), включая следующие возможности: § отображение местоположения транспортных средств (воздушный, водный и автомобильный транспорт) на карте в режиме реального времени (с заданным периодом обновления данных); § отображение маршрутов движения всех ТС за выбранный период времени, в том числе с использованием эффектов анимации; § отображение маршрутов движения ТС, связанных с карточкой события: ТС, являющихся участниками события, и ТС, находящиеся в заданном радиусе от события; § управление отображением сущностей и ОТИ на карте, включая настройку состава отображаемых объектов, поиск, фильтрацию, с использованием соответствующей панели управления и наглядным представлением результатов; § автоматическое изменение вида отображения объектов (цветовая индикация) по заданным условиям (например, при достижении критических значений параметров, характеризующих функционирование объекта); Должна обеспечиваться производительность обновления изображения на экране в 30 кадров в секунду на тестовой конфигурации пользовательского устройства (модель Бештау AIO2402/B560, входящая в Реестр российской промышленной продукции под номером 10394100 или аналог) при одновременном отображении не менее 5 000 объектов и 200 уникальных моделей объектов. Макеты интерфейсов Модуля СЦ должны быть предварительно согласованы с Заказчиком и разработаны с учетом требований ГОСТ Р ИСО 9241-161-2016 «Элементы графического пользовательского интерфейса» - 4.2.4.1. Требования к технической реализации компонента «Интерактивная карта» При реализации компонента «Интерактивная карта» должны учитываться требования, указанные ниже. 4.2.4.1.1. Требования к отображению элементов Повторяющихся элементы карты (ТС, ОТИ, события и пр.) должны отрисовываться с использованием аппаратного создания экземпляров объектов на пользовательском устройстве (WebGL/WebGPU)). Отрисовка каждого объекта отдельным запросом не допускается, должна обеспечиваться возможность одновременного отображения не менее 5 000 объектов без снижения производительности (30 кадров в секунду на тестовой конфигурации). 4.2.4.1.2. Уровни детализации объектов Для управления отображением сложных объектов должно быть создано не менее 3-х уровней детализации, отображаемых при изменении масштаба с возможностью автоматического переключения между уровнями. Все отображаемые объекты должны масштабироваться с учетом разрешения экрана пользователя с сохранением качества детализации. 4.2.4.1.3. Полигональная оптимизация и текстурирование При реализации компонента «Интерактивная карта» должна обеспечиваться технология рельефного тестурирования объектов. Не должны использоваться высокополигональные трехмерные модели. Все повторяющиеся элементы должны генерироваться единоразово и повторно использоваться при последующих отображениях. 4.2.4.1.4. Управление памятью Требуется реализовать потоковую загрузку на устройство пользователя элементов карты и текстур. Загрузка данных целиком при старте приложения не допускается. Необходимо реализовать механизм очистки памяти от элементов, которые находятся вне области видимости камеры в течение заданного времени. 4.2.4.1.5. Требования к взаимодействию пользователя с интерфейсом компонента «Интерактивная карта» Программная реализация механизмов управление камерой (масштабирование и навигация) должна быть выполнена с поддержкой технологии WebAssembly (WASM). Элементы управления должны являться неотъемлемой частью интерактивной карты. - 4.2.5. Развитие компонента администрирования (3 очередь) Должна быть выполнена доработка ролевой модели. Ролевая модель должна обеспечивать управление доступом к отдельным объектам Модуля СЦ и их элементам (атрибутам) с разграничением по видам транспорта, регионам и пр., в частности: – определение набора конкретных действий, доступных пользователям (выполняемых над объектом доступа, например, удаление записи, редактирование записи, формирование отчета и др.); – реализация возможности объединения пользователей в группы; – определение прав доступа для групп пользователей; – реализация интерфейса визуальной настройки прав доступа пользователей к объектам Модуля СЦ - 4.2.6. Взаимосвязи с внешними автоматизированными системами (1 очередь) Способы взаимодействия с внешними информационными системами должны быть определены на этапе технического проектирования. Должны быть выполнены следующие доработки: – интеграции с информационными ресурсами в целях получения данных о движении подвижных ТС (воздушные суда, суда водного транспорта); – интеграция с информационным ресурсом в целях получения данных о событиях на железнодорожном транспорте. Реализация интеграций должна включать проектирование и реализацию интеграционных механизмов обмена данными с учетом доступных вариантов реализации, обеспечение защищенных способов взаимодействия, настройку отображения отдельных данных на карте (настройка слоев). Взаимодействия, имеющие каналы связи, выходящие за пределы контролируемой зоны взаимодействующих систем, считаются защищенными, если для их защиты используются программные и/или программно-аппаратные шифровальные (криптографические) средства, сертифицированные ФСБ России (далее – СКЗИ). Выбор СКЗИ, схемы подключения и требуемого класса криптостойкости должен производиться в соответствии с Техническими условиями на подключение к информационным ресурсам ФГБУ «СИЦ Минтранса России» и инструкциями по подключению пользователей к ресурсам инфраструктуры Головного центра обработки данных, утвержденных приказом директора ФБГУ «СИЦ Минтранса России» от 24.05.2024 № 21-ОД - 4.3. Требования к оказанию услуг по технической поддержке Модуля СЦ 4.3.1. Общие требования к оказанию Услуг Техническая поддержка Модуля СЦ должна осуществляться с учетом требований постановления Правительства Российской Федерации от 06.07.2015 N 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации». Подрядчик обязан выполнять требования законодательства в сфере защиты информации, требования по защите информации, информационной безопасности, указанные в локальных нормативных актах ФГБУ «СИЦ Минтранса России», регламентирующих условия информационного взаимодействия, защиты информации и подключения к информационным ресурсам ФГБУ «СИЦ Минтранса России», участвующих в информационном взаимодействии в рамках оказания услуг по технической поддержке АСУ ТК в 2026 году - 4.3.1.1. Требования к составу и содержанию услуг третьего уровня технической поддержки Оказание услуг по технической поддержке Системы осуществляется в рамках этапов в соответствии с календарным планом. Подрядчик в течение 5 рабочих дней с даты заключения Контракта должен предоставить со своей стороны, а Заказчик со своей стороны Матрицу ответственных за взаимодействия в соответствии с Приложением 1 к Регламенту оказания услуг по третьему уровню технической поддержки Модуля СЦ (далее – Регламент, Приложение В). Подрядчик в течение 10 рабочих дней с даты заключения Контракта должен провести мероприятия по организации третьего уровня технической поддержки в соответствии с Регламентом. Услуги по третьему уровню технической поддержки Модуля СЦ должны включать: – организацию Подрядчиком третьего уровня технической поддержки; – информационно-консультационную поддержку работников Заказчика; – решение инцидентов, связанных с работой ППО; – адаптационное, конфигурационное и коррекционное сопровождение Модуля СЦ (в рамках действующих программных модулей и функциональности); – устранение уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности - 4.3.1.2. Требования к общему порядку оказания услуг Техническая поддержка Модуля СЦ должна быть организована на трех уровнях: – первый и второй уровни технической поддержки организуется Заказчиком; – третий уровень технической поддержки организуется Подрядчиком. Перечень действий на каждом уровне технической поддержки указан в Таблице 5: Таблица 5 – Перечень действий на каждом уровне технической поддержки Уровень технической поддержки Доступные действия Условия передачи задачи на следующий уровень Первый уровень технической поддержки (далее – 1-й уровень) – принимает обращения (заявки) пользователей Модуля СЦ и работников Заказчика; – регистрирует обращения в Модуле СЦ регистрации обращений; – присваивает уникальный идентификационный номер, классифицирует обращения; – самостоятельно решает обращения, которые связаны с недостаточной квалификацией пользователей или настройками в рамках своей компетенции; – взаимодействует с пользователями Модуля СЦ при решении проблемы Передает обращение на второй уровень поддержки в случае невозможности решения на своем уровне Второй уровень технической поддержки (далее – 2-й уровень) – принимает обращения от 1-го уровня; – уточняет классификацию обращения в результате дополнительного анализа; – самостоятельно решает обращения в рамках своей компетенции; – осуществляет техническую и консультационную поддержку Модуля СЦ; – взаимодействует с сотрудниками 1-го и 3-го уровня и пользователями Модуля СЦ; – формирует заявки для 3-го уровня и контролирует исполнение Передает обращение на третий уровень поддержки в случае невозможности решения на своем уровне Третий уровень технической поддержки (далее – 3-й уровень) – принимает обращения от 2-го уровня; – обеспечивает выполнение требований, предъявляемых Контрактом и настоящим Техническим заданием к Услугам, оказываемым Подрядчиком Все поступающие обращения должны быть исполнены Подрядчиком - Для обеспечения взаимодействия с Заказчиком Подрядчик со своей стороны определяет ответственных лиц, уполномоченных в структуре Подрядчика за своевременное и качественное оказание Услуг в рамках настоящего ТЗ, а также контактную информацию ответственных лиц (телефон, электронную почту). Подрядчик должен предоставить Заказчику единый адрес электронной почты для приема обращений (заявок) в течение 3 (трех) рабочих дней после заключения Контракта. Указанный в настоящем пункте адрес электронной почты (способ направления обращений (заявок) применяется в случае сбоя в работе СРО Заказчика. Со своей стороны, Заказчик предоставляет Подрядчику перечень и контактную информацию (телефон, электронную почту) уполномоченных лиц для осуществления взаимодействия с указанием зон ответственности. О любых изменениях в контактной информации ответственных лиц Стороны должны уведомить друг друга в течение 1 (одного) рабочего дня с момента возникновения таких изменений посредством уведомления на электронную почту ответственных лиц и/или в письменной форме. В результате оказания услуг по настоящему ТЗ не должны быть изменены исходные коды, дистрибутивы и иные компоненты Модуля СЦ вне согласованных с Заказчиком изменений. Любые изменения исходных кодов, дистрибутивов и иных компонентов Модуля СЦ должны производиться только после согласования с Заказчиком уполномоченными лицами по электронной почте или иным заранее согласованным способом. Не должна быть ухудшена надежность и производительность Модуля СЦ. Оказание услуг по Контракту не должно нарушать требования к информационной безопасности, описанной в документации на Модуль СЦ - Оказание услуг в рамках данного технического задания осуществляется Подрядчиком по обращению (заявке) Заказчика, направляемой посредством СРО Заказчика. Регистрация обращений, поступивших непосредственно в Модуль СЦ регистрации обращений Заказчика, производится сотрудниками Заказчика, которые обеспечивают первый уровень технической поддержки Модуля СЦ. В случае назначения приоритета «Критический» или «Высокий», информация о назначении также дублируется оповещением ответственных представителей Подрядчика посредством звонка на предоставленные номера телефонов. Обращение (заявка) должна содержать следующую информацию: – контакты пользователя/организации; – приоритет обращения, соответствующий Приложению 2 к Регламенту; – время обнаружения; – наименование компонента АСУ ТК - Модуль СЦ; Информация может быть расширена по согласованию с Заказчиком. Обращения (заявки) сотрудников Заказчика должны приниматься Подрядчиком через веб-интерфейс СРО. В процессе обработки обращений (заявок) Подрядчик должен обеспечить выполнение следующих процедур: – прием обращений(заявок) от сотрудников Заказчика; – оказание информационно-консультационной поддержки в соответствии с требованиями настоящего Технического задания; – информирование сотрудников Заказчика о статусе обработки и результатах обработки обращений(заявок). Подрядчик осуществляет обязательную регистрацию и учет всех обращений и заявок, поступивших к Подрядчику от представителей Заказчика в рамках оказания настоящих услуг - Примечание: в случае приостановки работы по обращению или заявке (обращение или заявка находится в статусе «Приостановлено»), указываются причины, по которым работы по обращению или заявке приостановлены с указанием перечня действий/информации, запрошенных у инициатора обращения, а также даты, формы и адресата такого запроса. В случае отклонения обращения или заявки (заполняется в случае, если обращению или заявке присваивается статус «Отклонено»), указываются подробно причины такого отклонения, а также фиксируется дата и время перехода в статус «Отклонено». В случае, если обращение или заявка отклонены (отменены) самим Инициатором, то указывается дата и способ, которым от инициатора получено соответствующее уведомление. В случае невыполнения Подрядчиком регламентного времени реагирования или решения обращения (заявки) Заказчик вправе отозвать обращение и направить его Подрядчику повторно. При этом каждое отозванное обращение учитывается в Отчёте об оказанных услугах, как обращение с превышением времени реагирования или решения, но оплате не подлежит. В случае, если обращение (заявка) связано с некачественным выполнением Подрядчиком другой задачи, такое обращение решается в регламентное время, установленное Техническим заданием, при этом оплате такие обращения не подлежат, о чем указывается в Отчете об оказанных услугах в графе «Примечание» - 4.3.1.3. Требования к регламенту оказания услуг Подрядчик должен руководствоваться Регламентом оказания услуг по технической поддержке Модуля СЦ. Регламент оказания услуг содержит следующую информацию: – порядок оказания услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Модуля СЦ; – порядок оказания услуги по решению инцидентов, связанных с работой ППО; – порядок оказания услуги адаптационного, конфигурационного и коррекционного сопровождения Модуля СЦ (в рамках действующих программных модулей и функциональностей); – порядок оказания услуги по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности. – Регламент содержит следующие формы заявок на оказание услуг: – форма заявки на оказание услуги по информационно-консультационной поддержке сотрудников Заказчика; – форма заявки на оказание услуги по решению инцидентов, связанных с работой ППО; – форма заявки на оказание услуг адаптационного, конфигурационного и коррекционного сопровождения Модуля СЦ (в рамках действующих программных модулей и функциональностей) (приоритет заявки определяется Заказчиком); – форма заявки на оказание услуги по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности - 4.3.2. Требования к режиму обеспечения функционирования Модуля СЦ Режим оказания услуг определен в Приложении Б к настоящему ТЗ. По согласованию с Заказчиком, в целях недопущения остановки функционирования Модуля СЦ в период интенсивной работы пользователей в Модуле СЦ, отдельные услуги могут оказываться по специальному графику (в нерабочее время Подрядчика) в соответствии с заявками Заказчика - 4.3.3. Требования к качеству оказываемых услуг Качество оказываемых услуг поддерживается Подрядчиком в соответствии с определяемыми данным ТЗ условиями и правилами и контролируется Заказчиком на постоянной основе, в том числе по соблюдению сроков исполнения и подтверждениям исполнения от инициаторов обращений и другим параметрам. По результатам выполнения работ по устранению инцидента должна быть устранена корневая причина инцидента с окончательным решением, устраняющим причину возникновения проблемы и исключающим вероятность повторного возникновения проблемы (инцидента). Время устранения корневых причин проблемы (инцидента) не должно составлять более 40 рабочих часов - 4.3.4. Требования к документированию результатов оказываемых услуг Для обеспечения контроля оказываемых услуг по поддержке Модуля СЦ со стороны Заказчика, по окончании каждого отчетного периода по контракту в соответствии с календарным планом, Подрядчик обязан предоставить Заказчику Отчет об оказанных услугах. Отчет должен содержать детальную информацию об оказанных услугах с указанием даты выполненных мероприятий и приложением обосновывающих документов (заявок, запросов, требований) или ссылкой на такие документы, если они содержатся в Модуле СЦ. Информация о выполненных мероприятиях по заявкам должна быть сформирована на основании соответствующих записей СРО по каждому этапу исполнения Контракта. В случае оказания услуги адаптационного, конфигурационного и коррекционного сопровождения Модуля СЦ, должны быть предоставлены документы, подтверждающие выполнение требований п. 29.3 приказа ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации». Фактическое время реагирования и время решения по всем обращениям, поступившим в СРО, формируется в СРО по итогам отчетного периода в разделе «Отчеты». Фактическое время реагирования и время решения по обращениям учитывает суммарное время, затраченное на реагирование и, соответственно, на работу по обращению с момента назначения обращения специалисту Подрядчика или группе исполнителей, ответственным за оказание услуг технической поддержки 3 уровня от начала до завершения работ Подрядчиком. При этом принимается суммарное время нахождения заявки в соответствующих статусах заявки СРО на стороне Подрядчика - 4.3.5. Требования к классификации обращений и заявок Обращения и заявки Заказчика классифицируются в соответствии с приоритетами и регламентными сроками, указанными в Приложении 2 к Регламенту. Регистрация обращений и заявок предусматривает создание новой записи в СРО с присвоением поступившему обращению или заявке (новой записи) уникального идентификатора. Запись в СРО должна содержать вопрос или проблему, которую требуется решить или оказать консультацию. Состав обязательной информации, которую должно содержать обращение или заявка, зафиксирован в Регламенте оказания Услуг. Если обращение или заявка автоматически зарегистрированы в СРО при отправке представителем Заказчика, Подрядчик проверяет корректность классификации обращения или заявки и может обратиться к Заказчику с просьбой корректировки, предоставив обоснования в соответствии с настоящей классификацией (Таблица 6) - 5. СОСТАВ И СОДЕРЖАНИЕ РАБОТ ПО РАЗВИТИЮ И ТЕХНИЧЕСКОЙ ПОДДЕРЖКЕ МОДУЛЯ СЦ (КАЛЕНДАРНЫЙ ПЛАН) - Сдача-приемка результатов выполненных работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная техническая документация, а также результаты работ предоставляются Заказчику в порядке, предусмотренном Контрактом и ТЗ, до размещения Подрядчиком в ЕИС документа о приемке. Документ о приемке размещается в ЕИС по каждому этапу в соответствии с условиями Контракта. Этапы выполнения работ по развитию Модуля СЦ приведены в Таблице 11. Таблица 11. Этапы выполнения работ по развитию Модуля СЦ. № этапа Наименование этапа Результат (отчетная документация) Срок исполнения этапа - - Значение характеристики не может изменяться участником закупки - 1 Техническое проектирование Сопроводительным письмом предоставляются Заказчику: · Технический проект, включая следующие документы: – Ведомость технического проекта; – Ведомость машинных носителей информации – Пояснительная записка; – Описание информационного обеспечения системы; – Описание автоматизируемых функций; – Схема функциональной структуры; – Описание организации информационной базы; – Описание программного обеспечения; · Макеты экранных форм компонента «Интерактивная карта»; · Руководство по безопасной разработке программного обеспечения; · Документ о приемке Начало: с даты заключения контракта Окончание: не позднее 31.07.2026 - 2 Услуги по технической поддержке Модуля СЦ (с даты заключения контракта по 10.09.2026) По окончании оказания Услуг сопроводительным письмом предоставляются Заказчику: – Отчет об оказанных Услугах по технической поддержке; – Актуальные на дату окончания оказания Услуг по данному этапу исходные коды прикладного ПО на электронном носителе (в случае внесения изменений); – Инструкция по сборке и развертыванию (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство пользователя (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство администратора (в случае внесения изменений); – Документ о приемке Начало: с даты заключения контракта Окончание: не позднее 10.09.2026 - 3 Разработка программного обеспечения (1 очередь, пп. 4.2.1, 4.2.6 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ; – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 1 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 1 очереди; – Руководство по резервному копированию; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 16.09.2026 - 4 Разработка программного обеспечения (2 очередь, пп. 4.2.3, 4.2.4 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ. – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 2 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 2 очереди; – Руководство по резервному копированию; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 25.09.2026 - 5 Разработка программного обеспечения (3 очередь, пп. 4.2.2, 4.2.5 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ; – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 3 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 3 очереди; – Руководство по резервному копированию; – Описание ролевой модели; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 09.10.2026 - 6 Опытная эксплуатация (1 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акт о завершении опытной эксплуатации 1 очереди; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке 17.09.2026 Окончание: не позднее 26.10.2026 - 7 Опытная эксплуатация (2 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акт о завершении опытной эксплуатации 2 очереди; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке 26.09.2026 Окончание: не позднее 26.10.2026 - 8 Опытная эксплуатация (3 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Акт о завершении опытной эксплуатации 3 очереди; – Документ о приемке Начало: с 10.10.2026 Окончание: не позднее 26.10.2026 - 9 Приемочные испытания Сопроводительным письмом предоставляются Заказчику: – Программа и методика приёмочных испытаний; – Протокол приемочных испытаний; – Исходные коды и дистрибутивы на электронном носителе (при условии внесения изменений, с учетом доработок по результатам опытной эксплуатации и проведенных испытаний); – Комплект рабочей документации на Модуль СЦ (при условии внесения изменений, с учетом доработок по результатам опытной эксплуатации и проведенных испытаний); – Акт приемки Системы в эксплуатацию; – Акт приемки-передачи исключительных прав на объект; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке; – Документы в соответствии с разделом 4.5.9 ТЗ; – Обеспечение гарантийных обязательств Начало: с 27.10.2026 Окончание: не позднее 10.11.2026 - 10 Услуги по технической поддержке Модуля СЦ (с 11.09.2026 по 15.12.2026) По окончании оказания Услуг сопроводительным письмом предоставляются Заказчику: – Отчет об оказанных Услугах по технической поддержке; – Актуальные на дату окончания оказания Услуг по данному этапу исходные коды прикладного ПО на электронном носителе (в случае внесения изменений); – Инструкция по сборке и развертыванию (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство пользователя (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство администратора (в случае внесения изменений); – Документ о приемке Начало: с 11.09.2026 Окончание: не позднее 15.12.2026 - Работы по развитию Системы (за исключением этапов проведения опытной эксплуатации и услуг по технической поддержке) могут быть выполнены досрочно. При досрочном выполнении работ (этапов работ) Подрядчик в письменной форме уведомляет Заказчика о готовности представить для приемки результаты проведения работ в соответствии с требованиями Контракта. Подрядчик также вправе досрочно приступать к работам в рамках очередного этапа при наличии технической, организационной готовности - при условии получения соответствующего согласования Заказчиком. Сдача-приемка результатов выполненных работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная, техническая документация, а также результаты Работ по каждому этапу предоставляется Заказчику в порядке, предусмотренном Контрактом и настоящим Техническим заданием, до размещения Подрядчиком в Единой информационной системе в сфере закупок документа о приемке. Документ о приемке размещается в ЕИС по каждому этапу в соответствии с условиями Контракта. Согласование документов осуществляется в электронном виде посредством переписки с адресов электронной почты Заказчика и Подрядчика, указанных в контракте. - 6. ПОРЯДОК РАЗРАБОТКИ МОДУЛЯ СЦ - Проектирование Модуля СЦ должно включать разработку следующих документов: – Ведомость технического проекта; – Ведомость машинных носителей информации – Пояснительная записка; – Описание информационного обеспечения системы; – Описание автоматизируемых функций; – Схема функциональной структуры; – Описание организации информационной базы; – Руководство по безопасной разработке программного обеспечения; – Описание программного обеспечения; – Макеты экранных форм компонента «Интерактивная карта». Структура документов должна соответствовать ГОСТ Р 59795-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов». Разработка Модуля СЦ должна включать в себя: – разработку программного обеспечения в части новых функций Модуля СЦ; – сборка исходного кода, развертывание и настройку доработанного программного обеспечения Модуля СЦ на вычислительных мощностях Заказчика (тестовый контур); – Комплект рабочей документации на Модуль СЦ; – разработку документа «Программа и методика предварительных испытаний»; – разработку документа «Программа и методика приемочных испытаний»; – разработку документа «Программа опытной эксплуатации». Структура документов должна соответствовать ГОСТ Р 59795-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов». В ходе выполнения работ формируется правоустанавливающая, отчетная, рабочая и техническая документация в соответствии с Контрактом и Календарным планом, приведенном в разделе 5. - - Значение характеристики не может изменяться участником закупки - 6.1. Сведения о гарантийном обслуживании Модуля СЦ Под гарантией понимается устранение Подрядчиком своими силами и за свой счет допущенных по его вине недостатков, выявленных после приемки выполненных Работ, как в работе самой Модуля СЦ, так и недостатков в отчетной документации. Если в период гарантийного срока обнаружатся недостатки, то Подрядчик обязан устранить их за свой счет, в сроки, установленные Заказчиком. Гарантийный срок в этом случае продлевается на период устранения недостатков. Срок гарантии: 1 год с даты приемки Заказчиком результатов исполнения Этапа № 9 контракта. Подрядчиком должны быть внесены соответствующие исправления в техническую и рабочую документацию (указанную в пунктах 5 и 6 настоящего ТЗ), связанные с устранением замечаний к работе Модуля СЦ или в случае выявления Заказчиком недостатков в такой документации в период гарантийного срока. Внесение изменений в документацию технического и рабочего проектирования осуществляется в соответствии с ГОСТ 2.503-2023 и ГОСТ Р 2.504-2021. - 7. ПОРЯДОК КОНТРОЛЯ И ПРИЕМКИ РЕЗУЛЬТАТОВ ВЫПОЛНЕНИЯ РАБОТ ПО РАЗВИТИЮ МОДУЛЯ СЦ - До момента подключения внешних ИС, Подрядчиком могут быть использованы эмуляторы ИС для прохождения предварительных испытаний, опытной эксплуатации и приемочных испытаний. В рамках опытной эксплуатации должны быть проведены мероприятия по нагрузочному тестированию Модуля СЦ. Документ «Программа и методика приемочных испытаний» должен быть разработан с учетом недостатков, выявленных в ходе опытной эксплуатации, утвержден Заказчиком до начала приемочных испытаний, при этом проверки Модуля СЦ в части не устраненных недостатков, выявленных в процессе опытной эксплуатации, должны быть вынесены в отдельный раздел «Программы и методики приемочных испытаний». В процессе приемочных испытаний должно быть проверено устранение недостатков, полученных в ходе опытной эксплуатации. После завершения устранения всех замечаний, препятствующих приемке Системы в эксплуатацию, перечисленных в Протоколе приемочных испытаний, Подрядчик должен письменно уведомить Заказчика о том, что все замечания устранены, после чего приемочные испытания по решению Заказчика могут быть проведены повторно. Процедура приемочных испытаний проводится до подписания Протокола приемочных испытаний, не содержащего замечаний, препятствующих приемке Системы в эксплуатацию. Приемочные испытания Системы считаются завершенными успешно, если Протокол приемочных испытаний не содержит замечаний, препятствующих приемке Системы в эксплуатацию - - Значение характеристики не может изменяться участником закупки - Испытания должны быть организованы и проведены в соответствии с ГОСТ Р 59792-2021 «Информационная технология. Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем». Должны быть проведены следующие виды испытаний: – предварительные испытания; – опытная эксплуатация; – приемочные испытания. Указанные виды испытаний проводятся в отношении не функциональных требований и функциональных возможностей, разрабатываемых в соответствии с настоящим ТЗ. Отдельные виды испытаний проводятся поэтапно в сроки, установленные Календарным планом. Предварительные испытания, опытная эксплуатация, приемочные испытания проводятся комиссией, создаваемой организационно-распорядительным документом Заказчика, который должен определять состав комиссии, порядок ее работы. Методы предварительных испытаний и порядок их проведения должны быть определены в документе «Программа и методика предварительных испытаний», который должен быть утвержден Заказчиком до начала предварительных испытаний. По результатам предварительных испытаний оформляется Протокол предварительных испытания и Акт о приемке в опытную эксплуатацию. Порядок проведения и методы испытаний во время опытной эксплуатации должны быть определены в документе «Программа опытной эксплуатации», который должен быть утвержден Заказчиком до начала опытной эксплуатации. Ход и результаты опытной эксплуатации отражаются в документе «Журнал опытной эксплуатации», и учитываются в ходе приемочных испытаний. По результатам опытной эксплуатации подписывается Акт о завершении опытной эксплуатации - 8. ТРЕБОВАНИЯ К СОСТАВУ И СОДЕРЖАНИЮ РАБОТ ПО ПОДГОТОВКЕ МОДУЛЯ СЦ К ВВОДУ В ЭКСПЛУАТАЦИЮ - По результатам проведения приемочных испытаний оформляется Протокол приемочных испытаний и Акт приемки в эксплуатацию. В случае, если взаимодействие с внешними системами не может быть проверено на средах постоянной эксплуатации взаимодействующих систем (по причине неготовности со стороны внешней системы или иным причинам), функции взаимодействия, разработанные в соответствии с требованиями ТЗ, должны быть проверены на тестовых данных с использованием программ-имитаторов взаимодействия. По результатам выполнения этапа приемочных испытаний должны быть подготовлены материалы для регистрации доработанной версии Модуля СЦ (объекта учета) в НФАП в соответствии с требованиями постановления Правительства Российской Федерации от 30 января 2013?г. №?62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин» (с изменениями и дополнениями) в части обязательности размещения результатов работ в национальном фонде алгоритмов и программ для электронных вычислительных машин. Сдача-приемка результатов выполнения Работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная, техническая документация, а также программное обеспечение предоставляется Заказчику в порядке, предусмотренном Контрактом и ТЗ до размещения Подрядчиком в Единой информационной системе в сфере закупок документа о приемке. Результаты проведения опытной эксплуатации, предварительных и приемочных испытаний должны быть зафиксированы в соответствующих протоколах и актах. Выявленные отклонения от настоящего ТЗ, оформляются как недостатки Модуля СЦ - - Значение характеристики не может изменяться участником закупки - Протоколы предварительных и приемочных испытаний должны содержать вывод о соответствии Модуля СЦ предъявляемым требованиям, а также сроки устранения замечаний и реализации рекомендаций, сформулированных комиссией в ходе предварительных и приемочных испытаний. Условием для передачи Модуля СЦ в промышленную эксплуатацию является устранение всех замечаний. Документация на Модуль СЦ и ее части (техническая и рабочая) должна содержать исчерпывающее описание принятых проектных решений в объеме, достаточном для ее дальнейшего развития и эксплуатации. Техническая и рабочая документация должна содержать описание разработанных результатов работ, в том числе программ для ЭВМ, прикладных программных интерфейсов, алгоритмов и протоколов информационного взаимодействия, технических требований, спецификаций и форматов обмена данными для взаимодействия с другими информационными системами, в объеме, достаточном для их установки, настройки, эксплуатации и развития в дальнейшем без привлечения Подрядчика. Исходные коды передаются в виде и составе, позволяющем провести: – сборку (компиляцию) Модуля СЦ в контролируемой Заказчиком среде; – установку полученной Модуля СЦ на специально подготовленную контролируемую Заказчиком инфраструктуру; – проверку функциональных возможностей Модуля СЦ; – оформление Модуля СЦ в качестве объекта национального фонда алгоритмов и программ для электронных вычислительных машин - 8.1. Требования, предъявляемые в соответствии с Приказом Минцифры России от 17.12.2020 № 715 «Об утверждении типовых условий контрактов на выполнение работ по созданию и (или) развитию (модернизации) государственных (муниципальных) и (или) иных информационных систем» Передача исходных кодов, разработанных в ходе выполнения работ, программ для электронных вычислительных машин (далее – программа для ЭВМ) должна сопровождаться передачей всех необходимых для сборки и запуска программы для ЭВМ библиотек зависимостей, программных сценариев (скриптов) для проведения установки (развертывания) программы для ЭВМ. Подрядчик в процессе сдачи-приемки работ по Контракту должен провести демонстрацию процесса и установки (развертывания) разработанных программ для ЭВМ. Документация на Модуль СЦ должна содержать описание принятых проектных решений в объеме, достаточном для ее дальнейшего развития и эксплуатации - 9. ТРЕБОВАНИЯ К ДОКУМЕНТИРОВАНИЮ - 9.1. Общие требования Документация на Модуль СЦ должна быть разработана в составе, указанном в разделах 5-8 данного ТЗ, и должна удовлетворять требованиям комплекса стандартов и руководящих документов на автоматизированные системы: – ГОСТ Р 2.105-2019 в части оформления текстовых документов; – ГОСТ 34.201-2020 в части наименования и обозначения документов. Документация на Модуль СЦ должны оформляться на листах формата А4. Допускается для размещения рисунков и таблиц использование листов формата А3 с подшивкой по короткой стороне листа. Документы объемом более 25 (двадцати пяти) листов должны содержать информационную часть, состоящую из аннотации и содержания. Исходные коды должны быть представлены в 1 (одном) экземпляре на электронном носителе, отчетные материалы должны быть представлены в 2 (двух) экземплярах на бумажном носителе (по одному экземпляру для Заказчика и Подрядчика) и в 1 (одном) экземпляре на электронном носителе в формате документов DOCX и PDF. При разработке документов на Модуль СЦ допускается отклонение от требований комплекса стандартов, описанных выше. Документам на Модуль СЦ должны в обязательном порядке присваиваться уникальные децимальные номера в соответствии с порядком, установленном в ГОСТ 34.201-2020. Документ «Программа и методика предварительных испытаний» должен включать приложения с формой протокола предварительных испытаний и формой акта приемки в опытную эксплуатацию. Документ «Программа опытной эксплуатации» должен включать приложение с формой журнала опытной эксплуатации. Документ «Программа и методика приемочных испытаний» должен включать приложения с формой протокола приемочных испытаний и формой акта приемки в эксплуатацию - - Значение характеристики не может изменяться участником закупки - 10. ИСТОЧНИКИ РАЗРАБОТКИ - 10.1. Список литературы Специальная литература для разработки ТЗ не использовалась. 10.2. Нормативно-методические документы Список используемых нормативно-методических документов представлен в разделе 1.6 технического задания. ? Приложение А Эскизы визуального оформления компонента «Интерактивная карта» - - Значение характеристики не может изменяться участником закупки - Приложение Б Параметры оказания услуг - Б.1. Базовые параметры оказания Услуг Базовые параметры оказания Услуг приведены ниже: – режимы оказания Услуг (таблица Б.1.1); – сроки предоставления отчетности (таблица Б.1.2). Таблица Б.1.1 - Режимы оказания Услуг № п/п Параметр Значение - - Значение характеристики не может изменяться участником закупки - 1 Режим работы Системы Круглосуточно (24х7) 2 Режим доступности информационно-консультационной поддержки пользователей Системы 2.1 Прием и регистрация обращений (заявок) в СРО Регистрация обращений (заявок) производится круглосуточно в режиме 24х7, без праздников и выходных дней. Обработка заявок первой линией поддержки осуществляется в рабочие дни с 9 до 18 часов 2.2 Консультирование сотрудников Заказчика и пользователей Системы в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 3 Режим доступности по решению инцидентов, связанных с работой ППО: 3.1 - приоритет «Критический» Круглосуточно (24х7) 3.2 - приоритет «Высокий» Круглосуточно (24х7) 3.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 3.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4 Режим доступности услуг по адаптации, конфигурации и коррекционному сопровождению Системы 4.1 - приоритет «Критический» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.2 - приоритет «Высокий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 5 Режим доступности по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности 5.1 - приоритет «Критический» Круглосуточно (24х7) 5.2 - приоритет «Высокий» Круглосуточно (24х7) 5.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 5.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) - Таблица Б.1.2. Сроки предоставления отчетности, с момента получения запроса № п/п Параметр Значение 1 Предоставление отчета об оказанных услугах за произвольный период 10 рабочих дней 2 Предоставление подробной информации по инциденту с приоритетом «Критический» 16 рабочих часов 3 Предоставление актуализированной документации 10 рабочих дней - Б.2. Приоритеты и регламентные сроки решения обращений (заявок) В зависимости от уровня сбоя в работе Системы обращению (заявке) присваивается один из следующих приоритетов, а также в зависимости от приоритета обращения (заявки) устанавливаются следующие контрольные сроки решения в соответствии с таблицей ниже (Таблица Б.2.1). Таблица Б.2.1 – Приоритеты и регламентные сроки решения обращений (заявок) № п/п Приоритет Максимальное время реагирования Время решения (срок выполнения) Описание приоритета По информационно-консультационной поддержке сотрудников Заказчика и пользователей Системы 1 - не более 1 часа не более 10 часов - По решению инцидентов, связанных с работой ППО: 1 Критический не более 30 минут не более 4 часов - полная недоступность ППО; - недоступность ключевых функций - ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО; - невозможность информационного обмена с ППО для ИС более 4 часов 2 Высокий не более 1 часа не более 8 часов - ошибки/сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; - снижение быстродействия СПО (время отклика ППО на операции превышает 30 секунд); - недоступность управления правами и ролями пользователей 3 Средний не более 4 часов не более 24 часов - невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым -недоступность функции формирования отчетов 4 Низкий не более 8 часов не более 40 часов - отклонение в работе ППО, не влияющее на корректную работу функций; - другие сбои и ошибки, затрагивающие основные функции ППО - По адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) 1 Критический не более 40 минут не более 8 часов - изменения, необходимые при проведении аварийно-восстановительных работ для возобновления работоспособности Системы; - изменения, связанные с критичными ошибками, блокирующими возможность оказания государственных услуг и/или чтение и внесение данных в Систему 2 Высокий не более 1 часа не более 40 часов - изменения, относящиеся к обеспечению работоспособности основной функциональности Системы, устраняют выявленные дефекты в работе Системы, оказывающие существенное влияние на работу пользователей в Системе; - изменения, затрагивающие три и более подсистемы/модуля Системы для адаптации 3 Средний не более 4 часов не более 72 часов - изменения, связанные с развитием/улучшением/оптимизацией Системы и выводом новой функциональности в штатном режиме для одного-двух модулей/подсистем; - изменения, связанные с развитием интеграционных механизмов Системы, например обновление существующих и/или реализация новых видов сведений СМЭВ, обновление существующих и/или реализация новых API, адаптация и/или изменение механизмов импорта и экспорта данных Системы и т.д. 4 Низкий не более 8 часов не более 160 часов - изменения, связанные с ошибками/корректировкой/изменением в отображении информации в пользовательском графическом интерфейсе Системы (графика, текст, органы управления, элементы интерфейса) - По устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности 1 Критический не более 30 минут не более 24 часов - критические уязвимости, влияющие на возможную полную недоступность ППО, ключевых функций Системы, ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО без возможности восстановления работоспособности Системы. - Критический уровень CVSS > 8.0 2 Высокий не более 1 часа не более 84 часов - критические уязвимости, влияющие на ошибки и сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО. - Высокий уровень CVSS 5.0 - 8.0 3 Средний не более 4 часов не более 120 часов - уязвимости, влияющие на невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым - Средний уровень CVSS 2.0 - 4.9 4 Низкий не более 8 часов не более 160 часов - уязвимости, влияющие на отклонение в работе ППО, не влияющее на корректную работу функций; - другие сбои и ошибки, затрагивающие основные функции ППО - Низкий уровень CVSS < 2.0 - Взаимодействие Заказчика и Подрядчика в части регистрации и контроля времени реагирования и решения обращения (заявки) осуществляется через СРО. Заказчик предоставляет Подрядчику доступ к СРО после заключения Контракта. Поступившие от разных пользователей заявки по поводу однотипных инцидентов или имеющие общую причину должны объединяться в одну заявку. Срок выполнения включает время диагностики инцидента, в ходе которого определяется причина инцидента (проблемы) и способ его устранения. Подрядчик должен обеспечить функционирование Модуля СЦ в соответствии с требованиями и параметрами, указанными в настоящем ТЗ и Регламенте оказании услуг. Основные параметры быстродействия типовых операций в Модуле СЦ указаны в таблице ниже (таблица Б.2.2). Таблица Б.2.2 - Параметры быстродействия Модуля СЦ № п/п Наименование параметра Значение (секунд) 1 Среднее время получения сообщения из очереди сообщений 10 2 Среднее время получения ответа от Системы 5 3 Среднее время открытия карточки реестра 5 - Приложение В Регламент оказания услуг - Уровень технической поддержки Организационно-структурная часть технической поддержки, имеющая определённые организационно-нормативными документами зоны ответственности, обязанности, а также временные нормативы, в течение которых эти обязательства должны выполняться либо эскалироваться на следующий уровень технической поддержки Услуги Услуги по технической поддержке Информационно-аналитической системы регулирования на транспорте АСУ ТК ФИО Фамилия, имя, отчество Эскалация Процедура повышения внимания к обращению (заявке) путем повышения его приоритета и/или передачи на следующий уровень технической поддержки, а также привлечение ролей, которые могут принимать решения без передачи на следующий уровень технической поддержки API Англ. Application Programming Interface — программный интерфейс приложения, интерфейс прикладного программирования — описание способов (набор классов, процедур, функций, структур или констант), которыми одна компьютерная программа может взаимодействовать с другой программой - - Значение характеристики не может изменяться участником закупки - CVSS Англ. Common Vulnerability Scoring System - открытый стандарт, используемый для расчета количественных оценок уязвимости в безопасности компьютерной системы, обычно с целью понять приоритет ее исправления. В современном инструментарии информационной безопасности используется версия 3.0 и выше с дополнительными метриками к базовым оценкам ID Англ. Identifier – идентификатор, уникальный признак объекта, позволяющий отличать его от других объектов, то есть, идентифицировать SLA Англ. Service Level Agreement - утвержденные условия по обработке обращения (заявки) с установленными метриками времени, которые определяют пороговые значения для эскалации в зависимости от статуса обращения (заявки) (например, время реакции – время от регистрации до осуществления первичной обработки, время решения – время от регистрации обращения (заявки) до его решения и т.д.) SQL Англ. Structured Query Language — «язык структурированных запросов», — декларативный язык программирования, применяемый для создания, модификации и управления данными в реляционной базе данных, управляемой соответствующей СУБД - 1 Общие сведения 1.1 Полное наименование Услуг Оказание услуг по технической поддержке Модуля СЦ АСУ ТК в 2026 году. 1.2 Предмет Регламента оказания услуг Требования Технического задания - 2 Общие положения 2.1 Цель и задачи оказания услуг Целью технической поддержки Системы является обеспечение ее стабильного и безопасного функционирования и эксплуатации, предупреждение, выявление и устранение сбоев в работе Системы и минимизация их неблагоприятного влияния. Для достижения поставленной цели требуется решение следующих задач: 1. Обеспечение информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы. 2. Поддержание параметров функционирования ППО Системы, удовлетворяющих требованиям производственных процессов, включая их непрерывность. 3. Обеспечение бесперебойного функционирования ППО и своевременное устранение сбоев и аварийных ситуаций в Системе. 4. Своевременное устранение уязвимостей при выявлении таковых, в соответствии с требованиями к обеспечению информационной безопасности. 5. Адаптация, конфигурирование, коррекция программного обеспечения в соответствии с изменениями нормативно-правовой базы и запросами уполномоченных сотрудников органов государственной власти, включая выполнение процедур тестирования и участие в обновлениях ППО на стендах Заказчика. 6. Обеспечение сохранения работоспособности ППО в изменяемой среде эксплуатации. 7. Ведение документации по настоящему контракту и инициирование актуализации документации на Систему по результатам обработки запросов Заказчика и внесения соответствующих изменений в ППО - Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 8) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 8) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 8) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 8) Категория обращения (заявки): инцидент Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 8) Приоритет Время, очередность решения обращения (заявки), ресурсы, привлекаемые для решения обращения (заявки), порядок/процедура действий при решении обращения (заявки) – поле СРО «Приоритет» (см. рисунок 8) Тип изменения Справочник, классифицирующий типовые запросы характерные для Системы – поле СРО «Предмет обращения» (см. рисунок 8) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 8) Текст запроса на оказание услуги по обновлению или удалению уязвимых компонентов (библиотек) ППО в соответствии с требованиями к обеспечению информационной безопасности Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 8) - На рисунке 8 приведена форма обращения (заявки) типа «Инцидент» в СРО. Рисунок 8 - Форма обращения (заявки) типа «Инцидент» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуги по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности, заполненную в свободной форме - Приложение 1 к Регламенту Матрица ответственных за взаимодействия в рамках выполнения работ по техническому сопровождению Системы Таблица 1 – Ответственные за взаимодействия в рамках выполнения работ по техническому сопровождению Системы со стороны Исполнителя ФИО Должность Адрес электронной почты Телефон — — — Общий контакт - Приложение 2 к Регламенту Приоритеты и регламентные сроки решения обращений (заявок) Приоритеты и регламентные сроки решения обращений (заявок) приведены в таблице 1. Таблица 1 – Приоритеты и регламентные сроки решения обращений (заявок) № п/п Приоритет Максимальное время реагирования Время решения (срок выполнения) Описание приоритета - По информационно-консультационной поддержке сотрудников Заказчика и пользователей Системы 1 – не более 1 часа не более 10 часов – - 2.2 Общее описание процесса оказания сопровождения (технической поддержки) Системы Процесс оказания технической поддержки Системы включает: 1. Поступление обращений (заявок) от пользователей и их регистрацию. 2. Сопровождение обращений (заявок) в соответствии с их классификацией и приоритизацией, в том числе, с их последующей эскалацией. 3. Определение ролей и регламент их взаимодействия при осуществлении деятельности по процессу. 4. Решение обращений (заявок) в установленные настоящим Регламентом сроки. 5. Взаимодействие между 1-м, 2-м и 3-м уровнями технической поддержки, в том числе, с формированием заданий для сопровождения Системы. 6. Контроль качества выполняемых Исполнителем работ, состоящий из проверки сценария, приводящего к ошибке, зафиксированной в Инциденте, и/или к ошибке воспроизведения, а также тестирование внесенных изменений в рамках ЗНИ. 7. Обеспечение мониторинга и проведение анализа процесса обработки поступающих в техническую поддержку обращений (заявок). Техническая поддержка реализуется путем проведения ответственными сотрудниками соответствующей информационно-консультационной деятельности в соответствии с определенными ролями, а также выполнения Исполнителем конкретных действий по своевременному выявлению причин сбоев и аварийных ситуаций и их устранению, а также по адаптации, конфигурированию, корректировке Системы, включая выполнение процедур тестирования и участия в обновлениях Системы. Все роли подразделяются на уровни поддержки, взаимодействующие между собой в соответствии с блок-схемой процесса технической поддержки. Общая схема процесса рассмотрения обращений (заявок) в соответствии с видами технической поддержки представлена на рисунке 1. . Рисунок 1 - Общая схема процесса рассмотрения обращений (заявок) в соответствии с видами технической поддержки - 2.3 Каналы связи Должна быть предусмотрена омниканальность в части приема обращений (заявок). Получение обращений (заявок) технической поддержкой происходит по следующим каналам связи: – СРО; – электронная почта; – телефонная линия. Исполнитель обеспечивает прием обращений (заявок) от Заказчика и предоставляет информацию в рамках оказания услуг по техническому сопровождению Системы, руководствуясь матрицей взаимодействия, приведенной в Приложении 1 к настоящему Регламенту - 3 Порядок оказания Услуг 3.1 Типы обращений (заявок) Обращения и заявки Заказчика классифицируются в соответствии с приоритетами и регламентными сроками, указанными в Приложении 2 к настоящему Регламенту. Регистрация обращений и заявок предусматривает создание новой записи в СРО с присвоением поступившему обращению или заявке (новой записи) уникального идентификатора. Запись в СРО должна содержать вопрос или проблему, которую требуется решить или оказать консультацию. Если обращение или заявка автоматически зарегистрированы в СРО при отправке представителем Заказчика, Исполнитель проверяет корректность указанного типа обращения (заявки) и может обратиться к Заказчику с просьбой корректировки, предоставив обоснования в соответствии с настоящей классификацией (Таблица 1) - По решению инцидентов, связанных с работой ППО 1 Критический не более 30 минут не более 4 часов – полная недоступность ППО; – недоступность ключевых функций; – ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО; – невозможность информационного обмена с ППО для ИС более 4 часов 2 Высокий не более 1 часа не более 8 часов – ошибки/сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; – снижение быстродействия СПО (время отклика ППО на операции превышает 30 секунд); – невозможность управления правами и ролями пользователей 3 Средний не более 4 часов не более 24 часов – невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым недоступность функции формирования отчетов 4 Низкий не более 8 часов не более 40 часов – отклонение в работе ППО, не влияющее на корректную работу функций; – другие сбои и ошибки, затрагивающие основные функции ППО - По адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) 1 Критический не более 40 минут не более 8 часов – изменения необходимые при проведении аварийно-восстановительных работ для возобновления работоспособности Системы; – изменения, связанные с критичными ошибками, блокирующими возможность оказания государственных услуг и/или чтение и внесение данных в Систему 2 Высокий не более 1 часа не более 40 часов – изменения относящиеся к обеспечению работоспособности основной функциональности Системы, устраняют выявленные дефекты в работе Системы, оказывающие существенное влияние на процесс оказания государственных услуг и работу пользователей в Системе; – изменения, затрагивающие три и более подсистемы/модуля Системы для адаптации 3 Средний не более 4 часов не более 72 часов – изменения, связанные с развитием/улучшением/оптимизацией Системы и выводом новой функциональности в штатном режиме для одного-двух модулей/подсистем; – изменения, связанные с развитием интеграционных механизмов Системы, например, обновление существующих и/или реализация новых видов сведений СМЭВ, обновление существующих и/или реализация новых API, адаптация и/или изменение механизмов импорта и экспорта данных Системы и т.д. 4 Низкий не более 8 часов не более 160 часов – изменения, связанные с ошибками/ корректировкой/изменение в отображении информации в пользовательском графическом интерфейсе Системы (графика, текст, органы управления, элементы интерфейса) - По устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности 1 Критический не более 30 минут не более 24 часов – критические уязвимости, влияющие на возможную полную недоступность ППО, ключевых функций Системы, ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО без возможности восстановления работоспособности Системы; – Критический уровень CVSS > 8.0 2 Высокий не более 1 часа не более 84 часов – критические уязвимости, влияющие на ошибки и сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; – Высокий уровень CVSS 5.0 - 8.0 3 Средний не более 4 часов не более 120 часов – уязвимости, влияющие на невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым; – Средний уровень CVSS 2.0 - 4.9 4 Низкий не более 8 часов не более 160 часов – уязвимости, влияющие на отклонение в работе ППО, не влияющее на корректную работу функций; – другие сбои и ошибки, затрагивающие основные функции ППО; – Низкий уровень CVSS < 2.0 - Таблица 1 - Типы обращений (заявок) Тип обращения (заявки) Описание Запрос на обслуживание Подготовка SQL запроса к СУБД для решения прикладной задачи и д р. – запрос на любое действие, не являющееся запросом информации и несовершенный на основе происшествия, прямо или косвенно влияющего на работу Системы Консультация (входит в тип обращения (заявки) «Запрос на обслуживание») «Где взять / куда обратиться...?», «Как сделать / выполнить…», «Как это работает…?» - запрос, имеющий своей целью получение информационной поддержки Инцидент Разбор ошибок/сбоев и подготовка материалов (корректировочных релизов, инструкций) для Заказчика для устранения ошибок/сбоев, которые приводят к частичному и полному нарушению работоспособности всех или отдельных функций ППО. Подготовка изменения и материалов, необходимых для проведения аварийно-восстановительных работ для возобновления работоспособности Системы. ЗНИ Подготовка изменений, связанных с изменением, улучшением/оптимизацией Системы и выводом новой модифицированной функциональности в штатном режиме. Подготовка изменений, связанных с модификацией существующих и/или реализация новых интеграционных механизмов для получения/обработки данных внешних систем. Подготовка изменений графического интерфейса по требованиям Заказчика - 3.2 Участники технической поддержки, осуществляющие сопровождение обращений (заявок) Техническая поддержка Системы должна быть организована на трех уровнях: 1. Первый и второй уровни технической поддержки организуется Заказчиком. 2. Третий уровень технической поддержки организуется Исполнителем. Зона ответственности каждого уровня технической поддержки указана в Таблице 2. Таблица 2 - Зона ответственности каждого уровня технической поддержки Участники технической поддержки Описание - Первый уровень технической поддержки (далее – 1-й уровень) Группа ответственных сотрудников 1-го уровня Заказчика, осуществляющая прием и первичную обработку обращений (заявок) (описание предмета обращения, первичная классификация и приоритизация, определение назначения, маршрутизация обращений (заявок) по назначению), руководствуется в своей работе настоящим Регламентом и БЗ, наполняемой 2-м уровнем поддержки, самостоятельно решает часть обращений (заявок), связанных с недостаточной квалификацией пользователей или настройками в рамках своей компетенции. В случае невозможности решения обращений (заявок) на 1-ом уровне ответственный сотрудник передает ее на 2-й уровень - Второй уровень технической поддержки (далее – 2-й уровень) Группа ответственных сотрудников 2-го уровня Заказчика по установленным компетенциям (информационная безопасность, сопровождение и эксплуатация информационно-аналитических систем, развитие информационно-аналитических систем, техническая поддержка информационно-аналитических систем) отвечает за поддержание работоспособности Системы, обработку обращений (заявок) и их решение в регламентные сроки в соответствии с установленными приоритетами. Осуществляет информационно-консультационную поддержку пользователей Системы в рамках своей компетенции. Оказывает экспертную помощь ответственным сотрудникам 1-го уровня в части формирования БЗ, содержащей ответы на часто задаваемые вопросы пользователей, с целью передачи знаний, навыков и инструментария на 1-й уровень для ускорения решения обращений (заявок). В случае невозможности решения обращения (заявки) на 2-ом уровне ответственный сотрудник передает его на 3-й уровень. При выявлении необходимости изменений в ППО Системы инициирует формирование обращения (заявки) и направляет его на группу ответственных сотрудников 3-го уровня по соответствующему классификатору (ЗНО, ЗНИ, и т.д.) - Приложение Г Форма Отчета об оказанных услугах Отчет об оказанных услугах за этап «наименование этапа» в период с «__» _________ по «__» _________. № п/п Наименование услуги Общее количество Номер ОРС Краткое Описание Время реагирования по ТЗ Время реагирования фактическое Время решения по ТЗ Время решения фактическое Результат соблюдения времени реагирования Результат соблюдения времени решения Примечание 1 Услуги по информационно-консультационной поддержке работников Заказчика 2 546782 Консультация по работе Модуля СЦ 1 2 10 часов 11 часов Нет Нет 567123 Консультация по схеме БД 1 1 10 часов 1 час Да Да 2 … … Заказчик Подрядчик /Должность/ /Должность/ ____________________ /Ф.И.О/ ___________________ /Ф.И.О/ М.П. М.П. «_____»_______________________202_г. «_____»_______________________202_г - Приложение 1 к Отчету об оказанных услугах Журнал обращений (заявок) на оказание услуги по информационно-консультационной поддержке пользователей Системы (шаблон) Наименование Исполнителя в этапе «наименование этапа» в период с ________________ по _______________ оказал(о) Услугу по поддержке пользователей Системы в объеме, указанном в Таблице 1 Таблица 1 - Журнал обращений (заявок) пользователей Системы № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. ИТОГО зарегистрировано: Всего обращений (заявок): ________ ИТОГО решено: Всего обращений (заявок): ________ - Приложение 2 к Отчету об оказанных услугах Журнал обращений (заявок) по решению инцидентов, связанных с работой ППО (шаблон) Наименование Исполнителя в этапе «наименование этапа» в период с ________________ по _______________ оказал(о) Услугу по решению инцидентов в объеме, указанном в Таблице 1. Таблица 1 - Журнал по решению инцидентов № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. ИТОГО зарегистрировано: Всего инцидентов: ________ ИТОГО решено: Всего инцидентов: ________ - Приложение 3 к Отчету об оказанных услугах Журнал обращений (заявок) выполнения адаптационного, конфигурационного и коррекционного сопровождения Системы (шаблон) Журнал выполнения адаптации, конфигурации и коррекции Системы сформирован за этап «наименование этапа» в период с «__» _________ по «__» ____________ и представлен в таблице ниже (Таблица 1). Таблица 1 - Журнал выполнения адаптации, конфигурации и коррекции сопровождения Системы № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. Количество выполненных заявок за этап: ________ - Приложение 4 к Отчету об оказанных услугах Журнал обращений (заявок) по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности (шаблон) Журнал обращений (заявок) по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности сформирован за этап «наименование этапа» в период с «__» _________ по «__» ____________ и представлен в таблице ниже (Таблица 1). Таблица 1 - Журнал выполнения заявок по устранению уязвимостей в ППО № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. Количество выполненных заявок за этап: ________ - Третий уровень технической поддержки (далее – 3-й уровень) Группа ответственных сотрудников Исполнителя, отвечающая за устранение сбоев и аварий, проведение информационно-консультационной поддержки пользователей Системы, проведение адаптации и конфигурирования Системы в объемах действующих контрактов на оказание технической поддержки - 3.3 Перечень и описание статусов обращений (заявок) В Таблице 3 приведен перечень статусов обращений (заявок), действующий в СРО, и их описание. Таблица 3 - Перечень статусов обращений (заявок) и их описание Статус Описание Зарегистрирован Обращение (заявка) принято и зарегистрировано Направлен в группу Присваивается при назначении ответственными сотрудниками 1-го уровня группе ответственных сотрудников 2-го уровня по тематике обращения (заявки) после заполнения всей необходимой информации и полей обращения (заявки), а также при его передаче между группами 2-го уровня Передан в группу Присваивается при передаче обращения (заявки) ответственными сотрудниками 2-го уровня на группу ответственных сотрудников 3-го уровня Назначен Присваивается при назначении обращения (заявки) на ответственного сотрудника для его решения в рамках компетенции В работе Присваивается при приеме обращения (заявки) в работу ответственным сотрудником для его решения Решен Присваивается ответственным сотрудником, выполнившим работы по обращению (заявке) Закрыт Присваивается автоматически при решении запроса по обращению (заявке), а также отсутствии дополнительных запросов пользователя в соответствии с действующим SLA, или при подтверждении решения обращения (заявки) со стороны пользователя Запрос доп. информации Присваивается при необходимости запроса дополнительной информации и/или уточнения предмета обращения по обращению (заявке) у пользователя Ответ предоставлен Присваивается после ответа пользователем на запрос дополнительной информации Отклонен Присваивается, если обращение (заявка) не актуальна (по информации от пользователя), отсутствует техническая возможность решения обращения (заявки), предмет обращения не входит в компетенции технической поддержки, или существует влияние доработки на другие компоненты, что нарушает общий порядок работы Системы - Согласование Присваивается при необходимости согласования направления обращения (заявки) ответственным сотрудником Заказчика на 3-й уровень Анализ Присваивается при проведении анализа на предмет возможности внесения изменений, связанных с развитием/улучшением/оптимизацией Системы и выводом новой функциональности и оценке ресурсоемкости Тестирование Присваивается Исполнителем при завершении разработки и проведенном предварительном тестировании для последующего осуществления приемочного тестирования Специалистом 2-го уровня Релиз Присваивается ответственным сотрудником Заказчика при принятии решения о возможности вывода доработки в продуктивную среду Утверждение заказчиком Присваивается при согласовании группой профильных специалистов на 2-м уровне поддержки с пользователем технического задания для внесения изменений, связанных с развитием/улучшением/оптимизацией Системы и выводом новой функциональности Доработка Присваивается в случае несогласования Заказчиком работ, проведенных Исполнителем в рамках контрактных обязательств, по внесению изменений, связанных с развитием/улучшением/оптимизацией Системы и выводом новой функциональности в штатном режиме, и необходимости последующего направления Исполнителю для ее доработки Отложен Присваивается в случае невозможности выполнения запроса, изложенного в обращении (заявке), в связи с необходимостью запроса дополнительной информации у третьих сторон - Приложение Д Форма Протокола проверки результатов организационно-штатных и подготовительных мероприятий (шаблон) Протокол проверки результатов организационно-штатных и подготовительных мероприятий Настоящий Протокол содержит результаты проверки организационно-штатных и подготовительных мероприятий, проведенных Исполнителем (Таблица Д.1). Таблица Д.1. Протокол проверки результатов № Мероприятия Подготовительного этапа Результат проверки 1. Определить и направить Заказчику документ «Ответственные за взаимодействия в рамках выполнения работ по техническому сопровождению Системы со стороны Исполнителя». Документ содержит контактную информацию (ФИО, должность, адрес электронной рабочей почты, номер телефона) не менее чем о 2 лицах, ответственных за оказание услуг со стороны Подрядчика Выполнено/Не выполнено 2. Обеспечить подключение специалистов Подрядчика к Системе Выполнено/Не выполнено 3. Обеспечить подключение специалистов Подрядчика к СРО Выполнено/Не выполнено Заказчик Подрядчик /Должность/ /Должность/ ____________________ /Ф.И.О/ ___________________ /Ф.И.О/ М.П. М.П. «_____»_______________________202_г. «_____»_______________________202_г - 3.4 Порядок регистрации и сопровождения Заявок Порядок регистрации и сопровождения обращений (заявок) в рамках оказываемых услуг по технической поддержке Системы зависит от типа обращения (заявки): 1. Услуга по решению инцидентов, связанных с работой ППО – тип обращения (заявки) «Инцидент». 2. Услуга по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности – тип обращения (заявки) «Инцидент». 3. Услуга информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы – тип обращения (заявки) «Запрос на обслуживание» (в том числе, консультационный запрос). 4. Услуга адаптационного, конфигурационного и коррекционного сопровождения Системы (в рамках действующих программных модулей и функциональностей) – тип обращения (заявки) «Запрос на изменение». В случае недоступности СРО взаимодействие и информирование Исполнителем о ходе оказания услуги по обращению (заявке), изменению статусов обращений (заявок) осуществляется по согласованию с Заказчиком в соответствии с матрицей взаимодействия, представленной в Приложении 1 к настоящему Регламенту. - 3.4.1 Инцидент На рисунке 2 представлена функциональная схема регистрации и сопровождения обращений (заявок) типа «Инцидент». Рисунок 2 - Функциональная схема регистрации и сопровождения обращений (заявок) типа «Инцидент» 3.4.2 Запрос на обслуживание На рисунке 3 представлена функциональная схема регистрации и сопровождения обращения (заявки) типа «ЗНО». Рисунок 3 - Функциональная схема регистрации и сопровождения обращения (заявки) типа «ЗНО» 3.4.3 Запрос на изменение На рисунке 4 представлена функциональная схема регистрации и сопровождения обращений (заявок) типа «ЗНИ». Рисунок 4 - Функциональная схема регистрации и сопровождения обращений (заявок) типа «ЗНИ» - 3.5 Порядок классификации и приоритизации обращений (заявок) Классификация является начальной стадией процесса оказания технической поддержки, необходимой для идентификации обращения (заявки) и определения соответствующих действий для его обработки. Для проведения первичной классификации необходимо получить от пользователя и зафиксировать в описании обращения (заявки) подробные сведения о сути запроса, в том числе, для Инцидентов зафиксировать сценарий воспроизведения обнаруженной ошибки. Для проведения вторичной классификации необходимо провести анализ и диагностику для определения корневой причины и затронутой Инцидентом функциональной области (инфраструктура, сеть, ППО). В процессе классификации осуществляется первичная диагностика и оценка проблемы, описанной пользователем Системы в обращении (заявке), в части функционирования и/или удобства использования Системы. Корректная классификация позволяет увеличить скорость обработки обращения (заявки) и решения описанной в обращении (заявке) проблемы при минимальном привлечении ресурсов, в частности, за счет использования известных решений для типовых обращений (заявок), которые должны описываться в БЗ СРО. Классификация позволяет произвести первоначальное назначение обращения (заявки) на ответственного сотрудника и выставить приоритет с учетом приоритизации. Приоритизация применяется для определения критичности описанной в обращении (заявке) проблемы для функционирования ППО Системы. Приоритет рассмотрения обращения (заявки) определяется в процессе ее классификации на основании ряда параметров, вводимых при заполнении обращения (заявки). Приоритизация используется для того, чтобы при одновременном наличии нескольких обращений (заявок) в первую очередь рассматривалась обращения (заявки) с наивысшим приоритетом и не позднее установленных для данного приоритета сроков - Изменение приоритета уже зарегистрированного обращения (заявки) используется в случае появления новых обстоятельств, которые ведут к изменению влияния и/или срочности существующего обращения (заявки). При регистрации обращения (заявки) необходимо провести его приоритизацию. В процессе управления обращениями (заявками) каждому обращению (заявке) присваивается приоритет, принимающий одно из значений: Низкий, Средний, Высокий или Критический. В соответствии с приоритетом определяется время, очередность устранения, , ресурсы, привлекаемые для работ по обращению (заявке), а также может определяться порядок/процедура действий при работе с обращением (заявкой). Заказчиком в зависимости от уровня сбоя в работе Системы обращению (заявке) присваивается приоритет с указанием максимального времени реакции и решения в соответствии с требованиями, указанными в Приложении 2 к настоящему Регламенту - 4 Формы обращений (заявок) на оказание услуг по технической поддержке Системы, заполняемые в СРО 4.1. Форма обращения (заявки) на оказание услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы При подаче обращения (заявки) типа «ЗНО» в СРО указывается (Таблица 5): Таблица 5 – Описание атрибутов формы обращения (заявки) на оказание услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 5) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 5) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 5) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 5) Категория обращения: информационно-консультационная поддержка Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 5) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 5) Текст запроса на оказание услуги по информационно-консультационной поддержке сотрудников Заказчика Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 5) - На рисунке 5 приведена форма обращения (заявки) типа «ЗНО» в СРО. Рисунок 5 - Форма обращения (заявки) типа «ЗНО» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы, заполненную в свободной форме. - Термины и сокращения В настоящем регламенте используются следующие термины и сокращения на русском и английском языках: Термины/сокращения Полное наименование/описание БЗ (База знаний) База данных Системы регистрации обращений (заявок), созданная для сбора, хранения и поиска способов решения известных проблем в рамках Системы Жизненный цикл обращения (заявки) Совокупность статусов, по которым проходит обращение (заявка), и правила перехода обращения (заявки) из одного статуса в другой Заказчик ФГБУ «СИЦ Минтранса России» – Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» ЗНИ Запрос на изменение – тип заявки, предполагающий внесение изменений в прикладное программное обеспечение Системы ЗНО Запрос на обслуживание – тип заявки, предполагающий работы по предоставлению консультации, предоставление доступа к Системе или стандартизированные типовые изменения конфигураций Системы Инцидент Тип заявки, классифицируемый как нештатное событие в работе компонентов функциональных задач Системы, которое привело или может привести к нарушению или снижению качества функционирования Системы ИС Информационная система Исполнитель Организация, которая определяется по результатам конкурсных процедур Классификация Анализ и заполнение классификационных полей справочными значениями, определяющими последовательность действий и этапов жизненного цикла заявки, а также порядок рассмотрения заявок Консультация Разъяснения по алгоритму работы, требуемых настроек прикладного программного обеспечения и технологии обработки данных при работе с Системой, предоставление информации Маршрутизация Определение процесса движения обращения (заявки) в Системе управления заявками между уровнями технической поддержки и организационными структурами на уровнях поддержки путем назначения обращения (заявки) в соответствии с его классификацией и выставленным приоритетом - Обращение (заявка) Устное или письменное обращение пользователя АСУ ТК с вопросом, касающимся работоспособности АСУ ТК, по одному из определённых каналов связи: электронная почта, Система регистрации обращений (заявок) Пользователь Инициатор обращения (заявки) или пользователь Системы ППО Прикладное программное обеспечение Предмет обращения Справочник, классифицирующий типовые запросы в Системе регистрации обращений (заявок), характерные для Системы, выбранное значение определяет маршрутизацию обращения (заявки) (группу ответственных сотрудников) Приоритизация Значение, определяющее время, очередность решения обращений (заявок), ресурсы, привлекаемые для решения обращений (заявок), . Приоритет устанавливается в соответствии с масштабом выявленной проблемы, которая привела или может привести к нарушению или снижению качества функционирования Системы Релиз Выпуск версии прикладного программного обеспечения Системы, от разработки до тестирования и планового обновления Системы на продуктивной среде для установки изменений, связанных с развитием/улучшением/оптимизацией Системы Система, АСУ ТК, Информационно-аналитическая система регулирования на транспорте Информационно-аналитическая система, предназначенная для автоматизации и информационно-аналитического обеспечения процессов управления развитием транспортного комплекса Российской Федерации, обеспечения публичности деятельности органов государственного управления транспортным комплексом, а также обеспечения процессов оказания государственных услуг в электронном виде в сфере транспорта СМЭВ Система межведомственного электронного взаимодействия СПО Системное программное обеспечение СРО Система регистрации обращений (заявок) Статус обращения (заявки) Текущее состояние обращения (заявки) в жизненном цикле процесса оказания технической поддержки Системы СУБД Система управления базами данных - 4.2. Форма обращения (заявки) на оказание услуги по решению инцидентов, связанных с работой ППО При подаче обращения (заявки) типа «Инцидент» в СРО указывается (Таблица 6): Таблица 6 – Описание атрибутов формы обращения (заявки) на оказание услуги по решению инцидентов, связанных с работой ППО Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 6) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 6) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 6,) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 6) Категория обращения (заявки): инцидент Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 6) Приоритет изменения Время - одно из значений: Низкий, Средний, Высокий или Критический. Определяет, очередность решения обращения (заявки), ресурсы, привлекаемые для решения обращения (заявки), порядок/процедура действий при решении обращения (заявки) – поле СРО «Приоритет» (см. рисунок 6,) - Тип изменения Справочник, классифицирующий типовые запросы характерные для Системы – поле СРО «Предмет обращения» (см. рисунок 6) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 6) Полное описание инцидента, включая скриншоты и описание шагов, приведших к неисправности Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 6) Однократность/неоднократность Круг пользователей или компьютеров, затронутых данным инцидентом Действия, предпринятые для самостоятельного решения инцидента (при наличии) Версии используемого программного обеспечения на клиентской рабочей станции, где воспроизводится ошибка (операционная система, прикладное программное обеспечение) Дополнительная информация - На рисунке 6 приведена форма обращения (заявки) типа «Инцидент» в СРО. Рисунок 6 - Форма обращения (заявки) типа «Инцидент» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуги по решению инцидентов, связанных с работой ППО, заполненную в свободной форме - 4.3. Форма обращения (заявки) на оказание услуг по адаптационному конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) При подаче обращения (заявки) типа «ЗНИ» в СРО указывается (Таблица 7): Таблица 7 – Описание атрибутов формы обращения (заявки) на оказание услуг по адаптационному, конфигурационному и коррекционному сопровождению Системы Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 10) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 9) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 10) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 10) Категория обращения (заявки): запрос на изменение Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 7) Приоритет изменения Время, очередность решения обращения (заявки), ресурсы, привлекаемые для решения обращения (заявки), порядок/процедура действий при решении обращения (заявки) – поле СРО «Приоритет» (см. рисунок 7) Тип изменения Справочник, классифицирующий типовые запросы характерные для Системы – поле СРО «Предмет обращения» (см. рисунок 7) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 7) Текст запроса на оказание услуги по адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 7) - На рисунке 7 приведена форма обращения (заявки) типа «ЗНИ» в СРО. Рисунок 7 - Форма обращения (заявки) типа «ЗНИ» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуг по адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей), заполненную в свободной форме - 4.4. Форма обращения (заявки) на оказание услуги по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности При подаче обращения (заявки) типа «Инцидент» в СРО указывается (Таблица 8): Таблица 8 – Описание атрибутов формы обращения (заявки) на оказание услуг по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности

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

ОПРЕДЕЛЕНИЯ, ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ - Автоматизированная система (АС) Система, состоящая из комплекса средств автоматизации, реализующего информационную технологию выполнения установленных функций, и персонала, обеспечивающего его функционирование (ГОСТ Р 59853-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения») АРМ Автоматизированное рабочее место АСУ ТК, Система Информационно-аналитическая система регулирования на транспорте АТС Автоматическая телефонная станция БД База данных ГИС Государственная информационная система ГОСТ Государственный стандарт ГЦОД СИЦ Минтранса России, ГЦОД Головной центр обработки данных ФГБУ «СИЦ Минтранса России» Дашборд Интерактивная аналитическая панель, графический интерфейс. ЕИС Единая информационная система в сфере закупок ЕСИА Единая система идентификации и аутентификации Заказчик Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» КИИ Критическая информационная инфраструктура Кластер Кла?стер (англ. cluster) – объединение нескольких однородных элементов, которое может рассматриваться как самостоятельная единица, обладающая определёнными свойствами Компонент Часть АС, выделенная по определенному признаку или совокупности признаков и рассматриваемая как единое целое (ГОСТ Р 59853-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения») Контракт Контракт на выполнение работ по развитию и оказанию услуг по технической поддержке Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК в 2026 году, заключаемый по результатам проведения конкурентной процедуры закупки в соответствии с требованиями Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» - - Значение характеристики не может изменяться участником закупки

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

ФГБУ «СИЦ Минтранса России» Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации», Заказчик Федеральный закон № 44-ФЗ Федеральный закон от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» ФЗ Функциональная задача ФЗ «Реестр объектов» Функциональная задача «Формирование и ведение единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации» ФСБ России Федеральная служба безопасности Российской Федерации ФСТЭК России Федеральная служба по техническому и экспортному контролю ЧС Чрезвычайная ситуация ЭВМ Электронно-вычислительная машина API От англ. Application Programming Interface – интерфейс прикладного программирования – совокупность инструментов и функций в виде интерфейса для взаимодействия с программой CSS От англ. Cascading Style Sheets — каскадные таблицы стилей FPS От англ. frame per second - количество кадров в секунду HTML От англ. HyperText Markup Language - стандартный язык разметки документов, создающий основу и структуру всех веб-страниц JSON От англ. JavaScript Object Notation – текстовый формат обмена данными, основанный на JavaScript WebAssembly (Wasm) Открытый стандарт, представляющий собой низкоуровневый бинарный формат инструкций, который позволяет выполнять код, написанный на языках C++, Rust или Go, в браузерах с производительностью, близкой к нативной

1. ОБЩИЕ СВЕДЕНИЯ - – ГОСТ Р 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.7. Сроки начала и окончания работ Начало работ: с даты заключения Контракта. Окончание работ: не позднее 15.12.2026. Работы выполняются в соответствии с этапами. Сроки выполнения этапов работ по развитию и технической поддержке Модуля СЦ определяются Календарным планом. Календарный план, приведен в разделе 5 настоящего ТЗ

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

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

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

1.1. Наименование Системы Полное наименование системы: Информационно-аналитическая система регулирования на транспорте. Условное обозначение системы: АСУ ТК. Полное наименование модуля: Модуль сбора, ведения и анализа информации о нештатных ситуациях на транспорте. Условное обозначение модуля: Модуль СЦ. Модуль СЦ создан в рамках контракта от 05.08.2024 № ОК/24_04 на выполнение работ по развитию АСУ ТК в части создания модуля «Сбора, ведения и анализа информации о нештатных ситуациях на транспорте». Развитие Модуля СЦ осуществлено в рамках контракта от 19.05.2025 № ОК/25_09 на выполнение работ по развитию Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК

1.2. Шифр темы или номер контракта Присваивается Заказчиком по результатам организации закупочных процедур. 1.2.1. Предмет контракта Выполнение работ по развитию Модуля СЦ. Код по ОКПД2: 62.01.11.000 – услуги по проектированию и разработке информационных технологий для прикладных задач и тестированию программного обеспечения. Оказание услуг по технической поддержке Модуля СЦ. Код по ОКПД2: 62.02.30.000 – услуги по технической поддержке информационных технологий. Выполнение работ по развитию Модуля СЦ предусмотрено с учетом ключевых результатов (ОКР) Ведомственной программы цифровой трансформации Минтранса России на 2026-2028 (далее - ВПЦТ Минтранса России) в составе мероприятия № 103.002 «АСУ ТК» ИТ расхода 103.26.000005 «Развитие Информационно-аналитической системы регулирования на транспорте (АСУ ТК)»: · «Обеспечено информационное взаимодействие с Минобороны о происшествиях на транспортных объектах»; · «Обеспечена автоматизация формирования отчетов о нештатных ситуациях на транспорте, в том числе по данным внешних систем». Выполнение работ по технической поддержке АСУ ТК предусмотрено ВПЦТ Минтранса России в составе мероприятия № 103.002 «АСУ ТК» ИТ расхода 103.26.000021 «Эксплуатация Информационно-аналитической системы регулирования на транспорте (АСУ ТК)»

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

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

1.5. Основания для выполнения работ Работы осуществляются на основании следующих документов: – постановление Правительства Российской Федерации от 30.12.2003 № 794 «О единой государственной системе предупреждения и ликвидации чрезвычайных ситуаций»; – постановление Правительства Российской Федерации от 08.11.2013 № 1007 «О силах и средствах единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций»; – распоряжение Правительства Российской Федерации от 27.11.2021 № 3363-р «О Транспортной стратегии Российской Федерации до 2030 года с прогнозом на период до 2035 года»; – Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 26.08.2025 №ЕФ-3; – Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 27.11.2025 №ЕФ-23;

– Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 19.02.2026 №ЕФ-1; – План мероприятий по профилактике случаев непроизводственного травматизма граждан на железнодорожном транспорте, являющийся приложением к постановлению коллегии Министерства транспорта Российской Федерации от 11.03.2026 № 2

1.6. Перечень документов, требования которых должны быть учтены при выполнении работ – Федеральный закон Российской Федерации от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации»; – Федеральный закон Российской Федерации от 27.07.2006 № 152-ФЗ «О персональных данных»; – Федеральный закон Российской Федерации от 06.04.2011 № 63-ФЗ «Об электронной подписи»; – Федеральный закон Российской Федерации от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации»; – Указ Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации»; – Указ Президента Российской Федерации от 01.05.2022 № 250 «О дополнительных мерах по обеспечению информационной безопасности Российской Федерации»; – Указ Президента Российской Федерации от 31.03.2010 № 403 «О создании комплексной системы обеспечения безопасности населения на транспорте»; – постановление Правительства Российской Федерации от 30.07.2004 № 395 «Об утверждении Положения о Министерстве транспорта Российской Федерации»; – постановление Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации»; – постановление Правительства Российской Федерации от 16.11.2015 № 1236 «Об установлении запрета на допуск программного обеспечения, происходящего из иностранных государств, для целей осуществления закупок для обеспечения государственных и муниципальных нужд»; – постановление Правительства Российской Федерации от 23.12.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 Федерального закона «Об электронной подписи»;

– постановление Правительства Российской Федерации от 08.06.2011 № 451 «Об инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг и исполнения государственных и муниципальных функций в электронной форме»; – постановление Правительства Российской Федерации от 30.01.2013 № 62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин»; – приказ ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации»; – приказ ФСТЭК России от 11.04.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений»; – приказ ФСБ России от 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 «Национальный стандарт Российской Федерации. Интеллектуальная собственность. Патентные исследования. Содержание и порядок проведения»;

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

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

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

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

3. ХАРАКТЕРИСТИКА ОБЪЕКТА АВТОМАТИЗАЦИИ - 3.1. Описание объекта автоматизации АСУ ТК Объектом автоматизации являются процессы основной и обеспечивающей деятельности, направленные на управление транспортным комплексом, в том числе, процессы информационного взаимодействия с другими организациями и субъектами транспортного комплекса. АСУ ТК относится к государственным информационным системам, а также к информационным системам персональных данных и значимым объектам критической информационной инфраструктуры Российской Федерации. АСУ ТК соответствует требованиям, предъявляемым к: – ГИС второго класса защищенности в соответствии с приказом ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах»; – ИС персональных данных при обеспечении третьего уровня защищенности персональных данных в соответствии с требованиями постановления Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»; – значимым объектам КИИ Российской Федерации второй категории значимости с постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении Правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений». Модуль СЦ является подсистемой АСУ ТК. Перечень платформенных решений и функциональных задач АСУ ТК представлен в Таблице 1 - - Значение характеристики не может изменяться участником закупки

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

8 Подсистема проектного архива АСУ ТК Подсистема проектного архива АСУ ТК предназначена для автоматизации деловых процессов должностных лиц Министерства транспорта Российской Федерации, подведомственных агентств и службы, в том числе, и процессов информационного взаимодействия внутреннего и внешнего характера 9 ФЗ «Реестр объектов» Функциональная задача предназначена для формирования и ведения единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации 10 ФЗ «СТП» Функциональная задача предназначена для организации информационно-аналитической поддержки процессов территориального планирования Российской Федерации в области федерального транспорта 11 ФЗ «МРТБ ПП» Функциональная задача предназначена для формирования и ведения межрегионального транспортного баланса пассажирских перевозок в дальнем (межрегиональном) сообщении 12 ФЗ «МДД» Функциональная задача предназначена для осуществления мониторинга дорожного движения 13 ФЗ «ТПР» Функциональная задача предназначена для формирования и ведения транспортного паспорта региона 14 ФЗ «Данные по грузообороту» Функциональная задача предназначена для обеспечения подсистем и пользователей АСУ ТК данными по грузообороту между Российской Федерацией и зарубежными странами 15 ФЗ «МЖТ» Функциональная задача предназначена для осуществления мониторинга железнодорожного транспорта 16 ФЗ «МГМП» Функциональная задача предназначена для осуществления мониторинга грузопотоков в морских портах с целью формирования единой цифровой среды мониторинга и планирования перевозок в/из портов Дальнего Востока

17 Модуль ГЭТ Модуль предназначен для получения, хранения данных инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по отдельно взятому предприятию-перевозчику. Формирования отчетов об инвентаризации с детальными данными по каждому разделу инвентаризации с маршрутизацией в муниципалитет / регион / Минтранс. Содержит агрегированные данные инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по всем перевозчикам, относящихся к данному муниципалитету. Формирует сводный отчет по муниципалитету по каждому разделу инвентаризации с маршрутизацией в регион / Минтранс. Формирует агрегированные данные инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по всем перевозчикам, относящиеся к данному региону и по всем муниципалитетам, относящимся к данному региону. Аналитические и статистические данные о состоянии ГЭТ региона. Содержит данные о видах транспорта, цифровых транспортных сервисах и платежных инструментах Региона. Формирует сводный отчет по каждому разделу инвентаризации с маршрутизацией в Минтранс. Формирует агрегированную статистику и аналитику по всем регионам страны в разрезе транспортных средств, маршрутов, пассажиропотоков, инфраструктуры ГЭТ. Данные о рейтинге регионов и перевозчиков на основании выбранных параметров, документооборот с участниками Системы: получение подписанных печатных форм, их утверждение, возврат на доработку. 18 Модуль iМинтранс Модуль создан для отчета по ключевым показателям транспортного комплекса России (Отраслевые и статистические показатели, исполнение бюджета, исполнение поручений, аналитика СМИ, происшествия по видам транспорта). 19 Модуль СЦ Модуль СЦ предназначен для оперативного мониторинга нештатных ситуаций транспортной отрасли, оповещения заинтересованных лиц и структур и предоставления данных о нештатных ситуациях

АСУ ТК осуществляет идентификацию и авторизацию посредством Единой системы идентификации и аутентификации (ЕСИА). Информационный обмен с внешними информационными системами осуществляется посредством СМЭВ 3 и СМЭВ 4. АСУ ТК развернута на вычислительных мощностях ГЦОД СИЦ Минтранса России

3.2. Описание и текущее состояние объекта автоматизации Модуля СЦ Объектом автоматизации является процесс организации мониторинга информации о НС и ЧС на транспорте. Предметом деятельности Учреждения являются следующие функции: – информационное обеспечение в области транспортной безопасности, защиты населения и территорий от чрезвычайных ситуаций природного и техногенного характера в транспортном комплексе; – подготовка справочных материалов при угрозе возникновения и возникновении чрезвычайных ситуаций и иных происшествий в транспортном комплексе; – взаимодействие и обмен оперативной информацией с органами управления Единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций; – организация оперативного мониторинга обстановки на объектах транспорта при угрозе и возникновении чрезвычайных ситуаций и иных происшествий. Перечень компонентов Модуля СЦ и выполняемые ими функции представлены в Таблице 2

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

3 Информирование – ведение справочника способов оповещения (веб-интерфейс, мессенджер); – формирование сценария выполнения оповещения (настройка условий, способа, параметров оповещения); – выполнение оповещений пользователей 4 Отчетность – формирование отчета и справки о событиях; – фильтрация событий для выгрузки в справку о событиях или в отчет о событиях 5 Администрирование – ведение ролей пользователей; – ведение учетных данных пользователей; – ведение справочника организаций; – ведение справочника групп системы мгновенного обмена сообщениями; – выполнение исходящего звонка на контактный телефонный номер организации; – формирование матрицы эскалации событий Архитектура Модуля СЦ представлена на рисунке 1. Рисунок 1. Архитектура Модуля СЦ

3.3. Состав используемого ПО Модуля СЦ Программная архитектура Модуля СЦ разработана как трехуровневая клиент-серверная архитектура. Архитектура включает в себя следующие уровни: • уровень представления – презентационный уровень, обеспечивающий взаимодействие с пользователя с клиентскими приложениями с использованием веб-браузера («тонкий» клиент); • уровень приложений – реализован в виде сервисов, обеспечивает обработку запросов, поступающих от клиентских приложений, формирование ответов на запрос в доступном пользователю виде (формирование пользовательских интерфейсов); • уровень хранения данных – реализуется как сервер БД и обеспечивает хранение и целостность хранимых данных, создание резервных копий, ведение журнала транзакций, восстановление данных после сбоев. Программная архитектура Модуля СЦ включает в себя сервисы и интерфейсы, указанные в Таблице 3. Таблица 3. Программная архитектура Модуля СЦ Программный сервис/интерфейс Технологии реализации Уровень представления Интерфейс пользователя и администратора (front-end) Javascript Уровень приложений Сервис (GateWay) Kotlin Сервис геокодирования (geocoding-service) Kotlin Сервис уведомлений (notifiсation-service) Kotlin Сервис работы с файлами (file-service) Kotlin Сервис отчетности (report-service) Kotlin Сервис управления событиями (event-service) Kotlin Сервис информирования через мессенджер (messenger-notifier) Python Сервис внешних интеграций (integration-service) Сбор информации из внешних систем и сервисов Брокер сообщений Kafka Уровень хранения данных Файловое хранилище MinIO S3 СУБД Postgres Pro Enterprise

3.4. Информационное взаимодействие программных сервисов и интерфейсов Модуля СЦ Объект автоматизации функционирует в распределенной информационной среде. Обмен данными осуществляется по защищенным каналам связи (в том числе ведомственным сетям передачи данных). Источники информации включают: · внешние автоматизированные системы (органов государственной власти); · внутренние базы данных (реестры объектов транспортной инфраструктуры, паспорта регионов и пр.); · оперативная информация от персонала, поступающая через автоматизированные рабочие места (АРМ) и мобильные устройства. 3.4.1. Взаимодействие Модуля СЦ со смежными подсистемами АСУ ТК Модуль СЦ входит в состав АСУ ТК и взаимодействует со следующими ее функциональными задачами и подсистемами: · Функциональной задачей «Формирование и ведение единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации» (ФЗ «Реестр объектов»); · Геоинформационной подсистемой АСУ ТК (П-ГИС); · Подсистемой ведения нормативно-справочной информации и метаданных (П-НСИ); · Подсистемой сбора данных и централизованное хранилище данных (П-СД); · Подсистемой информационного взаимодействия (П-ИВ). 3.4.2. Взаимодействие с внешними информационными системами Список внешних информационных систем, с которыми осуществляется взаимодействие Модуля СЦ: · ЕСИА; · мессенджер; · Яндекс Геокодер; · Информационная система «Централизованная система сбора информации систем-112»; · ПВК «Поиск-Море», АИС РПТ; · облачная АТС

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

4. ТРЕБОВАНИЯ К МОДУЛЮ СЦ - Таблица 6. Категории обращений и заявок Категория Примеры Запрос на обслуживание Подготовка SQL запроса к СУБД для решения прикладной задачи и д.р. – запрос на любое действие, не являющееся запросом информации и несовершенный на основе происшествия, прямо или косвенно влияющего на работу Модуля СЦ Консультация «Где взять / куда обратиться...?», «Как сделать / выполнить…», «Как это работает…?» - запрос, имеющий своей целью получение информационной поддержки Инцидент Разбор ошибок/сбоев и подготовка материалов (корректировочных релизов, инструкций) для Заказчика для устранения ошибок/сбоев, которые приводят к частичному и полному нарушению работоспособности всех или отдельных функций ППО. Подготовка изменения и материалов, необходимых для проведения аварийно-восстановительных работ для возобновления работоспособности Модуля СЦ ЗНИ Подготовка изменений, связанных с изменением, улучшением/оптимизацией Модуля СЦ и выводом новой модифицированной функциональности в штатном режиме. Подготовка изменений, связанных с модификацией существующих и/или реализация новых интеграционных механизмов для получения/обработки данных внешних систем. Подготовка изменений графического интерфейса по требованиям Заказчика. Перечень статусов обращений (заявок) приведен в пункте 3.3. Регламента оказания Услуг. Назначение обращению (заявке) статуса «Закрыто» осуществляется Заказчиком только после получения от инициатора обращения (заявки) подтверждения о его исполнении или нахождения обращения (заявки) в статусе «Выполнено» и отсутствия повторных вопросов/запросов по данному обращению (заявки) в течение 5 рабочих дней. Категории и статусы обращений (заявок) могут быть скорректированы в процессе оказания услуг исключительно по согласованию с Заказчиком - - Значение характеристики не может изменяться участником закупки

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

4.3.6.2. Требования к услугам информационно-консультационной поддержки работников Заказчика и пользователей Модуля СЦ Услуги информационно-консультационной поддержки сотрудников Заказчика включают: – обработку обращений и заявок, поступивших от сотрудников Заказчика; – консультирование сотрудников Заказчика и пользователей Модуля СЦ; – актуализацию документации, и других материалов по работе с Модулем СЦ при необходимости. – консультирование и разработку рекомендаций по настройке Модуля СЦ (без изменения программного кода), включая изменение настроек функционирования; – консультации по вопросам использования, настройки и возможностям Модуля СЦ; – консультации по проведению превентивных мер для недопущения аварийных ситуаций в Модуле СЦ; – консультации по предварительной диагностике и локализации возникшей неисправности Модуля СЦ; – консультации по вопросам обеспечения информационной безопасности Модуля СЦ и настройки функций, обеспечивающих корректную работу программного обеспечения для совершения юридически значимых действий в Модуле СЦ; – другие вопросы, связанные с работой Модуля СЦ. 4.3.6.2.1. Требования к порядку оказания услуг информационно-консультационной поддержки работников Заказчика и пользователей Модуля СЦ Подрядчик выполняет консультирование сотрудников Заказчика и пользователей Модуля СЦ. Консультация может быть предоставлена по согласованным с представителем Заказчика каналам коммуникации с регистрацией результата консультации в СРО Подрядчиком. Детальный порядок оказания консультационных услуг определен в Регламенте оказания Услуг

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

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

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

4.3.6.4.1. Требования к проведению изменений Основанием для внесения изменений является запрос от Заказчика. Все активности по внесению изменений должны быть согласованы с Заказчиком, а действия Подрядчика при оказании данной услуги должны быть зафиксированы. В рамках данного Технического задания изменениями считаются локальные доработки функционала Модуля СЦ, которые не должны приводить к необходимости выполнения дополнительных аттестационных испытаний или переаттестации АСУ ТК в соответствии с п. 33 приказа от 29.04.2021 № 77 «Об утверждении Порядка организации и проведения работ по аттестации объектов информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну». При необходимости внесения изменений в Модуль СЦ, не связанных с критичным инцидентом, существенно нарушающим работоспособность Модуля СЦ, Заказчик направляет Подрядчику обращение (заявку), в котором излагает суть изменения, которое требуется внести в Модуль СЦ. Исполнитель, в течение 3 (трех) рабочих дней с момента поступления соответствующего обращения (заявки), оценивает техническую возможность реализации запрашиваемого изменения и варианты реализации. По итогу проведения оценки Подрядчик направляет Заказчику заключение о возможности реализации данного изменения с описанием возможных вариантов реализации и согласует с Заказчиком проведение данного изменения

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

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

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

4.4.7.1. Требования к инструментам разработки и процессу контроля версий программного обеспечения 4.4.7.1.1. Система контроля версий Для управления исходным кодом должна использоваться система контроля версий кода, развернутая в инфраструктуре Заказчика. 4.4.7.1.2. Правила именования веток Имя ветки должно соответствовать следующему формату: / / Категории веток: ? feature/ — разработка новой функциональности, а также рефакторинг или удаление существующей; ? fix/ — исправление ошибок; ? hotfix/ — срочные исправления, применяемые в обход стандартного процесса разработки; ? test/ — для проведения экспериментов, не влияющих на основную разработку. Идентификатор задачи: после категории указывается ссылка на задачу (issue) в системе контроля версий кода. Описание: добавляется краткое описание решаемой задачи в формате kebab-case (слова разделяются дефисами, например, add-user-auth). Примеры именования веток: ? feature/#123/add-payment-integration; ? fix/#45/correct-calculation-logic; ? hotfix/#67/urgent-database-connection-patch. 4.4.7.1.3. Правила именования коммитов Сообщение коммита должно соответствовать соглашению Conventional Commits и состоять из категории и описания: : ? fix — исправление ошибки. Примеры сообщений коммитов: ? feat: добавление формы регистрации пользователя; ? fix: исправление ошибки валидации email-адреса; ? refactor: оптимизация алгоритма сортировки данных; ? chore: обновление версий в файле dependencies. 4.4.7.1.4. Модель ветвления В процессе разработки используются следующие основные ветви: ? main / master — стабильная ветка, содержит только код, прошедший полное тестирование и развернутый в продуктивных контурах; ? dev — ветка для интеграции завершенных задач, предназначенная для сборки и тестирования в тестовых средах. Попадание кода в main осуществляется только через Merge Request (MR) из dev

4.5.5. Требования к информационной безопасности Работы по защите информации/информационной безопасности, не включенные в состав настоящего раздела, требуемые в соответствии с требованиями постановления Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации», а также нормативно правовых актов в области защиты персональных данных и обеспечения безопасности объектов критической информационной инфраструктуры, будут проведены в рамках исполнения отдельного контракта, заключенного по результатам отдельной закупочной процедуры (не является частью данного ТЗ), включающего: – определение актуальных угроз безопасности информации и актуализация модели угроз безопасности информации (при необходимости); – выполнение требований о согласовании технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России в установленном порядке; – выполнение требований по устранению Подрядчиком замечаний и недостатков, в случае их выявления при согласовании Заказчиком технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России; – выполнение требований к классу защищенности ГИС, уровню защищенности персональных данных и категории значимости объекта КИИ РФ, установленных для Головного центра обработки данных ФГБУ «СИЦ Минтранса России» (далее – ГЦОД);

– определение перечня объектов защиты информационной системы; – описание (актуализированных) требований к системе защиты информации, а также к мерам защиты информации информационной системы в зависимости от установленных классов защищенности, уровня защищенности персональных данных и категории значимости объектов КИИ РФ (приказы ФСТЭК России № 21, 117, 239); – выполнение требований к мерам по защите ГИС от атак, направленных на отказ в обслуживании, в соответствии с пунктами 30, 34, 59, 63 Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений, утвержденных приказом ФСТЭК России от 11.04.2025 № 117; – описание (актуализированных) требований по защите информации, подлежащих реализации в информационно телекоммуникационной инфраструктуре ГЦОД; – выполнение требований о применении сертифицированных средств защиты информации, включая их классы защиты и уровни доверия; – выполнение требований о запрете использования с 01.01.2025 органами (организациями) средств защиты информации странами происхождения, которых являются иностранные государства в соответствии с пунктом 6 Указа Президента Российской Федерации от 01.05.2022 № 250; – выполнение требований по обеспечению непрерывного взаимодействия с ГосСОПКА в установленном порядке;

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

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

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

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

4.3.6.4. Требования к услугам адаптационного, конфигурационного и коррекционного сопровождения и доработки Модуля СЦ (в рамках действующих программных модулей и функциональностей) Услуги адаптационного, конфигурационного и коррекционного сопровождения и доработки Модуля СЦ включают: – управление изменениями и адаптация функций Модуля СЦ; – изменение настроек функционирования Модуля СЦ; – внесение изменений и/или модификаций Модуля СЦ (в рамках действующих программных модулей и функциональностей), направленных на улучшение их работоспособности и функциональных возможностей; – подготовка и передача Заказчику SQL запросов в СУБД для получения агрегированной информации из Модуля СЦ, которую невозможно получить с использованием графического пользовательского интерфейса; – адаптация модулей интеграций со смежными информационными системами

4.3.6.4.2. Требования к изменению настроек функционирования Изменение настроек функционирования может проводиться в рамках допустимых пределов изменения функционирования, заложенных в архитектуру Модуля СЦ. Изменение настроек функционирования включает в себя изменение данных и справочников, изменение форм документов, формируемых Модулем СЦ, изменение и настройку форматов и версий передачи данных в смежные системы. Доработка программного кода Модуля СЦ может допускаться (в случае необходимости) при выполнении работ по адаптации функций Модуля СЦ в части изменения формата передачи данных в смежные информационные системы при условии соблюдения требований пункта 29.3 приказа ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации»

4.3.6.5. Требования к услугам по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности По запросу Заказчика Подрядчик должен провести работу по приведению ППО в соответствие с требованиями по обеспечению информационной безопасности. Критичность уязвимости оценивается в соответствии в соответствии с Методическим документом ФСТЭК России «Методика оценки уровня критичности уязвимостей программных, программно-аппаратных средств» (утвержден ФСТЭК России 30.06.2025), а также с учетом ГОСТ 56545-2015 и международными стандартами (CVSS 3.0 и выше), и задает необходимый срок устранения. В процессе проведения Заказчиком обследования Модуля СЦ и выявления уязвимостей в ППО, связанных с исходным кодом Модуля СЦ и/или используемыми компонентами (библиотеками), Заказчик направляет Подрядчику обращение (заявку) на устранение, с указанием критичности и срочности принятия мер по устранению в СРО.

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

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

4.4.7.1.5. Требования к используемым зависимостям (библиотекам) Все внешние зависимости проекта должны быть зафиксированы с указанием точных версий. Для контроля версий зависимостей в репозиторий обязательно должны быть включены следующие файлы: · Для JavaScript: package-lock.json или yarn.lock; · Для Python: requirements.txt (с зафиксированными версиями) или Pipfile.lock; · Для Go: go.mod и go.sum; Загрузка всех зависимостей должна производиться исключительно через внутренний прокси-репозиторий Заказчика, настроенный в соответствующем системе менеджере пакетов. Запрещается: · Использование плавающих версий (например, ^1.2.3, ~4.5.0, latest); · Использование библиотек, содержащих критические уязвимости, в том числе зарегистрированные в реестре CVE (Common Vulnerabilities and Exposures). 4.4.7.1.6. Требования к процессу непрерывной интеграции (CI) Сборка программного обеспечения, включая этапы компиляции, тестирования и анализа кода, должна выполняться исключительно в инфраструктуре непрерывной интеграции Заказчика. 4.4.7.1.7. Требования к хранению артефактов сборки Все артефакты сборки (результирующие пакеты, Docker-образы и т.д.) подлежат обязательному хранению в предназначенной для этого инфраструктуре Заказчика (артефакторий). Запрещается размещение финальных артефактов сборки на сторонних ресурсах

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

4.5. Общие технические требования 4.5.1. Требования к численности и квалификации персонала и пользователей Модуля СЦ Программное обеспечение Модуля СЦ не должно требовать изменения штатной численности персонала Заказчика. Программное обеспечение Модуля СЦ не должно требовать наличия у пользователей дополнительной квалификации в сфере информационных технологий, кроме базовых знаний в обращении с персональным компьютером, базовых навыков работы в интернет-обозревателях и знаний о Модуле СЦ в объеме документов Руководство пользователя, Руководство администратора

– выполнение требований по обеспечению в автоматизированном режиме с Национальной системой противодействия DDoS-атакам (НСПА) Центра мониторинга и управления сетью связи общего пользования ФГУП «ГРЧЦ» в рамках реализации мер по защите ГИС от атак, направленных на отказ в обслуживании; – детализированные требования к составу и содержанию работ по аттестации, а также к их результатам в соответствии с пунктами 13, 15 и 16 требований приказа ФСТЭК России от 29.04.2021 № 77 «Об утверждении Порядка организации и проведения работ по аттестации объектов информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну»

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

Подрядчик должен обеспечить реализацию и проведение внутренних проверок мер по разработке безопасного ПО, приведенных в Руководстве. Подрядчик должен провести анализ угроз безопасности информации программного обеспечения в соответствии с ГОСТ 58412-2019 «Защита информации. Разработка безопасного программного обеспечения. Угрозы безопасности информации при разработке программного обеспечения». Подрядчик должен провести испытания по выявлению уязвимостей в программном обеспечении Системы: · проведение статического анализа исходного кода программы; · проведение динамического анализа исходного кода программы; · проведение композитного анализа исходного кода и образов программы; · проведение фаззинг-тестирования программы, направленного на выявление в ней уязвимостей. Испытания по выявлению уязвимостей в программном обеспечении Системы должны быть проведены в рамках: · предварительных испытаний; · опытной эксплуатации; · приемочных испытаний

4.5.11. Требования к показателям назначения 4.5.11.1. Требования к показателям назначения мероприятий по развитию Модуля СЦ В рамках выполнения работ по развитию Модуля СЦ, предусмотренных ТЗ, показатель назначения «Количество пользователей» должен соответствовать значениям, приведенным в данном разделе. Пояснения по показателям, связанным с количеством пользователей, приведены в Таблице 8. Таблица 8. Определения показателей, связанных с количеством пользователей в Модуле СЦ № Показатель Определение Расчетное количество пользователей Количество пользователей, работу которых должен обеспечить Модуль СЦ к моменту сдачи работ по Контракту с учетом достижения всех показателей назначения Расчетное количество одновременно работающих пользователей Количество одновременно работающих пользователей, работу которых должен обеспечивать Модуль СЦ к моменту сдачи работ по Контракту с учетом достижения всех показателей назначения Значения показателей количества пользователей, достижение которых необходимо обеспечить, представлено в Таблице 9

Таблица 9. Значения показателей количества пользователей № Показатель Значение 1. Расчетное количество пользователей 1 000 2. Расчетное среднее количество одновременно работающих пользователей 200 Развитие Модуля СЦ должно быть направлено на достижение следующего эффекта (показателя), подставленного в мероприятии 103.002 «Информационно-аналитическая система регулирования на транспорте (АСУ ТК)» ВПЦТ Минтранса России: Выполнение работ по развитию Модуля СЦ предусмотрено мероприятием по развитию АСУ ТК, приведенном в ВПЦТ Минтранса России на 2026-2028 гг: № 103.002 «АСУ ТК» в составе ИТ расхода 103.26.000005 «Развитие предусматривает реализацию ОКР и эффектов, приведенных в Таблице 10. Таблица 10. ОКР и эффекты, приведенные в ВПЦТ Минтранса России на 2026 г. № ОКР Дата ОКР Эффекты 1 Обеспечено информационное взаимодействие с Минобороны России о происшествиях на транспортных объектах 25.12.2026 Сокращено время сбора и передачи сведений для Минобороны России о ЧС и НС на транспорте с 120 до 10 минут 2 Обеспечена автоматизация формирования отчетов о нештатных ситуациях на транспорте, в том числе по данным внешних систем 25.12.2026 Сокращено время на подготовку отчетов о нештатных ситуациях на транспорте с 20 до 5 минут Реализация остальных ОКР не является предметом данного ТЗ и проводится в рамках отдельного технического задания.

4.5.11.2. Требования к показателям назначения мероприятий по эксплуатации Модуля СЦ. Работы по эксплуатации Модуля СЦ не должны обеспечивать режимы функционирования Модуля СЦ, приведенные в разделе 4.5.2 данного ТЗ

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

4.4. Требования к видам обеспечения 4.4.1. Требования к лингвистическому обеспечению Документация на Модуль СЦ должна разрабатываться на русском языке. Взаимодействие пользователей с Модулем СЦ посредством графического интерфейса должно происходить на русском языке за исключением сообщений, зависящих от настроек системного программного обеспечения, установленного на рабочих местах пользователей. При разработке программных решений Модуля СЦ должно быть предусмотрено использование языков программирования высокого уровня, приведенных в Таблице 7. Таблица 7. Языки и средства разработки, специального программного обеспечения Модуля СЦ Категория Наименование Назначение Языки программирования Kotlin Разработка серверной логики и сервисов (backend) JavaScript / TypeScript Разработка клиентской части (frontend) Python Разработка скриптов интеграции, обработки данных и автоматизации Фреймворки и библиотеки Vue.JS Разработка пользовательских интерфейсов (веб-интерфейсы компонентов визуализации и отчетности) React Разработка пользовательских интерфейсов (при необходимости создания сложных интерактивных компонентов) Решения по лингвистическому обеспечению, включая перечень используемых языков программирования, должны быть согласованы с Заказчиком на этапе технического проектирования

4.4.2. Требования к математическому обеспечению Требования к математическому обеспечению не предъявляются. 4.4.3. Требования к метрологическому обеспечению Требования к метрологическому обеспечению не предъявляются. 4.4.4. Требования к организационному обеспечению Требования к организационному обеспечению не предъявляются. 4.4.5. Требования к методическому обеспечению Задачи методического обеспечения Модуля СЦ должны быть обеспечены за счет использования технологических и методических документов касающихся вопросов функционирования транспортного комплекса и разработки и эксплуатации ПО. 4.4.6. Требования к информационному обеспечению Состав, структура и способы организации информационного обеспечения в Модуле СЦ должны быть определены на этапе технического проектирования. Факты информационного обмена с внешними системами должны фиксироваться в соответствующем журнале

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

В аварийном режиме осуществляется поиск неисправностей и проведение работ по их устранению. Перевод в аварийный режим должен осуществляться при возникновении сбоев, аварий и прочих незапланированных воздействий, сразу после наступления одной или нескольких аварийных ситуаций, с последующим возвратом в штатный режим функционирования сразу после окончания восстановительных работ. ПО Модуля СЦ должно обладать надежностью, обеспечивающей работу пользователей в произвольном режиме и оперативное восстановление работоспособности при сбоях. В целях обеспечения надежного функционирования ПО должно предусматривать: – сохранение целостности данных при нештатном завершении работы компонентов Модуля СЦ; – сохранение работоспособности программного обеспечения при некорректных действиях пользователя; – резервное копирование базы данных Модуля СЦ. – время восстановления работоспособности Модуля СЦ после отказа не более 4 часов. – отказоустойчивость на уровне 99% при единовременной количестве не менее 200 пользовательских сессий в Модуле СЦ. Указанные характеристики приведены без учета характеристик надежности инфраструктуры и времени передачи информации по каналам связи. При возникновении сбоев в аппаратном обеспечении, включая аварийное отключение электропитания, Модуль СЦ должен автоматически восстанавливать свою работоспособность (не требовать перенастройки) после устранения сбоев и корректного перезапуска аппаратного обеспечения

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

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

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

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

4.5.3. Требования по диагностированию Модуля СЦ Диагностирование Модуля СЦ должно осуществляться путем анализа записей в системных журналах СУБД, операционных систем серверов, а также с помощью встроенных средств диагностирования общего программного обеспечения Модуля СЦ. Диагностированию подлежат: – сбои и нарушения функционирования технического обеспечения (серверов) Модуля СЦ; – сбои и нарушения функционирования системного программного обеспечения серверов, используемых для работы Модуля СЦ; – сбои и нарушения функционирования прикладного программного обеспечения серверов, используемых для работы Модуля СЦ; – случаи недоступности (отсутствия ответа) или некорректные ответы внешних систем; – сбои и нарушения функционирования СУБД; – сбои при выполнении регламентных операций резервного копирования. При возникновении аварийных ситуаций либо ошибок в программном обеспечении диагностические инструменты должны позволять сохранять набор информации, необходимой для идентификации и устранения проблемы. Модуль СЦ и ее компоненты должны обеспечивать возможность диагностики своей работоспособности с возможностью интеграции с модулем мониторинга АСУ ТК. Набор передаваемых журналов и метрик должен быть определен на этапе технического проектирования

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

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

4.5.8. Требования к защите от влияния внешних воздействий Требования к защите от влияния внешних воздействий не предъявляются

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

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

Лицензионное (сублицензионное) соглашение (договор) не может возлагать на Заказчика какие-либо обязанности (в т.ч. в части конфиденциальности, предоставления отчетности), не предусмотренные Контрактом. 4.5.9.7. Передача Заказчику исключительных прав, или простых (неисключительных) прав не может повлечь увеличение стоимости Контракта и/или изменение иных существенных условий Контракта. 4.5.9.8. Функциональность Модуля СЦ передается в объеме и в сроки, установленные Техническим заданием. 4.5.9.9. Нарушение условий настоящего раздела Технического задания, в т.ч. отсутствие соответствующего лицензионного (сублицензионного) соглашения (или договора), либо предоставление лицензионного (сублицензионного) соглашения (или договора), не соответствующего требованиям действующего законодательства Российской Федерации или требованиям Контракта, является нарушением существенных условий Контракта. 4.5.9.10. В случае, если в соответствии с пунктом 4.5.9.6 Заказчику передается исключительное право, такая передача осуществляется в порядке, установленном Гражданским кодексом Российской Федерации. 4.5.9.11. В случае, если при выполнении Работ положения пунктов 4.5.9.5-4.5.9.6 не применялись, Подрядчик в составе отчетной документации предоставляет об этом декларацию в свободной форме. Декларация должна содержать сведения о полном соответствии результата Работ требованиям Контракта, а также о неприменении при выполнении работ готового программного обеспечения (платформ, подсистем, СУБД и т.д.), которое стало частью (компонентом) Системы

4.1. Требования к структуре Модуля СЦ В процессе работ по развитию Системы должны сохраниться основные требования к построению архитектуры Системы в соответствии с принципами трехуровневой архитектуры: 1. уровень хранения данных или уровень базы данных (сервер СУБД); 2. уровень сервера приложений (сервер аналитической обработки); 3. презентационный уровень, обеспечивающий взаимодействие с клиентскими приложениями. В состав Системы должны входить следующие основные компоненты: 4. сервер баз данных; 5. сервер приложений; 6. веб-сервер. Сервер баз данных должен обеспечивать хранение и целостность хранимых данных, создание резервных копий, ведение журнала транзакций, восстановление данных после сбоев. Сервер приложений должен обеспечивать обработку запросов, поступающих от клиентских приложений (через веб-сервер), формирование ответов на запрос в доступном пользователю виде (формирование пользовательских интерфейсов). Веб-сервер должен обеспечивать взаимодействие с оператором и внешними системами по HTTP / HTTPS протоколу в режиме «запрос-ответ» (получения запросов от пользователя и передачи ответа в виде соответствующей информации, обработанной серверами приложений). Взаимодействие Системы с пользователем должно отвечать требованиям модели «тонкого клиента» (т.е. представлять на стороне клиента (пользователя) лишь графический пользовательский интерфейс). Все составляющие Системы должны использовать единую методологию и отвечать единым принципам взаимодействия, надежности и управления. Перечень компонентов Модуля СЦ представлен в Таблице 4. Таблица 4. Перечень компонентов Модуля СЦ, в отношении которых выполняются работы по развитию № п.п. Наименование компонента Модуля СЦ Раздел ТЗ 1 Компонент регистрации событий 4.2.1. 2 Компонент отчетности 4.2.2 3 Компонент визуализации 4.2.3 4 «Интерактивная карта» (компонент создается) 4.2.4 5 Компонент администрирования 4.2.5

4.2. Требования к дорабатываемым функциям модуля СЦ 4.2.1. Развитие компонента регистрации событий (1 очередь) Должны быть выполнены следующие доработки: – обеспечение логирования действий пользователя, связанных с карточкой события; – доработка объектной модели в части создания новых типов сущностей (карточек) с учетом реализуемых интеграций с информационными ресурсами (силы и средства предупреждения и ликвидации ЧС и нештатных ситуаций на транспорте, ТС, ограничения воздушного пространства, неблагоприятные и опасные природные явления); – реализация механизма установления связи между сущностями в Модуле СЦ автоматизированным и ручным способами (события, природные явления, силы и средства предупреждения и ликвидации ЧС и нештатных ситуаций на транспорте, ограничения воздушного пространства, ОТИ, ТС и др.); – отображение в карточке установленных связей между сущностями.

4.2.2. Развитие компонента отчетности (3 очередь) Должна быть обеспечена автоматизация процессов формирования отчетов о ЧС и нештатных ситуациях на транспорте, в т.ч. на основе данных из внешних систем. Включает следующие доработки: – разработка шаблонов отчетов в различных форматах (табличный, текстовый); – реализация выбора фотоматериалов для включения в справку; – форматирование содержимого справок с учетом правил русского языка в отношении окончаний слов (в зависимости от падежа, склонения, числа и рода); – автоматизированное формирование выводов к содержимому справки на основе настраиваемых критериев; – создание интерфейса выбора параметров (фильтрации) для формирования отчетов: o состав полей для включения в отчёт; o настройка диапазонов значений характеристик и дат; o порядок отображения полей; o настройка заголовка. – реализация способа подготовки отчётов в асинхронном режиме (очереди); – реализация интерфейса компонента формирования отчетности для отображения очереди формирования отчетов и статусов их подготовки; – экспорт отчётов в форматы xlsx, csv и справок в форматы pdf, docx. Необходимо разработать не менее 10 шаблонов отчетов и/или справок. Перечень, структура и содержание шаблонов должны быть согласованы с Заказчиком на этапе технического проектирования.

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

– отображение на карте связанных сущностей и ОТИ; – реализация функции выбора темного и светлого стилей отображения элементов интерфейса, карточек сущностей, картографической основы и объектов, отображаемых на карте; – реализация механизма для выбора картографической основы в одном из распространенных форматов WMTS, TMS, MVT и др. Должна быть предусмотрена возможность настройки перечня картографических основ и параметров доступа к ним; – настройка базового набора дашбордов, содержащих преднастроенные виджеты о количестве событий в разрезе видов транспорта с возможностью перехода к исходным данным (карточкам событий, ОТИ и т.д.), с фильтрацией по параметрам. Параметры фильтрации должны быть определены на этапе технического проектирования. Должно быть обеспечено автоматическое и принудительное обновление данных, отображаемых на дашбордах

4.2.4. Создание компонента «Интерактивная карта» (2 очередь) В составе создаваемого компонента должны отображаться данные, доступные в компоненте визуализации. Требования к интерфейсу интерактивной карты: – интерактивная карта должна быть представлена в виде объемной карты с учетом макетов, представленных в Приложении А к ТЗ; – интерфейс должен корректно отображаться на экранах мониторов (разрешение Full HD 1920?1080), телевизоров (разрешение 4К 3840?2160), жидкокристаллических панелей для видеостены, используемой Заказчиком, с параметрами каждой панели: диагональ 55 дюймов, разрешение 1920x1080; – интерфейс должен корректно отображаться на планшетных устройствах с диагональю экрана 10-12 дюймов, конкретные требования должны быть уточнены на этапе технического проектирования; – должна быть обеспечена кластеризация и генерализация отображения объектов на карте при изменении масштаба; – должно быть обеспечено отображение основных характеристик объектов при выборе их на карте; – должно быть обеспечено управление отображением слоев на карте; – должна быть обеспечена настройка цветовой индикации отображаемых объектов транспортной инфраструктуры; – должно быть обеспечено отображение легенды карты, содержащей отображаемые объекты на карте; – должна быть обеспечена возможность одновременного отображения не менее 5 000 ОТИ и ТС на карте.

На интерактивной карте должны быть отображены подвижные объекты совместно с объектами транспортной инфраструктуры (ОТИ), включая следующие возможности: § отображение местоположения транспортных средств (воздушный, водный и автомобильный транспорт) на карте в режиме реального времени (с заданным периодом обновления данных); § отображение маршрутов движения всех ТС за выбранный период времени, в том числе с использованием эффектов анимации; § отображение маршрутов движения ТС, связанных с карточкой события: ТС, являющихся участниками события, и ТС, находящиеся в заданном радиусе от события; § управление отображением сущностей и ОТИ на карте, включая настройку состава отображаемых объектов, поиск, фильтрацию, с использованием соответствующей панели управления и наглядным представлением результатов; § автоматическое изменение вида отображения объектов (цветовая индикация) по заданным условиям (например, при достижении критических значений параметров, характеризующих функционирование объекта); Должна обеспечиваться производительность обновления изображения на экране в 30 кадров в секунду на тестовой конфигурации пользовательского устройства (модель Бештау AIO2402/B560, входящая в Реестр российской промышленной продукции под номером 10394100 или аналог) при одновременном отображении не менее 5 000 объектов и 200 уникальных моделей объектов. Макеты интерфейсов Модуля СЦ должны быть предварительно согласованы с Заказчиком и разработаны с учетом требований ГОСТ Р ИСО 9241-161-2016 «Элементы графического пользовательского интерфейса»

4.2.4.1. Требования к технической реализации компонента «Интерактивная карта» При реализации компонента «Интерактивная карта» должны учитываться требования, указанные ниже. 4.2.4.1.1. Требования к отображению элементов Повторяющихся элементы карты (ТС, ОТИ, события и пр.) должны отрисовываться с использованием аппаратного создания экземпляров объектов на пользовательском устройстве (WebGL/WebGPU)). Отрисовка каждого объекта отдельным запросом не допускается, должна обеспечиваться возможность одновременного отображения не менее 5 000 объектов без снижения производительности (30 кадров в секунду на тестовой конфигурации). 4.2.4.1.2. Уровни детализации объектов Для управления отображением сложных объектов должно быть создано не менее 3-х уровней детализации, отображаемых при изменении масштаба с возможностью автоматического переключения между уровнями. Все отображаемые объекты должны масштабироваться с учетом разрешения экрана пользователя с сохранением качества детализации. 4.2.4.1.3. Полигональная оптимизация и текстурирование При реализации компонента «Интерактивная карта» должна обеспечиваться технология рельефного тестурирования объектов. Не должны использоваться высокополигональные трехмерные модели. Все повторяющиеся элементы должны генерироваться единоразово и повторно использоваться при последующих отображениях. 4.2.4.1.4. Управление памятью Требуется реализовать потоковую загрузку на устройство пользователя элементов карты и текстур. Загрузка данных целиком при старте приложения не допускается. Необходимо реализовать механизм очистки памяти от элементов, которые находятся вне области видимости камеры в течение заданного времени. 4.2.4.1.5. Требования к взаимодействию пользователя с интерфейсом компонента «Интерактивная карта» Программная реализация механизмов управление камерой (масштабирование и навигация) должна быть выполнена с поддержкой технологии WebAssembly (WASM). Элементы управления должны являться неотъемлемой частью интерактивной карты.

4.2.5. Развитие компонента администрирования (3 очередь) Должна быть выполнена доработка ролевой модели. Ролевая модель должна обеспечивать управление доступом к отдельным объектам Модуля СЦ и их элементам (атрибутам) с разграничением по видам транспорта, регионам и пр., в частности: – определение набора конкретных действий, доступных пользователям (выполняемых над объектом доступа, например, удаление записи, редактирование записи, формирование отчета и др.); – реализация возможности объединения пользователей в группы; – определение прав доступа для групп пользователей; – реализация интерфейса визуальной настройки прав доступа пользователей к объектам Модуля СЦ

4.2.6. Взаимосвязи с внешними автоматизированными системами (1 очередь) Способы взаимодействия с внешними информационными системами должны быть определены на этапе технического проектирования. Должны быть выполнены следующие доработки: – интеграции с информационными ресурсами в целях получения данных о движении подвижных ТС (воздушные суда, суда водного транспорта); – интеграция с информационным ресурсом в целях получения данных о событиях на железнодорожном транспорте. Реализация интеграций должна включать проектирование и реализацию интеграционных механизмов обмена данными с учетом доступных вариантов реализации, обеспечение защищенных способов взаимодействия, настройку отображения отдельных данных на карте (настройка слоев). Взаимодействия, имеющие каналы связи, выходящие за пределы контролируемой зоны взаимодействующих систем, считаются защищенными, если для их защиты используются программные и/или программно-аппаратные шифровальные (криптографические) средства, сертифицированные ФСБ России (далее – СКЗИ). Выбор СКЗИ, схемы подключения и требуемого класса криптостойкости должен производиться в соответствии с Техническими условиями на подключение к информационным ресурсам ФГБУ «СИЦ Минтранса России» и инструкциями по подключению пользователей к ресурсам инфраструктуры Головного центра обработки данных, утвержденных приказом директора ФБГУ «СИЦ Минтранса России» от 24.05.2024 № 21-ОД

4.3. Требования к оказанию услуг по технической поддержке Модуля СЦ 4.3.1. Общие требования к оказанию Услуг Техническая поддержка Модуля СЦ должна осуществляться с учетом требований постановления Правительства Российской Федерации от 06.07.2015 N 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации». Подрядчик обязан выполнять требования законодательства в сфере защиты информации, требования по защите информации, информационной безопасности, указанные в локальных нормативных актах ФГБУ «СИЦ Минтранса России», регламентирующих условия информационного взаимодействия, защиты информации и подключения к информационным ресурсам ФГБУ «СИЦ Минтранса России», участвующих в информационном взаимодействии в рамках оказания услуг по технической поддержке АСУ ТК в 2026 году

4.3.1.1. Требования к составу и содержанию услуг третьего уровня технической поддержки Оказание услуг по технической поддержке Системы осуществляется в рамках этапов в соответствии с календарным планом. Подрядчик в течение 5 рабочих дней с даты заключения Контракта должен предоставить со своей стороны, а Заказчик со своей стороны Матрицу ответственных за взаимодействия в соответствии с Приложением 1 к Регламенту оказания услуг по третьему уровню технической поддержки Модуля СЦ (далее – Регламент, Приложение В). Подрядчик в течение 10 рабочих дней с даты заключения Контракта должен провести мероприятия по организации третьего уровня технической поддержки в соответствии с Регламентом. Услуги по третьему уровню технической поддержки Модуля СЦ должны включать: – организацию Подрядчиком третьего уровня технической поддержки; – информационно-консультационную поддержку работников Заказчика; – решение инцидентов, связанных с работой ППО; – адаптационное, конфигурационное и коррекционное сопровождение Модуля СЦ (в рамках действующих программных модулей и функциональности); – устранение уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности

4.3.1.2. Требования к общему порядку оказания услуг Техническая поддержка Модуля СЦ должна быть организована на трех уровнях: – первый и второй уровни технической поддержки организуется Заказчиком; – третий уровень технической поддержки организуется Подрядчиком. Перечень действий на каждом уровне технической поддержки указан в Таблице 5: Таблица 5 – Перечень действий на каждом уровне технической поддержки Уровень технической поддержки Доступные действия Условия передачи задачи на следующий уровень Первый уровень технической поддержки (далее – 1-й уровень) – принимает обращения (заявки) пользователей Модуля СЦ и работников Заказчика; – регистрирует обращения в Модуле СЦ регистрации обращений; – присваивает уникальный идентификационный номер, классифицирует обращения; – самостоятельно решает обращения, которые связаны с недостаточной квалификацией пользователей или настройками в рамках своей компетенции; – взаимодействует с пользователями Модуля СЦ при решении проблемы Передает обращение на второй уровень поддержки в случае невозможности решения на своем уровне Второй уровень технической поддержки (далее – 2-й уровень) – принимает обращения от 1-го уровня; – уточняет классификацию обращения в результате дополнительного анализа; – самостоятельно решает обращения в рамках своей компетенции; – осуществляет техническую и консультационную поддержку Модуля СЦ; – взаимодействует с сотрудниками 1-го и 3-го уровня и пользователями Модуля СЦ; – формирует заявки для 3-го уровня и контролирует исполнение Передает обращение на третий уровень поддержки в случае невозможности решения на своем уровне Третий уровень технической поддержки (далее – 3-й уровень) – принимает обращения от 2-го уровня; – обеспечивает выполнение требований, предъявляемых Контрактом и настоящим Техническим заданием к Услугам, оказываемым Подрядчиком Все поступающие обращения должны быть исполнены Подрядчиком

Для обеспечения взаимодействия с Заказчиком Подрядчик со своей стороны определяет ответственных лиц, уполномоченных в структуре Подрядчика за своевременное и качественное оказание Услуг в рамках настоящего ТЗ, а также контактную информацию ответственных лиц (телефон, электронную почту). Подрядчик должен предоставить Заказчику единый адрес электронной почты для приема обращений (заявок) в течение 3 (трех) рабочих дней после заключения Контракта. Указанный в настоящем пункте адрес электронной почты (способ направления обращений (заявок) применяется в случае сбоя в работе СРО Заказчика. Со своей стороны, Заказчик предоставляет Подрядчику перечень и контактную информацию (телефон, электронную почту) уполномоченных лиц для осуществления взаимодействия с указанием зон ответственности. О любых изменениях в контактной информации ответственных лиц Стороны должны уведомить друг друга в течение 1 (одного) рабочего дня с момента возникновения таких изменений посредством уведомления на электронную почту ответственных лиц и/или в письменной форме. В результате оказания услуг по настоящему ТЗ не должны быть изменены исходные коды, дистрибутивы и иные компоненты Модуля СЦ вне согласованных с Заказчиком изменений. Любые изменения исходных кодов, дистрибутивов и иных компонентов Модуля СЦ должны производиться только после согласования с Заказчиком уполномоченными лицами по электронной почте или иным заранее согласованным способом. Не должна быть ухудшена надежность и производительность Модуля СЦ. Оказание услуг по Контракту не должно нарушать требования к информационной безопасности, описанной в документации на Модуль СЦ

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

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

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

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

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

4.3.4. Требования к документированию результатов оказываемых услуг Для обеспечения контроля оказываемых услуг по поддержке Модуля СЦ со стороны Заказчика, по окончании каждого отчетного периода по контракту в соответствии с календарным планом, Подрядчик обязан предоставить Заказчику Отчет об оказанных услугах. Отчет должен содержать детальную информацию об оказанных услугах с указанием даты выполненных мероприятий и приложением обосновывающих документов (заявок, запросов, требований) или ссылкой на такие документы, если они содержатся в Модуле СЦ. Информация о выполненных мероприятиях по заявкам должна быть сформирована на основании соответствующих записей СРО по каждому этапу исполнения Контракта. В случае оказания услуги адаптационного, конфигурационного и коррекционного сопровождения Модуля СЦ, должны быть предоставлены документы, подтверждающие выполнение требований п. 29.3 приказа ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации». Фактическое время реагирования и время решения по всем обращениям, поступившим в СРО, формируется в СРО по итогам отчетного периода в разделе «Отчеты». Фактическое время реагирования и время решения по обращениям учитывает суммарное время, затраченное на реагирование и, соответственно, на работу по обращению с момента назначения обращения специалисту Подрядчика или группе исполнителей, ответственным за оказание услуг технической поддержки 3 уровня от начала до завершения работ Подрядчиком. При этом принимается суммарное время нахождения заявки в соответствующих статусах заявки СРО на стороне Подрядчика

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

5. СОСТАВ И СОДЕРЖАНИЕ РАБОТ ПО РАЗВИТИЮ И ТЕХНИЧЕСКОЙ ПОДДЕРЖКЕ МОДУЛЯ СЦ (КАЛЕНДАРНЫЙ ПЛАН) - Сдача-приемка результатов выполненных работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная техническая документация, а также результаты работ предоставляются Заказчику в порядке, предусмотренном Контрактом и ТЗ, до размещения Подрядчиком в ЕИС документа о приемке. Документ о приемке размещается в ЕИС по каждому этапу в соответствии с условиями Контракта. Этапы выполнения работ по развитию Модуля СЦ приведены в Таблице 11. Таблица 11. Этапы выполнения работ по развитию Модуля СЦ. № этапа Наименование этапа Результат (отчетная документация) Срок исполнения этапа - - Значение характеристики не может изменяться участником закупки

1 Техническое проектирование Сопроводительным письмом предоставляются Заказчику: · Технический проект, включая следующие документы: – Ведомость технического проекта; – Ведомость машинных носителей информации – Пояснительная записка; – Описание информационного обеспечения системы; – Описание автоматизируемых функций; – Схема функциональной структуры; – Описание организации информационной базы; – Описание программного обеспечения; · Макеты экранных форм компонента «Интерактивная карта»; · Руководство по безопасной разработке программного обеспечения; · Документ о приемке Начало: с даты заключения контракта Окончание: не позднее 31.07.2026

2 Услуги по технической поддержке Модуля СЦ (с даты заключения контракта по 10.09.2026) По окончании оказания Услуг сопроводительным письмом предоставляются Заказчику: – Отчет об оказанных Услугах по технической поддержке; – Актуальные на дату окончания оказания Услуг по данному этапу исходные коды прикладного ПО на электронном носителе (в случае внесения изменений); – Инструкция по сборке и развертыванию (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство пользователя (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство администратора (в случае внесения изменений); – Документ о приемке Начало: с даты заключения контракта Окончание: не позднее 10.09.2026

3 Разработка программного обеспечения (1 очередь, пп. 4.2.1, 4.2.6 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ; – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 1 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 1 очереди; – Руководство по резервному копированию; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 16.09.2026

4 Разработка программного обеспечения (2 очередь, пп. 4.2.3, 4.2.4 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ. – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 2 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 2 очереди; – Руководство по резервному копированию; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 25.09.2026

5 Разработка программного обеспечения (3 очередь, пп. 4.2.2, 4.2.5 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ; – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 3 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 3 очереди; – Руководство по резервному копированию; – Описание ролевой модели; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 09.10.2026

6 Опытная эксплуатация (1 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акт о завершении опытной эксплуатации 1 очереди; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке 17.09.2026 Окончание: не позднее 26.10.2026

7 Опытная эксплуатация (2 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акт о завершении опытной эксплуатации 2 очереди; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке 26.09.2026 Окончание: не позднее 26.10.2026

8 Опытная эксплуатация (3 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Акт о завершении опытной эксплуатации 3 очереди; – Документ о приемке Начало: с 10.10.2026 Окончание: не позднее 26.10.2026

9 Приемочные испытания Сопроводительным письмом предоставляются Заказчику: – Программа и методика приёмочных испытаний; – Протокол приемочных испытаний; – Исходные коды и дистрибутивы на электронном носителе (при условии внесения изменений, с учетом доработок по результатам опытной эксплуатации и проведенных испытаний); – Комплект рабочей документации на Модуль СЦ (при условии внесения изменений, с учетом доработок по результатам опытной эксплуатации и проведенных испытаний); – Акт приемки Системы в эксплуатацию; – Акт приемки-передачи исключительных прав на объект; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке; – Документы в соответствии с разделом 4.5.9 ТЗ; – Обеспечение гарантийных обязательств Начало: с 27.10.2026 Окончание: не позднее 10.11.2026

10 Услуги по технической поддержке Модуля СЦ (с 11.09.2026 по 15.12.2026) По окончании оказания Услуг сопроводительным письмом предоставляются Заказчику: – Отчет об оказанных Услугах по технической поддержке; – Актуальные на дату окончания оказания Услуг по данному этапу исходные коды прикладного ПО на электронном носителе (в случае внесения изменений); – Инструкция по сборке и развертыванию (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство пользователя (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство администратора (в случае внесения изменений); – Документ о приемке Начало: с 11.09.2026 Окончание: не позднее 15.12.2026

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

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

6.1. Сведения о гарантийном обслуживании Модуля СЦ Под гарантией понимается устранение Подрядчиком своими силами и за свой счет допущенных по его вине недостатков, выявленных после приемки выполненных Работ, как в работе самой Модуля СЦ, так и недостатков в отчетной документации. Если в период гарантийного срока обнаружатся недостатки, то Подрядчик обязан устранить их за свой счет, в сроки, установленные Заказчиком. Гарантийный срок в этом случае продлевается на период устранения недостатков. Срок гарантии: 1 год с даты приемки Заказчиком результатов исполнения Этапа № 9 контракта. Подрядчиком должны быть внесены соответствующие исправления в техническую и рабочую документацию (указанную в пунктах 5 и 6 настоящего ТЗ), связанные с устранением замечаний к работе Модуля СЦ или в случае выявления Заказчиком недостатков в такой документации в период гарантийного срока. Внесение изменений в документацию технического и рабочего проектирования осуществляется в соответствии с ГОСТ 2.503-2023 и ГОСТ Р 2.504-2021.

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

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

8. ТРЕБОВАНИЯ К СОСТАВУ И СОДЕРЖАНИЮ РАБОТ ПО ПОДГОТОВКЕ МОДУЛЯ СЦ К ВВОДУ В ЭКСПЛУАТАЦИЮ - По результатам проведения приемочных испытаний оформляется Протокол приемочных испытаний и Акт приемки в эксплуатацию. В случае, если взаимодействие с внешними системами не может быть проверено на средах постоянной эксплуатации взаимодействующих систем (по причине неготовности со стороны внешней системы или иным причинам), функции взаимодействия, разработанные в соответствии с требованиями ТЗ, должны быть проверены на тестовых данных с использованием программ-имитаторов взаимодействия. По результатам выполнения этапа приемочных испытаний должны быть подготовлены материалы для регистрации доработанной версии Модуля СЦ (объекта учета) в НФАП в соответствии с требованиями постановления Правительства Российской Федерации от 30 января 2013?г. №?62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин» (с изменениями и дополнениями) в части обязательности размещения результатов работ в национальном фонде алгоритмов и программ для электронных вычислительных машин. Сдача-приемка результатов выполнения Работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная, техническая документация, а также программное обеспечение предоставляется Заказчику в порядке, предусмотренном Контрактом и ТЗ до размещения Подрядчиком в Единой информационной системе в сфере закупок документа о приемке. Результаты проведения опытной эксплуатации, предварительных и приемочных испытаний должны быть зафиксированы в соответствующих протоколах и актах. Выявленные отклонения от настоящего ТЗ, оформляются как недостатки Модуля СЦ - - Значение характеристики не может изменяться участником закупки

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

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

9. ТРЕБОВАНИЯ К ДОКУМЕНТИРОВАНИЮ - 9.1. Общие требования Документация на Модуль СЦ должна быть разработана в составе, указанном в разделах 5-8 данного ТЗ, и должна удовлетворять требованиям комплекса стандартов и руководящих документов на автоматизированные системы: – ГОСТ Р 2.105-2019 в части оформления текстовых документов; – ГОСТ 34.201-2020 в части наименования и обозначения документов. Документация на Модуль СЦ должны оформляться на листах формата А4. Допускается для размещения рисунков и таблиц использование листов формата А3 с подшивкой по короткой стороне листа. Документы объемом более 25 (двадцати пяти) листов должны содержать информационную часть, состоящую из аннотации и содержания. Исходные коды должны быть представлены в 1 (одном) экземпляре на электронном носителе, отчетные материалы должны быть представлены в 2 (двух) экземплярах на бумажном носителе (по одному экземпляру для Заказчика и Подрядчика) и в 1 (одном) экземпляре на электронном носителе в формате документов DOCX и PDF. При разработке документов на Модуль СЦ допускается отклонение от требований комплекса стандартов, описанных выше. Документам на Модуль СЦ должны в обязательном порядке присваиваться уникальные децимальные номера в соответствии с порядком, установленном в ГОСТ 34.201-2020. Документ «Программа и методика предварительных испытаний» должен включать приложения с формой протокола предварительных испытаний и формой акта приемки в опытную эксплуатацию. Документ «Программа опытной эксплуатации» должен включать приложение с формой журнала опытной эксплуатации. Документ «Программа и методика приемочных испытаний» должен включать приложения с формой протокола приемочных испытаний и формой акта приемки в эксплуатацию - - Значение характеристики не может изменяться участником закупки

10. ИСТОЧНИКИ РАЗРАБОТКИ - 10.1. Список литературы Специальная литература для разработки ТЗ не использовалась. 10.2. Нормативно-методические документы Список используемых нормативно-методических документов представлен в разделе 1.6 технического задания. ? Приложение А Эскизы визуального оформления компонента «Интерактивная карта» - - Значение характеристики не может изменяться участником закупки

Приложение Б Параметры оказания услуг - Б.1. Базовые параметры оказания Услуг Базовые параметры оказания Услуг приведены ниже: – режимы оказания Услуг (таблица Б.1.1); – сроки предоставления отчетности (таблица Б.1.2). Таблица Б.1.1 - Режимы оказания Услуг № п/п Параметр Значение - - Значение характеристики не может изменяться участником закупки

1 Режим работы Системы Круглосуточно (24х7) 2 Режим доступности информационно-консультационной поддержки пользователей Системы 2.1 Прием и регистрация обращений (заявок) в СРО Регистрация обращений (заявок) производится круглосуточно в режиме 24х7, без праздников и выходных дней. Обработка заявок первой линией поддержки осуществляется в рабочие дни с 9 до 18 часов 2.2 Консультирование сотрудников Заказчика и пользователей Системы в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 3 Режим доступности по решению инцидентов, связанных с работой ППО: 3.1 - приоритет «Критический» Круглосуточно (24х7) 3.2 - приоритет «Высокий» Круглосуточно (24х7) 3.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 3.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4 Режим доступности услуг по адаптации, конфигурации и коррекционному сопровождению Системы 4.1 - приоритет «Критический» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.2 - приоритет «Высокий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 5 Режим доступности по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности 5.1 - приоритет «Критический» Круглосуточно (24х7) 5.2 - приоритет «Высокий» Круглосуточно (24х7) 5.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 5.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням)

Таблица Б.1.2. Сроки предоставления отчетности, с момента получения запроса № п/п Параметр Значение 1 Предоставление отчета об оказанных услугах за произвольный период 10 рабочих дней 2 Предоставление подробной информации по инциденту с приоритетом «Критический» 16 рабочих часов 3 Предоставление актуализированной документации 10 рабочих дней

Б.2. Приоритеты и регламентные сроки решения обращений (заявок) В зависимости от уровня сбоя в работе Системы обращению (заявке) присваивается один из следующих приоритетов, а также в зависимости от приоритета обращения (заявки) устанавливаются следующие контрольные сроки решения в соответствии с таблицей ниже (Таблица Б.2.1). Таблица Б.2.1 – Приоритеты и регламентные сроки решения обращений (заявок) № п/п Приоритет Максимальное время реагирования Время решения (срок выполнения) Описание приоритета По информационно-консультационной поддержке сотрудников Заказчика и пользователей Системы 1 - не более 1 часа не более 10 часов - По решению инцидентов, связанных с работой ППО: 1 Критический не более 30 минут не более 4 часов - полная недоступность ППО; - недоступность ключевых функций - ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО; - невозможность информационного обмена с ППО для ИС более 4 часов 2 Высокий не более 1 часа не более 8 часов - ошибки/сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; - снижение быстродействия СПО (время отклика ППО на операции превышает 30 секунд); - недоступность управления правами и ролями пользователей 3 Средний не более 4 часов не более 24 часов - невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым -недоступность функции формирования отчетов 4 Низкий не более 8 часов не более 40 часов - отклонение в работе ППО, не влияющее на корректную работу функций; - другие сбои и ошибки, затрагивающие основные функции ППО

По адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) 1 Критический не более 40 минут не более 8 часов - изменения, необходимые при проведении аварийно-восстановительных работ для возобновления работоспособности Системы; - изменения, связанные с критичными ошибками, блокирующими возможность оказания государственных услуг и/или чтение и внесение данных в Систему 2 Высокий не более 1 часа не более 40 часов - изменения, относящиеся к обеспечению работоспособности основной функциональности Системы, устраняют выявленные дефекты в работе Системы, оказывающие существенное влияние на работу пользователей в Системе; - изменения, затрагивающие три и более подсистемы/модуля Системы для адаптации 3 Средний не более 4 часов не более 72 часов - изменения, связанные с развитием/улучшением/оптимизацией Системы и выводом новой функциональности в штатном режиме для одного-двух модулей/подсистем; - изменения, связанные с развитием интеграционных механизмов Системы, например обновление существующих и/или реализация новых видов сведений СМЭВ, обновление существующих и/или реализация новых API, адаптация и/или изменение механизмов импорта и экспорта данных Системы и т.д. 4 Низкий не более 8 часов не более 160 часов - изменения, связанные с ошибками/корректировкой/изменением в отображении информации в пользовательском графическом интерфейсе Системы (графика, текст, органы управления, элементы интерфейса)

По устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности 1 Критический не более 30 минут не более 24 часов - критические уязвимости, влияющие на возможную полную недоступность ППО, ключевых функций Системы, ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО без возможности восстановления работоспособности Системы. - Критический уровень CVSS > 8.0 2 Высокий не более 1 часа не более 84 часов - критические уязвимости, влияющие на ошибки и сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО. - Высокий уровень CVSS 5.0 - 8.0 3 Средний не более 4 часов не более 120 часов - уязвимости, влияющие на невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым - Средний уровень CVSS 2.0 - 4.9 4 Низкий не более 8 часов не более 160 часов - уязвимости, влияющие на отклонение в работе ППО, не влияющее на корректную работу функций; - другие сбои и ошибки, затрагивающие основные функции ППО - Низкий уровень CVSS < 2.0

Взаимодействие Заказчика и Подрядчика в части регистрации и контроля времени реагирования и решения обращения (заявки) осуществляется через СРО. Заказчик предоставляет Подрядчику доступ к СРО после заключения Контракта. Поступившие от разных пользователей заявки по поводу однотипных инцидентов или имеющие общую причину должны объединяться в одну заявку. Срок выполнения включает время диагностики инцидента, в ходе которого определяется причина инцидента (проблемы) и способ его устранения. Подрядчик должен обеспечить функционирование Модуля СЦ в соответствии с требованиями и параметрами, указанными в настоящем ТЗ и Регламенте оказании услуг. Основные параметры быстродействия типовых операций в Модуле СЦ указаны в таблице ниже (таблица Б.2.2). Таблица Б.2.2 - Параметры быстродействия Модуля СЦ № п/п Наименование параметра Значение (секунд) 1 Среднее время получения сообщения из очереди сообщений 10 2 Среднее время получения ответа от Системы 5 3 Среднее время открытия карточки реестра 5

Приложение В Регламент оказания услуг - Уровень технической поддержки Организационно-структурная часть технической поддержки, имеющая определённые организационно-нормативными документами зоны ответственности, обязанности, а также временные нормативы, в течение которых эти обязательства должны выполняться либо эскалироваться на следующий уровень технической поддержки Услуги Услуги по технической поддержке Информационно-аналитической системы регулирования на транспорте АСУ ТК ФИО Фамилия, имя, отчество Эскалация Процедура повышения внимания к обращению (заявке) путем повышения его приоритета и/или передачи на следующий уровень технической поддержки, а также привлечение ролей, которые могут принимать решения без передачи на следующий уровень технической поддержки API Англ. Application Programming Interface — программный интерфейс приложения, интерфейс прикладного программирования — описание способов (набор классов, процедур, функций, структур или констант), которыми одна компьютерная программа может взаимодействовать с другой программой - - Значение характеристики не может изменяться участником закупки

CVSS Англ. Common Vulnerability Scoring System - открытый стандарт, используемый для расчета количественных оценок уязвимости в безопасности компьютерной системы, обычно с целью понять приоритет ее исправления. В современном инструментарии информационной безопасности используется версия 3.0 и выше с дополнительными метриками к базовым оценкам ID Англ. Identifier – идентификатор, уникальный признак объекта, позволяющий отличать его от других объектов, то есть, идентифицировать SLA Англ. Service Level Agreement - утвержденные условия по обработке обращения (заявки) с установленными метриками времени, которые определяют пороговые значения для эскалации в зависимости от статуса обращения (заявки) (например, время реакции – время от регистрации до осуществления первичной обработки, время решения – время от регистрации обращения (заявки) до его решения и т.д.) SQL Англ. Structured Query Language — «язык структурированных запросов», — декларативный язык программирования, применяемый для создания, модификации и управления данными в реляционной базе данных, управляемой соответствующей СУБД

1 Общие сведения 1.1 Полное наименование Услуг Оказание услуг по технической поддержке Модуля СЦ АСУ ТК в 2026 году. 1.2 Предмет Регламента оказания услуг Требования Технического задания

2 Общие положения 2.1 Цель и задачи оказания услуг Целью технической поддержки Системы является обеспечение ее стабильного и безопасного функционирования и эксплуатации, предупреждение, выявление и устранение сбоев в работе Системы и минимизация их неблагоприятного влияния. Для достижения поставленной цели требуется решение следующих задач: 1. Обеспечение информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы. 2. Поддержание параметров функционирования ППО Системы, удовлетворяющих требованиям производственных процессов, включая их непрерывность. 3. Обеспечение бесперебойного функционирования ППО и своевременное устранение сбоев и аварийных ситуаций в Системе. 4. Своевременное устранение уязвимостей при выявлении таковых, в соответствии с требованиями к обеспечению информационной безопасности. 5. Адаптация, конфигурирование, коррекция программного обеспечения в соответствии с изменениями нормативно-правовой базы и запросами уполномоченных сотрудников органов государственной власти, включая выполнение процедур тестирования и участие в обновлениях ППО на стендах Заказчика. 6. Обеспечение сохранения работоспособности ППО в изменяемой среде эксплуатации. 7. Ведение документации по настоящему контракту и инициирование актуализации документации на Систему по результатам обработки запросов Заказчика и внесения соответствующих изменений в ППО

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

На рисунке 8 приведена форма обращения (заявки) типа «Инцидент» в СРО. Рисунок 8 - Форма обращения (заявки) типа «Инцидент» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуги по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности, заполненную в свободной форме

Приложение 1 к Регламенту Матрица ответственных за взаимодействия в рамках выполнения работ по техническому сопровождению Системы Таблица 1 – Ответственные за взаимодействия в рамках выполнения работ по техническому сопровождению Системы со стороны Исполнителя ФИО Должность Адрес электронной почты Телефон — — — Общий контакт

Приложение 2 к Регламенту Приоритеты и регламентные сроки решения обращений (заявок) Приоритеты и регламентные сроки решения обращений (заявок) приведены в таблице 1. Таблица 1 – Приоритеты и регламентные сроки решения обращений (заявок) № п/п Приоритет Максимальное время реагирования Время решения (срок выполнения) Описание приоритета

По информационно-консультационной поддержке сотрудников Заказчика и пользователей Системы 1 – не более 1 часа не более 10 часов –

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

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

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

По решению инцидентов, связанных с работой ППО 1 Критический не более 30 минут не более 4 часов – полная недоступность ППО; – недоступность ключевых функций; – ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО; – невозможность информационного обмена с ППО для ИС более 4 часов 2 Высокий не более 1 часа не более 8 часов – ошибки/сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; – снижение быстродействия СПО (время отклика ППО на операции превышает 30 секунд); – невозможность управления правами и ролями пользователей 3 Средний не более 4 часов не более 24 часов – невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым недоступность функции формирования отчетов 4 Низкий не более 8 часов не более 40 часов – отклонение в работе ППО, не влияющее на корректную работу функций; – другие сбои и ошибки, затрагивающие основные функции ППО

По адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) 1 Критический не более 40 минут не более 8 часов – изменения необходимые при проведении аварийно-восстановительных работ для возобновления работоспособности Системы; – изменения, связанные с критичными ошибками, блокирующими возможность оказания государственных услуг и/или чтение и внесение данных в Систему 2 Высокий не более 1 часа не более 40 часов – изменения относящиеся к обеспечению работоспособности основной функциональности Системы, устраняют выявленные дефекты в работе Системы, оказывающие существенное влияние на процесс оказания государственных услуг и работу пользователей в Системе; – изменения, затрагивающие три и более подсистемы/модуля Системы для адаптации 3 Средний не более 4 часов не более 72 часов – изменения, связанные с развитием/улучшением/оптимизацией Системы и выводом новой функциональности в штатном режиме для одного-двух модулей/подсистем; – изменения, связанные с развитием интеграционных механизмов Системы, например, обновление существующих и/или реализация новых видов сведений СМЭВ, обновление существующих и/или реализация новых API, адаптация и/или изменение механизмов импорта и экспорта данных Системы и т.д. 4 Низкий не более 8 часов не более 160 часов – изменения, связанные с ошибками/ корректировкой/изменение в отображении информации в пользовательском графическом интерфейсе Системы (графика, текст, органы управления, элементы интерфейса)

По устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности 1 Критический не более 30 минут не более 24 часов – критические уязвимости, влияющие на возможную полную недоступность ППО, ключевых функций Системы, ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО без возможности восстановления работоспособности Системы; – Критический уровень CVSS > 8.0 2 Высокий не более 1 часа не более 84 часов – критические уязвимости, влияющие на ошибки и сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; – Высокий уровень CVSS 5.0 - 8.0 3 Средний не более 4 часов не более 120 часов – уязвимости, влияющие на невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым; – Средний уровень CVSS 2.0 - 4.9 4 Низкий не более 8 часов не более 160 часов – уязвимости, влияющие на отклонение в работе ППО, не влияющее на корректную работу функций; – другие сбои и ошибки, затрагивающие основные функции ППО; – Низкий уровень CVSS < 2.0

Таблица 1 - Типы обращений (заявок) Тип обращения (заявки) Описание Запрос на обслуживание Подготовка SQL запроса к СУБД для решения прикладной задачи и д р. – запрос на любое действие, не являющееся запросом информации и несовершенный на основе происшествия, прямо или косвенно влияющего на работу Системы Консультация (входит в тип обращения (заявки) «Запрос на обслуживание») «Где взять / куда обратиться...?», «Как сделать / выполнить…», «Как это работает…?» - запрос, имеющий своей целью получение информационной поддержки Инцидент Разбор ошибок/сбоев и подготовка материалов (корректировочных релизов, инструкций) для Заказчика для устранения ошибок/сбоев, которые приводят к частичному и полному нарушению работоспособности всех или отдельных функций ППО. Подготовка изменения и материалов, необходимых для проведения аварийно-восстановительных работ для возобновления работоспособности Системы. ЗНИ Подготовка изменений, связанных с изменением, улучшением/оптимизацией Системы и выводом новой модифицированной функциональности в штатном режиме. Подготовка изменений, связанных с модификацией существующих и/или реализация новых интеграционных механизмов для получения/обработки данных внешних систем. Подготовка изменений графического интерфейса по требованиям Заказчика

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

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

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

Приложение Г Форма Отчета об оказанных услугах Отчет об оказанных услугах за этап «наименование этапа» в период с «__» _________ по «__» _________. № п/п Наименование услуги Общее количество Номер ОРС Краткое Описание Время реагирования по ТЗ Время реагирования фактическое Время решения по ТЗ Время решения фактическое Результат соблюдения времени реагирования Результат соблюдения времени решения Примечание 1 Услуги по информационно-консультационной поддержке работников Заказчика 2 546782 Консультация по работе Модуля СЦ 1 2 10 часов 11 часов Нет Нет 567123 Консультация по схеме БД 1 1 10 часов 1 час Да Да 2 … … Заказчик Подрядчик /Должность/ /Должность/ ____________________ /Ф.И.О/ ___________________ /Ф.И.О/ М.П. М.П. «_____»_______________________202_г. «_____»_______________________202_г

Приложение 1 к Отчету об оказанных услугах Журнал обращений (заявок) на оказание услуги по информационно-консультационной поддержке пользователей Системы (шаблон) Наименование Исполнителя в этапе «наименование этапа» в период с ________________ по _______________ оказал(о) Услугу по поддержке пользователей Системы в объеме, указанном в Таблице 1 Таблица 1 - Журнал обращений (заявок) пользователей Системы № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. ИТОГО зарегистрировано: Всего обращений (заявок): ________ ИТОГО решено: Всего обращений (заявок): ________

Приложение 2 к Отчету об оказанных услугах Журнал обращений (заявок) по решению инцидентов, связанных с работой ППО (шаблон) Наименование Исполнителя в этапе «наименование этапа» в период с ________________ по _______________ оказал(о) Услугу по решению инцидентов в объеме, указанном в Таблице 1. Таблица 1 - Журнал по решению инцидентов № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. ИТОГО зарегистрировано: Всего инцидентов: ________ ИТОГО решено: Всего инцидентов: ________

Приложение 3 к Отчету об оказанных услугах Журнал обращений (заявок) выполнения адаптационного, конфигурационного и коррекционного сопровождения Системы (шаблон) Журнал выполнения адаптации, конфигурации и коррекции Системы сформирован за этап «наименование этапа» в период с «__» _________ по «__» ____________ и представлен в таблице ниже (Таблица 1). Таблица 1 - Журнал выполнения адаптации, конфигурации и коррекции сопровождения Системы № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. Количество выполненных заявок за этап: ________

Приложение 4 к Отчету об оказанных услугах Журнал обращений (заявок) по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности (шаблон) Журнал обращений (заявок) по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности сформирован за этап «наименование этапа» в период с «__» _________ по «__» ____________ и представлен в таблице ниже (Таблица 1). Таблица 1 - Журнал выполнения заявок по устранению уязвимостей в ППО № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. Количество выполненных заявок за этап: ________

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

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

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

Приложение Д Форма Протокола проверки результатов организационно-штатных и подготовительных мероприятий (шаблон) Протокол проверки результатов организационно-штатных и подготовительных мероприятий Настоящий Протокол содержит результаты проверки организационно-штатных и подготовительных мероприятий, проведенных Исполнителем (Таблица Д.1). Таблица Д.1. Протокол проверки результатов № Мероприятия Подготовительного этапа Результат проверки 1. Определить и направить Заказчику документ «Ответственные за взаимодействия в рамках выполнения работ по техническому сопровождению Системы со стороны Исполнителя». Документ содержит контактную информацию (ФИО, должность, адрес электронной рабочей почты, номер телефона) не менее чем о 2 лицах, ответственных за оказание услуг со стороны Подрядчика Выполнено/Не выполнено 2. Обеспечить подключение специалистов Подрядчика к Системе Выполнено/Не выполнено 3. Обеспечить подключение специалистов Подрядчика к СРО Выполнено/Не выполнено Заказчик Подрядчик /Должность/ /Должность/ ____________________ /Ф.И.О/ ___________________ /Ф.И.О/ М.П. М.П. «_____»_______________________202_г. «_____»_______________________202_г

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

3.4.1 Инцидент На рисунке 2 представлена функциональная схема регистрации и сопровождения обращений (заявок) типа «Инцидент». Рисунок 2 - Функциональная схема регистрации и сопровождения обращений (заявок) типа «Инцидент» 3.4.2 Запрос на обслуживание На рисунке 3 представлена функциональная схема регистрации и сопровождения обращения (заявки) типа «ЗНО». Рисунок 3 - Функциональная схема регистрации и сопровождения обращения (заявки) типа «ЗНО» 3.4.3 Запрос на изменение На рисунке 4 представлена функциональная схема регистрации и сопровождения обращений (заявок) типа «ЗНИ». Рисунок 4 - Функциональная схема регистрации и сопровождения обращений (заявок) типа «ЗНИ»

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

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

4 Формы обращений (заявок) на оказание услуг по технической поддержке Системы, заполняемые в СРО 4.1. Форма обращения (заявки) на оказание услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы При подаче обращения (заявки) типа «ЗНО» в СРО указывается (Таблица 5): Таблица 5 – Описание атрибутов формы обращения (заявки) на оказание услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 5) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 5) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 5) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 5) Категория обращения: информационно-консультационная поддержка Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 5) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 5) Текст запроса на оказание услуги по информационно-консультационной поддержке сотрудников Заказчика Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 5)

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

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

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

4.2. Форма обращения (заявки) на оказание услуги по решению инцидентов, связанных с работой ППО При подаче обращения (заявки) типа «Инцидент» в СРО указывается (Таблица 6): Таблица 6 – Описание атрибутов формы обращения (заявки) на оказание услуги по решению инцидентов, связанных с работой ППО Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 6) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 6) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 6,) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 6) Категория обращения (заявки): инцидент Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 6) Приоритет изменения Время - одно из значений: Низкий, Средний, Высокий или Критический. Определяет, очередность решения обращения (заявки), ресурсы, привлекаемые для решения обращения (заявки), порядок/процедура действий при решении обращения (заявки) – поле СРО «Приоритет» (см. рисунок 6,)

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

На рисунке 6 приведена форма обращения (заявки) типа «Инцидент» в СРО. Рисунок 6 - Форма обращения (заявки) типа «Инцидент» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуги по решению инцидентов, связанных с работой ППО, заполненную в свободной форме

4.3. Форма обращения (заявки) на оказание услуг по адаптационному конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) При подаче обращения (заявки) типа «ЗНИ» в СРО указывается (Таблица 7): Таблица 7 – Описание атрибутов формы обращения (заявки) на оказание услуг по адаптационному, конфигурационному и коррекционному сопровождению Системы Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 10) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 9) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 10) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 10) Категория обращения (заявки): запрос на изменение Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 7) Приоритет изменения Время, очередность решения обращения (заявки), ресурсы, привлекаемые для решения обращения (заявки), порядок/процедура действий при решении обращения (заявки) – поле СРО «Приоритет» (см. рисунок 7) Тип изменения Справочник, классифицирующий типовые запросы характерные для Системы – поле СРО «Предмет обращения» (см. рисунок 7) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 7) Текст запроса на оказание услуги по адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 7)

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

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

- 62.01.11.000 - Этап№4: Разработка программного обеспечения (2 очередь, пп. 4.2.3, 4.2.4 ТЗ), Предварительные испытания ОКПД2: 62.01.11.000 ОПРЕДЕЛЕНИЯ, ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ Автоматизированная система (АС) Система, состоящая из комплекса средств автоматизации, реализующего информационную технологию выполнения установленных функций, и персонала, обеспечивающего его функционирование (ГОСТ Р 59853-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения») АРМ Автоматизированное рабочее место АСУ ТК, Система Информационно-аналитическая система регулирования на транспорте АТС Автоматическая телефонная станция БД База данных ГИС Государственная информационная система ГОСТ Государственный стандарт ГЦОД СИЦ Минтранса России, ГЦОД Головной центр обработки данных ФГБУ «СИЦ Минтранса России» Дашборд Интерактивная аналитическая панель, графический интерфейс. ЕИС Единая информационная система в сфере закупок ЕСИА Единая система идентификации и аутентификации Заказчик Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» КИИ Критическая информационная инфраструктура Кластер Кла?стер (англ. cluster) – объединение нескольких однородных элементов, которое может рассматриваться как самостоятельная единица, обладающая определёнными свойствами Компонент Часть АС, выделенная по определенному признаку или совокупности признаков и рассматриваемая как единое целое (ГОСТ Р 59853-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения») Контракт Контракт на выполнение работ по развитию и оказанию услуг по технической поддержке Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК в 2026 году, заключаемый по результатам проведения конкурентной процедуры закупки в соответствии с требованиями Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» ... 1. ОБЩИЕ СВЕДЕНИЯ – постановление Правительства Российской Федерации от 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 Федерального закона «Об электронной подписи»; ... 2. ЦЕЛИ И НАЗНАЧЕНИЕ ВЫПОЛНЕНИЯ РАБОТ 2.1. Назначение АСУ ТК АСУ ТК предназначена для автоматизации и информационно-аналитического обеспечения процессов управления развитием транспортного комплекса Российской Федерации, обеспечения публичности деятельности органов государственного управления транспортным комплексом. Основными целями АСУ ТК являются: – повышение эффективности процессов управления функционированием и развитием транспортного комплекса на основе создания единой информационной среды и комплекса информационно-аналитических услуг на уровне органов государственного управления ТК; – повышение уровня безопасности ТК на базе получения полной, достоверной и оперативной информации о происходящих изменениях, своевременного выявления негативных тенденций и для принятия соответствующих мер по их устранению и ликвидации последствий ... - Условная единица - 1,00 - 20 805 211,56 - 20 805 211,56

- Наименование характеристики Значение характеристики Единица измерения характеристики Инструкция по заполнению характеристик в заявке ОПРЕДЕЛЕНИЯ, ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ Автоматизированная система (АС) Система, состоящая из комплекса средств автоматизации, реализующего информационную технологию выполнения установленных функций, и персонала, обеспечивающего его функционирование (ГОСТ Р 59853-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения») АРМ Автоматизированное рабочее место АСУ ТК, Система Информационно-аналитическая система регулирования на транспорте АТС Автоматическая телефонная станция БД База данных ГИС Государственная информационная система ГОСТ Государственный стандарт ГЦОД СИЦ Минтранса России, ГЦОД Головной центр обработки данных ФГБУ «СИЦ Минтранса России» Дашборд Интерактивная аналитическая панель, графический интерфейс. ЕИС Единая информационная система в сфере закупок ЕСИА Единая система идентификации и аутентификации Заказчик Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» КИИ Критическая информационная инфраструктура Кластер Кла?стер (англ. cluster) – объединение нескольких однородных элементов, которое может рассматриваться как самостоятельная единица, обладающая определёнными свойствами Компонент Часть АС, выделенная по определенному признаку или совокупности признаков и рассматриваемая как единое целое (ГОСТ Р 59853-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения») Контракт Контракт на выполнение работ по развитию и оказанию услуг по технической поддержке Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК в 2026 году, заключаемый по результатам проведения конкурентной процедуры закупки в соответствии с требованиями Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» Значение характеристики не может изменяться участником закупки Модуль iМинтранс Модуль сбора данных и представления показателей деятельности Министерства транспорта Российской Федерации iМинтранс АСУ ТК Модуль СЦ Модуль сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК НС Нештатная ситуация НСИ Нормативно-справочная информация ОТИ Объект транспортной инфраструктуры П-ГИС Геоинформационная подсистема П-ИВ Подсистема информационного взаимодействия П-НСИ Подсистема ведения нормативно-справочной информации и метаданных ПО Программное обеспечение Подрядчик, Исполнитель Организация, с которой будет заключен контракт на выполнение работ по развитию Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК П-СД Подсистема сбора данных Работы Работы по развитию Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК СЗИ Средство защиты информации СМЭВ Система межведомственного электронного взаимодействия СУБД Система управления базами данных ТЗ Техническое задание (настоящий документ) ТС Транспортное средство ТК Транспортный комплекс Учреждение Учреждения в области информационной безопасности ФГБУ «СИЦ Минтранса России» Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации», Заказчик Федеральный закон № 44-ФЗ Федеральный закон от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» ФЗ Функциональная задача ФЗ «Реестр объектов» Функциональная задача «Формирование и ведение единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации» ФСБ России Федеральная служба безопасности Российской Федерации ФСТЭК России Федеральная служба по техническому и экспортному контролю ЧС Чрезвычайная ситуация ЭВМ Электронно-вычислительная машина API От англ. Application Programming Interface – интерфейс прикладного программирования – совокупность инструментов и функций в виде интерфейса для взаимодействия с программой CSS От англ. Cascading Style Sheets — каскадные таблицы стилей FPS От англ. frame per second - количество кадров в секунду HTML От англ. HyperText Markup Language - стандартный язык разметки документов, создающий основу и структуру всех веб-страниц JSON От англ. JavaScript Object Notation – текстовый формат обмена данными, основанный на JavaScript WebAssembly (Wasm) Открытый стандарт, представляющий собой низкоуровневый бинарный формат инструкций, который позволяет выполнять код, написанный на языках C++, Rust или Go, в браузерах с производительностью, близкой к нативной 1. ОБЩИЕ СВЕДЕНИЯ – постановление Правительства Российской Федерации от 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 Федерального закона «Об электронной подписи»; Значение характеристики не может изменяться участником закупки – постановление Правительства Российской Федерации от 08.06.2011 № 451 «Об инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг и исполнения государственных и муниципальных функций в электронной форме»; – постановление Правительства Российской Федерации от 30.01.2013 № 62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин»; – приказ ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации»; – приказ ФСТЭК России от 11.04.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений»; – приказ ФСБ России от 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 «Национальный стандарт Российской Федерации. Интеллектуальная собственность. Патентные исследования. Содержание и порядок проведения»; 1.1. Наименование Системы Полное наименование системы: Информационно-аналитическая система регулирования на транспорте. Условное обозначение системы: АСУ ТК. Полное наименование модуля: Модуль сбора, ведения и анализа информации о нештатных ситуациях на транспорте. Условное обозначение модуля: Модуль СЦ. Модуль СЦ создан в рамках контракта от 05.08.2024 № ОК/24_04 на выполнение работ по развитию АСУ ТК в части создания модуля «Сбора, ведения и анализа информации о нештатных ситуациях на транспорте». Развитие Модуля СЦ осуществлено в рамках контракта от 19.05.2025 № ОК/25_09 на выполнение работ по развитию Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК – ГОСТ Р 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.7. Сроки начала и окончания работ Начало работ: с даты заключения Контракта. Окончание работ: не позднее 15.12.2026. Работы выполняются в соответствии с этапами. Сроки выполнения этапов работ по развитию и технической поддержке Модуля СЦ определяются Календарным планом. Календарный план, приведен в разделе 5 настоящего ТЗ 1.2. Шифр темы или номер контракта Присваивается Заказчиком по результатам организации закупочных процедур. 1.2.1. Предмет контракта Выполнение работ по развитию Модуля СЦ. Код по ОКПД2: 62.01.11.000 – услуги по проектированию и разработке информационных технологий для прикладных задач и тестированию программного обеспечения. Оказание услуг по технической поддержке Модуля СЦ. Код по ОКПД2: 62.02.30.000 – услуги по технической поддержке информационных технологий. Выполнение работ по развитию Модуля СЦ предусмотрено с учетом ключевых результатов (ОКР) Ведомственной программы цифровой трансформации Минтранса России на 2026-2028 (далее - ВПЦТ Минтранса России) в составе мероприятия № 103.002 «АСУ ТК» ИТ расхода 103.26.000005 «Развитие Информационно-аналитической системы регулирования на транспорте (АСУ ТК)»: · «Обеспечено информационное взаимодействие с Минобороны о происшествиях на транспортных объектах»; · «Обеспечена автоматизация формирования отчетов о нештатных ситуациях на транспорте, в том числе по данным внешних систем». Выполнение работ по технической поддержке АСУ ТК предусмотрено ВПЦТ Минтранса России в составе мероприятия № 103.002 «АСУ ТК» ИТ расхода 103.26.000021 «Эксплуатация Информационно-аналитической системы регулирования на транспорте (АСУ ТК)» 1.3. Заказчик Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» (ФГБУ «СИЦ Минтранса России»). Адрес: 107078, Москва, Садовая-Спасская ул., д.18, стр. 1. Оператором Системы является Заказчик - Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» (ФГБУ «СИЦ Минтранса России) 1.4. Подрядчик Определяется по результатам проведения конкурентной процедуры закупки в соответствии с требованиями Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (далее – Федеральный закон № 44-ФЗ) 1.5. Основания для выполнения работ Работы осуществляются на основании следующих документов: – постановление Правительства Российской Федерации от 30.12.2003 № 794 «О единой государственной системе предупреждения и ликвидации чрезвычайных ситуаций»; – постановление Правительства Российской Федерации от 08.11.2013 № 1007 «О силах и средствах единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций»; – распоряжение Правительства Российской Федерации от 27.11.2021 № 3363-р «О Транспортной стратегии Российской Федерации до 2030 года с прогнозом на период до 2035 года»; – Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 26.08.2025 №ЕФ-3; – Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 27.11.2025 №ЕФ-23; 1.8. Общие сведения об источниках и порядке финансирования работ Источником финансирования являются средства субсидии федерального бюджета Российской Федерации, предоставленной в соответствии с абзацем вторым пункта 1 статьи 78.1 Бюджетного кодекса Российской Федерации (код цели 08-01) 1.9. Порядок оформления и предъявления результатов работ Подрядчик должен передать Заказчику результаты работ в порядке, определенном Контрактом в сроки, установленные п. 5 настоящего ТЗ, в соответствии с Календарным планом 1.10. Место выполнения Работ Работы выполняются удаленно на комплексе технических средств Заказчика. Адрес размещения комплекса технических средств Заказчика: Московская обл., Богородский район, пос. Горбуша, Радиоцентр. Техническая возможность удаленного подключения обеспечивается Заказчиком (в части предоставления параметров доступа). Оплата телематических и иных услуг, технических и программных средств, необходимых Подрядчику для удаленного подключения и для выполнения требований по информационной безопасности, осуществляется Подрядчиком самостоятельно за свой счет – Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 19.02.2026 №ЕФ-1; – План мероприятий по профилактике случаев непроизводственного травматизма граждан на железнодорожном транспорте, являющийся приложением к постановлению коллегии Министерства транспорта Российской Федерации от 11.03.2026 № 2 1.6. Перечень документов, требования которых должны быть учтены при выполнении работ – Федеральный закон Российской Федерации от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации»; – Федеральный закон Российской Федерации от 27.07.2006 № 152-ФЗ «О персональных данных»; – Федеральный закон Российской Федерации от 06.04.2011 № 63-ФЗ «Об электронной подписи»; – Федеральный закон Российской Федерации от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации»; – Указ Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации»; – Указ Президента Российской Федерации от 01.05.2022 № 250 «О дополнительных мерах по обеспечению информационной безопасности Российской Федерации»; – Указ Президента Российской Федерации от 31.03.2010 № 403 «О создании комплексной системы обеспечения безопасности населения на транспорте»; – постановление Правительства Российской Федерации от 30.07.2004 № 395 «Об утверждении Положения о Министерстве транспорта Российской Федерации»; – постановление Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации»; – постановление Правительства Российской Федерации от 16.11.2015 № 1236 «Об установлении запрета на допуск программного обеспечения, происходящего из иностранных государств, для целей осуществления закупок для обеспечения государственных и муниципальных нужд»; – постановление Правительства Российской Федерации от 23.12.2024 № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц»; 2. ЦЕЛИ И НАЗНАЧЕНИЕ ВЫПОЛНЕНИЯ РАБОТ 2.1. Назначение АСУ ТК АСУ ТК предназначена для автоматизации и информационно-аналитического обеспечения процессов управления развитием транспортного комплекса Российской Федерации, обеспечения публичности деятельности органов государственного управления транспортным комплексом. Основными целями АСУ ТК являются: – повышение эффективности процессов управления функционированием и развитием транспортного комплекса на основе создания единой информационной среды и комплекса информационно-аналитических услуг на уровне органов государственного управления ТК; – повышение уровня безопасности ТК на базе получения полной, достоверной и оперативной информации о происходящих изменениях, своевременного выявления негативных тенденций и для принятия соответствующих мер по их устранению и ликвидации последствий Значение характеристики не может изменяться участником закупки Основными задачами АСУ ТК являются: – автоматизация процессов прогнозирования развития транспортного комплекса и поддержки принятия управленческих решений; – автоматизация процессов мониторинга безопасности и устойчивости транспортного комплекса, управления в чрезвычайных и нештатных ситуациях; – автоматизация процессов управления программами и проектами развития и модернизации транспортного комплекса; – автоматизация процессов мониторинга состояния транспортного комплекса, в том числе с использованием набора ключевых показателей эффективности деятельности транспортного комплекса; – информационно-технологическая поддержка взаимодействия субъектов транспортного комплекса Российской Федерации, органов государственного управления и контроля, международных организаций на основе создания единой технологической среды взаимодействия и управления движением данных (и связанных с ними документов) в транспортном комплексе; – использование в процессах управления транспортным комплексом РФ современных технологий электронного документооборота и электронного обмена данными; – организация межведомственного электронного взаимодействия подразделений Министерства транспорта Российской Федерации, подведомственных агентств и службы с другими организациями 2.2. Назначение и цели развития и технической поддержки Модуля СЦ Назначение Модуля СЦ: – оперативный мониторинг нештатных и чрезвычайных ситуаций на транспорте ; – оповещение заинтересованных лиц и структур о нештатных и чрезвычайных ситуациях; – сбор, обработка и хранение данных о нештатных и чрезвычайных ситуациях. Целями развития Модуля СЦ являются: – расширение состава данных об оперативной обстановке на транспорте; – оптимизация процесса сбора данных об оперативной обстановке на транспорте; – повышение информированности пользователей за счет визуализация данных Модуля СЦ; – автоматизация процесса формирования отчетов о ЧС и нештатной ситуации на транспорте; – обеспечение информационного взаимодействия с заинтересованными организациями по вопросам ведения. Целями оказания услуг по технической поддержке являются: – обеспечение информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы; – поддержание параметров функционирования ППО Системы, удовлетворяющих требованиям производственных процессов, включая их непрерывность; – обеспечение бесперебойного функционирования ППО и своевременное устранение сбоев и аварийных ситуаций в Системе; – своевременное устранение уязвимостей при выявлении таковых, в соответствии с требованиями к обеспечению информационной безопасности; – адаптация, конфигурирование, коррекция программного обеспечения в соответствии с изменениями нормативно-правовой базы и запросами уполномоченных сотрудников органов государственной власти, включая выполнение процедур тестирования и участие в обновлениях ППО на стендах Заказчика; – обеспечение сохранения работоспособности ППО в изменяемой среде эксплуатации; – ведение документации по настоящему ТЗ, инициирование и актуализация документации на Систему по результатам обработки запросов Заказчика и внесении соответствующих изменений в ППО. Модуль СЦ применяется в деятельности Министерства транспорта Российской Федерации, подведомственных агентств и службы и другими организациями в соответствии с соглашениями об информационном обмене 3. ХАРАКТЕРИСТИКА ОБЪЕКТА АВТОМАТИЗАЦИИ Таблица 1 – Перечень платформенных решений и функциональных задач АСУ ТК № Наименование подсистемы/ функциональной задачи/ модуля Назначение 1 Подсистема сбора данных и централизованного хранилища данных Подсистема обеспечивает выполнение сбора данных в АСУ ТК, и в т. ч., в рамках функциональных задач «Формирование и ведение межрегионального транспортного баланса пассажирских перевозок в дальнем (межрегиональном) сообщении» и «Формирование и ведение транспортного паспорта региона» 2 Подсистема информационного взаимодействия Подсистема информационного предназначена для обеспечения информационного взаимодействия подсистем АСУ ТК, а также, взаимодействия АСУ ТК с АС федеральных органов исполнительной власти 3 Подсистема ведения нормативно-справочной информации и метаданных Подсистема предназначена для автоматизации функций формирования и актуализации справочников, классификаторов, реестров и регистров, необходимых для обеспечения информационной поддержки пользователей НСИ и интеграции подсистем АСУ ТК в части применения НСИ 4 Модуль СМЭВ Модуль взаимодействия со СМЭВ представляет собой набор сервисов взаимодействия: сервис синхронного взаимодействия и сервис отправки, осуществляющих дополнительную обработку сообщений, отправляемых в СМЭВ и принимаемых из СМЭВ 5 Геоинформационная подсистема Программное обеспечение геоинформационной подсистемы предназначено для обеспечения смежных подсистем АСУ ТК возможностью работы с картографической информацией, в том числе, отображения на электронных картах объектов транспортной инфраструктуры и получения информации о местоположении, характеристиках контролируемых транспортных объектов 6 Подсистема информационного портала АСУ ТК Подсистема информационного портала предназначена для отображения и входа в функциональные задачи АСУ ТК 7 Подсистема технического портала АСУ ТК Подсистема технического портала АСУ ТК предназначена для управления заявками пользователей и технологического документооборота заявок Значение характеристики не может изменяться участником закупки 8 Подсистема проектного архива АСУ ТК Подсистема проектного архива АСУ ТК предназначена для автоматизации деловых процессов должностных лиц Министерства транспорта Российской Федерации, подведомственных агентств и службы, в том числе, и процессов информационного взаимодействия внутреннего и внешнего характера 9 ФЗ «Реестр объектов» Функциональная задача предназначена для формирования и ведения единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации 10 ФЗ «СТП» Функциональная задача предназначена для организации информационно-аналитической поддержки процессов территориального планирования Российской Федерации в области федерального транспорта 11 ФЗ «МРТБ ПП» Функциональная задача предназначена для формирования и ведения межрегионального транспортного баланса пассажирских перевозок в дальнем (межрегиональном) сообщении 12 ФЗ «МДД» Функциональная задача предназначена для осуществления мониторинга дорожного движения 13 ФЗ «ТПР» Функциональная задача предназначена для формирования и ведения транспортного паспорта региона 14 ФЗ «Данные по грузообороту» Функциональная задача предназначена для обеспечения подсистем и пользователей АСУ ТК данными по грузообороту между Российской Федерацией и зарубежными странами 15 ФЗ «МЖТ» Функциональная задача предназначена для осуществления мониторинга железнодорожного транспорта 16 ФЗ «МГМП» Функциональная задача предназначена для осуществления мониторинга грузопотоков в морских портах с целью формирования единой цифровой среды мониторинга и планирования перевозок в/из портов Дальнего Востока 17 Модуль ГЭТ Модуль предназначен для получения, хранения данных инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по отдельно взятому предприятию-перевозчику. Формирования отчетов об инвентаризации с детальными данными по каждому разделу инвентаризации с маршрутизацией в муниципалитет / регион / Минтранс. Содержит агрегированные данные инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по всем перевозчикам, относящихся к данному муниципалитету. Формирует сводный отчет по муниципалитету по каждому разделу инвентаризации с маршрутизацией в регион / Минтранс. Формирует агрегированные данные инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по всем перевозчикам, относящиеся к данному региону и по всем муниципалитетам, относящимся к данному региону. Аналитические и статистические данные о состоянии ГЭТ региона. Содержит данные о видах транспорта, цифровых транспортных сервисах и платежных инструментах Региона. Формирует сводный отчет по каждому разделу инвентаризации с маршрутизацией в Минтранс. Формирует агрегированную статистику и аналитику по всем регионам страны в разрезе транспортных средств, маршрутов, пассажиропотоков, инфраструктуры ГЭТ. Данные о рейтинге регионов и перевозчиков на основании выбранных параметров, документооборот с участниками Системы: получение подписанных печатных форм, их утверждение, возврат на доработку. 18 Модуль iМинтранс Модуль создан для отчета по ключевым показателям транспортного комплекса России (Отраслевые и статистические показатели, исполнение бюджета, исполнение поручений, аналитика СМИ, происшествия по видам транспорта). 19 Модуль СЦ Модуль СЦ предназначен для оперативного мониторинга нештатных ситуаций транспортной отрасли, оповещения заинтересованных лиц и структур и предоставления данных о нештатных ситуациях АСУ ТК осуществляет идентификацию и авторизацию посредством Единой системы идентификации и аутентификации (ЕСИА). Информационный обмен с внешними информационными системами осуществляется посредством СМЭВ 3 и СМЭВ 4. АСУ ТК развернута на вычислительных мощностях ГЦОД СИЦ Минтранса России 3.2. Описание и текущее состояние объекта автоматизации Модуля СЦ Объектом автоматизации является процесс организации мониторинга информации о НС и ЧС на транспорте. Предметом деятельности Учреждения являются следующие функции: – информационное обеспечение в области транспортной безопасности, защиты населения и территорий от чрезвычайных ситуаций природного и техногенного характера в транспортном комплексе; – подготовка справочных материалов при угрозе возникновения и возникновении чрезвычайных ситуаций и иных происшествий в транспортном комплексе; – взаимодействие и обмен оперативной информацией с органами управления Единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций; – организация оперативного мониторинга обстановки на объектах транспорта при угрозе и возникновении чрезвычайных ситуаций и иных происшествий. Перечень компонентов Модуля СЦ и выполняемые ими функции представлены в Таблице 2 Таблица 2. Перечень компонентов Модуля СЦ и их функции № п/п Компонент Выполняемые функции 1 Регистрация событий – ведение карточки события; – удаление комментария; – динамическое отображение существующих событий в заданном радиусе и за заданный период; – возможность автоматической проверки вводимых данных в части количества пострадавших; – отображение карточки ОТИ, ТС в соответствии с ФЗ Реестр объектов; – сохранение и отображение версии карточки события; – привязка события к координатам по картографической основе; – указание признака выполнения действия по отработке события; – перевод статуса события; – закрытие карточки события; – публикация информации о событии в канале мессенджера; – возможность перехода из карточки события на картографическую основу для просмотра местоположения события 2 Визуализация – отображение событий на картографической основе в виде пиктограмм; – масштабирование карты; – отображение краткой карточки события при выборе события на картографической основе; – отображение списка событий; – отображение карточки события; – отображение журнала действий пользователя; – отображение дополнительной информации (текстовая информация и приложенные файлы); – отображение справки о событиях и отчета о событиях; – отображение фильтров и количества отфильтрованных объектов; – отображение результатов поиска; – отображение статистики по событиям на экране; – возможность создания события с картографической основы; – отображения картографических слоев в зависимости от примененных фильтров; – возможность настройки шага картографической сети; – возможность настройки географической точки центра карты; – отображение количества непрочитанных сообщений; – возможность перехода к детальной карточке события из краткой карточки события при выборе события на картографической основе 3 Информирование – ведение справочника способов оповещения (веб-интерфейс, мессенджер); – формирование сценария выполнения оповещения (настройка условий, способа, параметров оповещения); – выполнение оповещений пользователей 4 Отчетность – формирование отчета и справки о событиях; – фильтрация событий для выгрузки в справку о событиях или в отчет о событиях 5 Администрирование – ведение ролей пользователей; – ведение учетных данных пользователей; – ведение справочника организаций; – ведение справочника групп системы мгновенного обмена сообщениями; – выполнение исходящего звонка на контактный телефонный номер организации; – формирование матрицы эскалации событий Архитектура Модуля СЦ представлена на рисунке 1. Рисунок 1. Архитектура Модуля СЦ 3.3. Состав используемого ПО Модуля СЦ Программная архитектура Модуля СЦ разработана как трехуровневая клиент-серверная архитектура. Архитектура включает в себя следующие уровни: • уровень представления – презентационный уровень, обеспечивающий взаимодействие с пользователя с клиентскими приложениями с использованием веб-браузера («тонкий» клиент); • уровень приложений – реализован в виде сервисов, обеспечивает обработку запросов, поступающих от клиентских приложений, формирование ответов на запрос в доступном пользователю виде (формирование пользовательских интерфейсов); • уровень хранения данных – реализуется как сервер БД и обеспечивает хранение и целостность хранимых данных, создание резервных копий, ведение журнала транзакций, восстановление данных после сбоев. Программная архитектура Модуля СЦ включает в себя сервисы и интерфейсы, указанные в Таблице 3. Таблица 3. Программная архитектура Модуля СЦ Программный сервис/интерфейс Технологии реализации Уровень представления Интерфейс пользователя и администратора (front-end) Javascript Уровень приложений Сервис (GateWay) Kotlin Сервис геокодирования (geocoding-service) Kotlin Сервис уведомлений (notifiсation-service) Kotlin Сервис работы с файлами (file-service) Kotlin Сервис отчетности (report-service) Kotlin Сервис управления событиями (event-service) Kotlin Сервис информирования через мессенджер (messenger-notifier) Python Сервис внешних интеграций (integration-service) Сбор информации из внешних систем и сервисов Брокер сообщений Kafka Уровень хранения данных Файловое хранилище MinIO S3 СУБД Postgres Pro Enterprise 3.4. Информационное взаимодействие программных сервисов и интерфейсов Модуля СЦ Объект автоматизации функционирует в распределенной информационной среде. Обмен данными осуществляется по защищенным каналам связи (в том числе ведомственным сетям передачи данных). Источники информации включают: · внешние автоматизированные системы (органов государственной власти); · внутренние базы данных (реестры объектов транспортной инфраструктуры, паспорта регионов и пр.); · оперативная информация от персонала, поступающая через автоматизированные рабочие места (АРМ) и мобильные устройства. 3.4.1. Взаимодействие Модуля СЦ со смежными подсистемами АСУ ТК Модуль СЦ входит в состав АСУ ТК и взаимодействует со следующими ее функциональными задачами и подсистемами: · Функциональной задачей «Формирование и ведение единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации» (ФЗ «Реестр объектов»); · Геоинформационной подсистемой АСУ ТК (П-ГИС); · Подсистемой ведения нормативно-справочной информации и метаданных (П-НСИ); · Подсистемой сбора данных и централизованное хранилище данных (П-СД); · Подсистемой информационного взаимодействия (П-ИВ). 3.4.2. Взаимодействие с внешними информационными системами Список внешних информационных систем, с которыми осуществляется взаимодействие Модуля СЦ: · ЕСИА; · мессенджер; · Яндекс Геокодер; · Информационная система «Централизованная система сбора информации систем-112»; · ПВК «Поиск-Море», АИС РПТ; · облачная АТС 3.5. Требования к эксплуатации Применяемое в Системе программное обеспечение, программно-аппаратные и аппаратные комплексы должны соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации» 3.1. Описание объекта автоматизации АСУ ТК Объектом автоматизации являются процессы основной и обеспечивающей деятельности, направленные на управление транспортным комплексом, в том числе, процессы информационного взаимодействия с другими организациями и субъектами транспортного комплекса. АСУ ТК относится к государственным информационным системам, а также к информационным системам персональных данных и значимым объектам критической информационной инфраструктуры Российской Федерации. АСУ ТК соответствует требованиям, предъявляемым к: – ГИС второго класса защищенности в соответствии с приказом ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах»; – ИС персональных данных при обеспечении третьего уровня защищенности персональных данных в соответствии с требованиями постановления Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»; – значимым объектам КИИ Российской Федерации второй категории значимости с постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении Правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений». Модуль СЦ является подсистемой АСУ ТК. Перечень платформенных решений и функциональных задач АСУ ТК представлен в Таблице 1 4. ТРЕБОВАНИЯ К МОДУЛЮ СЦ 4.2.4. Создание компонента «Интерактивная карта» (2 очередь) В составе создаваемого компонента должны отображаться данные, доступные в компоненте визуализации. Требования к интерфейсу интерактивной карты: – интерактивная карта должна быть представлена в виде объемной карты с учетом макетов, представленных в Приложении А к ТЗ; – интерфейс должен корректно отображаться на экранах мониторов (разрешение Full HD 1920?1080), телевизоров (разрешение 4К 3840?2160), жидкокристаллических панелей для видеостены, используемой Заказчиком, с параметрами каждой панели: диагональ 55 дюймов, разрешение 1920x1080; – интерфейс должен корректно отображаться на планшетных устройствах с диагональю экрана 10-12 дюймов, конкретные требования должны быть уточнены на этапе технического проектирования; – должна быть обеспечена кластеризация и генерализация отображения объектов на карте при изменении масштаба; – должно быть обеспечено отображение основных характеристик объектов при выборе их на карте; – должно быть обеспечено управление отображением слоев на карте; – должна быть обеспечена настройка цветовой индикации отображаемых объектов транспортной инфраструктуры; – должно быть обеспечено отображение легенды карты, содержащей отображаемые объекты на карте; – должна быть обеспечена возможность одновременного отображения не менее 5 000 ОТИ и ТС на карте. Значение характеристики не может изменяться участником закупки На интерактивной карте должны быть отображены подвижные объекты совместно с объектами транспортной инфраструктуры (ОТИ), включая следующие возможности: § отображение местоположения транспортных средств (воздушный, водный и автомобильный транспорт) на карте в режиме реального времени (с заданным периодом обновления данных); § отображение маршрутов движения всех ТС за выбранный период времени, в том числе с использованием эффектов анимации; § отображение маршрутов движения ТС, связанных с карточкой события: ТС, являющихся участниками события, и ТС, находящиеся в заданном радиусе от события; § управление отображением сущностей и ОТИ на карте, включая настройку состава отображаемых объектов, поиск, фильтрацию, с использованием соответствующей панели управления и наглядным представлением результатов; § автоматическое изменение вида отображения объектов (цветовая индикация) по заданным условиям (например, при достижении критических значений параметров, характеризующих функционирование объекта); Должна обеспечиваться производительность обновления изображения на экране в 30 кадров в секунду на тестовой конфигурации пользовательского устройства (модель Бештау AIO2402/B560, входящая в Реестр российской промышленной продукции под номером 10394100 или аналог) при одновременном отображении не менее 5 000 объектов и 200 уникальных моделей объектов. Макеты интерфейсов Модуля СЦ должны быть предварительно согласованы с Заказчиком и разработаны с учетом требований ГОСТ Р ИСО 9241-161-2016 «Элементы графического пользовательского интерфейса» Таблица 6. Категории обращений и заявок Категория Примеры Запрос на обслуживание Подготовка SQL запроса к СУБД для решения прикладной задачи и д.р. – запрос на любое действие, не являющееся запросом информации и несовершенный на основе происшествия, прямо или косвенно влияющего на работу Модуля СЦ Консультация «Где взять / куда обратиться...?», «Как сделать / выполнить…», «Как это работает…?» - запрос, имеющий своей целью получение информационной поддержки Инцидент Разбор ошибок/сбоев и подготовка материалов (корректировочных релизов, инструкций) для Заказчика для устранения ошибок/сбоев, которые приводят к частичному и полному нарушению работоспособности всех или отдельных функций ППО. Подготовка изменения и материалов, необходимых для проведения аварийно-восстановительных работ для возобновления работоспособности Модуля СЦ ЗНИ Подготовка изменений, связанных с изменением, улучшением/оптимизацией Модуля СЦ и выводом новой модифицированной функциональности в штатном режиме. Подготовка изменений, связанных с модификацией существующих и/или реализация новых интеграционных механизмов для получения/обработки данных внешних систем. Подготовка изменений графического интерфейса по требованиям Заказчика. Перечень статусов обращений (заявок) приведен в пункте 3.3. Регламента оказания Услуг. Назначение обращению (заявке) статуса «Закрыто» осуществляется Заказчиком только после получения от инициатора обращения (заявки) подтверждения о его исполнении или нахождения обращения (заявки) в статусе «Выполнено» и отсутствия повторных вопросов/запросов по данному обращению (заявки) в течение 5 рабочих дней. Категории и статусы обращений (заявок) могут быть скорректированы в процессе оказания услуг исключительно по согласованию с Заказчиком 4.3.6. Требования к услугам технической поддержки 4.3.6.1. Требования к организации третьего уровня технической поддержки Основными задачами организации третьего уровня технической поддержки в рамках оказания услуг по технической поддержке Модуля СЦ являются организация эксплуатационной службы Подрядчика, проверка готовности технических и программных средств для обеспечения непрерывного функционирования ППО Модуля СЦ. Подрядчиком должны быть проведены организационно-штатные и подготовительные мероприятия (в т. ч. технические) в рамках организации технической поддержки Модуля СЦ. Подрядчик в течение 5 (пяти) рабочих дней с даты заключения Контракта должен: – определить и направить Заказчику документ «Перечень уполномоченных специалистов», содержащий контактную информацию (ФИО, должность, адрес рабочей электронной почты) лиц, ответственных за оказание услуг со стороны Подрядчика; – обеспечить подключение специалистов Подрядчика к Системе регистрации обращений (заявок) (СРО предоставляется Заказчиком) для оказания услуг; – согласовать с Заказчиком способ доступа Подрядчика к Модулю СЦ. Результат выполнения мероприятий фиксируется в Протоколе проверки результатов организационно-штатных и подготовительных мероприятий (см. Приложение Д к настоящему ТЗ) 4.2.4.1. Требования к технической реализации компонента «Интерактивная карта» При реализации компонента «Интерактивная карта» должны учитываться требования, указанные ниже. 4.2.4.1.1. Требования к отображению элементов Повторяющихся элементы карты (ТС, ОТИ, события и пр.) должны отрисовываться с использованием аппаратного создания экземпляров объектов на пользовательском устройстве (WebGL/WebGPU)). Отрисовка каждого объекта отдельным запросом не допускается, должна обеспечиваться возможность одновременного отображения не менее 5 000 объектов без снижения производительности (30 кадров в секунду на тестовой конфигурации). 4.2.4.1.2. Уровни детализации объектов Для управления отображением сложных объектов должно быть создано не менее 3-х уровней детализации, отображаемых при изменении масштаба с возможностью автоматического переключения между уровнями. Все отображаемые объекты должны масштабироваться с учетом разрешения экрана пользователя с сохранением качества детализации. 4.2.4.1.3. Полигональная оптимизация и текстурирование При реализации компонента «Интерактивная карта» должна обеспечиваться технология рельефного тестурирования объектов. Не должны использоваться высокополигональные трехмерные модели. Все повторяющиеся элементы должны генерироваться единоразово и повторно использоваться при последующих отображениях. 4.2.4.1.4. Управление памятью Требуется реализовать потоковую загрузку на устройство пользователя элементов карты и текстур. Загрузка данных целиком при старте приложения не допускается. Необходимо реализовать механизм очистки памяти от элементов, которые находятся вне области видимости камеры в течение заданного времени. 4.2.4.1.5. Требования к взаимодействию пользователя с интерфейсом компонента «Интерактивная карта» Программная реализация механизмов управление камерой (масштабирование и навигация) должна быть выполнена с поддержкой технологии WebAssembly (WASM). Элементы управления должны являться неотъемлемой частью интерактивной карты. 4.2.5. Развитие компонента администрирования (3 очередь) Должна быть выполнена доработка ролевой модели. Ролевая модель должна обеспечивать управление доступом к отдельным объектам Модуля СЦ и их элементам (атрибутам) с разграничением по видам транспорта, регионам и пр., в частности: – определение набора конкретных действий, доступных пользователям (выполняемых над объектом доступа, например, удаление записи, редактирование записи, формирование отчета и др.); – реализация возможности объединения пользователей в группы; – определение прав доступа для групп пользователей; – реализация интерфейса визуальной настройки прав доступа пользователей к объектам Модуля СЦ 4.3.6.2. Требования к услугам информационно-консультационной поддержки работников Заказчика и пользователей Модуля СЦ Услуги информационно-консультационной поддержки сотрудников Заказчика включают: – обработку обращений и заявок, поступивших от сотрудников Заказчика; – консультирование сотрудников Заказчика и пользователей Модуля СЦ; – актуализацию документации, и других материалов по работе с Модулем СЦ при необходимости. – консультирование и разработку рекомендаций по настройке Модуля СЦ (без изменения программного кода), включая изменение настроек функционирования; – консультации по вопросам использования, настройки и возможностям Модуля СЦ; – консультации по проведению превентивных мер для недопущения аварийных ситуаций в Модуле СЦ; – консультации по предварительной диагностике и локализации возникшей неисправности Модуля СЦ; – консультации по вопросам обеспечения информационной безопасности Модуля СЦ и настройки функций, обеспечивающих корректную работу программного обеспечения для совершения юридически значимых действий в Модуле СЦ; – другие вопросы, связанные с работой Модуля СЦ. 4.3.6.2.1. Требования к порядку оказания услуг информационно-консультационной поддержки работников Заказчика и пользователей Модуля СЦ Подрядчик выполняет консультирование сотрудников Заказчика и пользователей Модуля СЦ. Консультация может быть предоставлена по согласованным с представителем Заказчика каналам коммуникации с регистрацией результата консультации в СРО Подрядчиком. Детальный порядок оказания консультационных услуг определен в Регламенте оказания Услуг 4.3.6.3. Требования к услугам по решению инцидентов, связанных с работой ППО Подрядчик устраняет неисправности Модуля СЦ, связанные с работой ППО, выявленные в рамках оказания услуг согласно настоящему Техническому заданию, при этом в зону ответственности Подрядчика не входит устранение неисправностей, выявленных на стороне Заказчика и на стороне третьих лиц (провайдера связи, поставщика электропитания и т.д.). Первичная диагностика выявленной неисправности проводится на 1 и 2 уровнях технической поддержки и не входит в зону ответственности Подрядчика. Если при проведении первичной диагностики и попытке устранить неисправности на 1 и 2 уровнях технической поддержки, данную неисправность устранить не удалось и в процессе диагностики было выявлено, что проблема связана с работоспособностью ППО, обращение (заявка) назначается сотруднику Подрядчика, ответственному за оказание услуг технической поддержки 3 уровня. Инцидентами вне зоны ответственности Подрядчика являются: – работоспособность функциональности, выходящая за рамки текущей реализации функций в Модуле СЦ и/или являющаяся расширением требований Заказчика к функциям Модуля СЦ; – проведение профилактических и плановых работ, согласованных с Заказчиком; – нарушение работоспособности функций Модуля СЦ, вызванное проведением работ на стороне Заказчика 4.2.6. Взаимосвязи с внешними автоматизированными системами (1 очередь) Способы взаимодействия с внешними информационными системами должны быть определены на этапе технического проектирования. Должны быть выполнены следующие доработки: – интеграции с информационными ресурсами в целях получения данных о движении подвижных ТС (воздушные суда, суда водного транспорта); – интеграция с информационным ресурсом в целях получения данных о событиях на железнодорожном транспорте. Реализация интеграций должна включать проектирование и реализацию интеграционных механизмов обмена данными с учетом доступных вариантов реализации, обеспечение защищенных способов взаимодействия, настройку отображения отдельных данных на карте (настройка слоев). Взаимодействия, имеющие каналы связи, выходящие за пределы контролируемой зоны взаимодействующих систем, считаются защищенными, если для их защиты используются программные и/или программно-аппаратные шифровальные (криптографические) средства, сертифицированные ФСБ России (далее – СКЗИ). Выбор СКЗИ, схемы подключения и требуемого класса криптостойкости должен производиться в соответствии с Техническими условиями на подключение к информационным ресурсам ФГБУ «СИЦ Минтранса России» и инструкциями по подключению пользователей к ресурсам инфраструктуры Головного центра обработки данных, утвержденных приказом директора ФБГУ «СИЦ Минтранса России» от 24.05.2024 № 21-ОД 4.3. Требования к оказанию услуг по технической поддержке Модуля СЦ 4.3.1. Общие требования к оказанию Услуг Техническая поддержка Модуля СЦ должна осуществляться с учетом требований постановления Правительства Российской Федерации от 06.07.2015 N 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации». Подрядчик обязан выполнять требования законодательства в сфере защиты информации, требования по защите информации, информационной безопасности, указанные в локальных нормативных актах ФГБУ «СИЦ Минтранса России», регламентирующих условия информационного взаимодействия, защиты информации и подключения к информационным ресурсам ФГБУ «СИЦ Минтранса России», участвующих в информационном взаимодействии в рамках оказания услуг по технической поддержке АСУ ТК в 2026 году 4.3.1.1. Требования к составу и содержанию услуг третьего уровня технической поддержки Оказание услуг по технической поддержке Системы осуществляется в рамках этапов в соответствии с календарным планом. Подрядчик в течение 5 рабочих дней с даты заключения Контракта должен предоставить со своей стороны, а Заказчик со своей стороны Матрицу ответственных за взаимодействия в соответствии с Приложением 1 к Регламенту оказания услуг по третьему уровню технической поддержки Модуля СЦ (далее – Регламент, Приложение В). Подрядчик в течение 10 рабочих дней с даты заключения Контракта должен провести мероприятия по организации третьего уровня технической поддержки в соответствии с Регламентом. Услуги по третьему уровню технической поддержки Модуля СЦ должны включать: – организацию Подрядчиком третьего уровня технической поддержки; – информационно-консультационную поддержку работников Заказчика; – решение инцидентов, связанных с работой ППО; – адаптационное, конфигурационное и коррекционное сопровождение Модуля СЦ (в рамках действующих программных модулей и функциональности); – устранение уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности Работы по устранению неисправности приостанавливаются (по согласованию с Заказчиком) в следующих случаях: – если Подрядчиком в результате диагностики выявлено, что неисправность находится в зоне ответственности Заказчика. Подрядчик информирует Заказчика о выявленной неисправности в зоне его ответственности по согласованным каналам связи; – требуется действие со стороны Заказчика – до момента выполнения данного действия Заказчика. Заказчик информируется о необходимых действиях по согласованным каналам связи; – отсутствие возможности связаться со специалистами Заказчика, участие которых необходимо для устранения неисправности; – требуется доставить оборудование на объект – до момента доставки и установки оборудования. В случаях, представленных выше, время приостановки работ не входит в учет продолжительности устранения неисправности. Учет времени устранения неисправности Подрядчиком считается с момента назначения Инцидента специалисту Подрядчика, ответственному за оказание услуг технической поддержки 3 уровня. Подтверждение необходимости приостановления работ находится в зоне ответственности Подрядчика. Приостановление сроков выполнения задач в соответствии с настоящим пунктом подтверждается Заказчиком по мотивированному обращению Подрядчика в СРО, основанному на данных диагностики или на иных фактических обстоятельствах В случае непринятия Подрядчиком необходимых мер по информированию Заказчика (отсутствие надлежащего обращения от Подрядчика или отсутствие уведомления о необходимости осуществления каких-либо действий Заказчиком) не может являться основанием для приостановления работ по устранению неисправности. В отдельных случаях Подрядчику может потребоваться выполнение технологических работ для устранения причин неисправности или недопущения повторения их в будущем. Для обеспечения устранения неисправности Модуля СЦ Заказчиком проводится классификация в соответствии с приоритетами по степени срочности их устранения. Продолжительность устранения неисправности, а также периодичность информирования Подрядчиком Заказчика о ходе устранения неисправности, определены в Регламенте оказания услуг. При подаче обращения (заявки) наивысшего приоритета через СРО Заказчик должен дополнительно проинформировать службу поддержки Подрядчика о созданном обращении (заявки) по телефону уполномоченного сотрудника Подрядчика. При этом временем подачи обращения (заявки) считается время подачи обращения (заявки) через СРО 4.4.7.1.5. Требования к используемым зависимостям (библиотекам) Все внешние зависимости проекта должны быть зафиксированы с указанием точных версий. Для контроля версий зависимостей в репозиторий обязательно должны быть включены следующие файлы: · Для JavaScript: package-lock.json или yarn.lock; · Для Python: requirements.txt (с зафиксированными версиями) или Pipfile.lock; · Для Go: go.mod и go.sum; Загрузка всех зависимостей должна производиться исключительно через внутренний прокси-репозиторий Заказчика, настроенный в соответствующем системе менеджере пакетов. Запрещается: · Использование плавающих версий (например, ^1.2.3, ~4.5.0, latest); · Использование библиотек, содержащих критические уязвимости, в том числе зарегистрированные в реестре CVE (Common Vulnerabilities and Exposures). 4.4.7.1.6. Требования к процессу непрерывной интеграции (CI) Сборка программного обеспечения, включая этапы компиляции, тестирования и анализа кода, должна выполняться исключительно в инфраструктуре непрерывной интеграции Заказчика. 4.4.7.1.7. Требования к хранению артефактов сборки Все артефакты сборки (результирующие пакеты, Docker-образы и т.д.) подлежат обязательному хранению в предназначенной для этого инфраструктуре Заказчика (артефакторий). Запрещается размещение финальных артефактов сборки на сторонних ресурсах 4.4.8. Требования к техническому обеспечению Количество серверов, подключаемых и настраиваемых сервисов, их параметров, схемы соединений и настройки межсетевого взаимодействия должны быть согласованы с Заказчиком на этапе № 1 Техническое проектирование. Доступ к комплексу технических средств предоставляется Заказчиком по письменному запросу Подрядчика. Применяемые в Системе программно-аппаратные и аппаратные комплексы должны соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации», требованиям Постановления Правительства Российской Федерации от 23 декабря 2024 г. № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц». Модуль СЦ, работающий в составе АСУ ТК, развернут на вычислительных мощностях ГЦОД СИЦ Минтранса России 4.5. Общие технические требования 4.5.1. Требования к численности и квалификации персонала и пользователей Модуля СЦ Программное обеспечение Модуля СЦ не должно требовать изменения штатной численности персонала Заказчика. Программное обеспечение Модуля СЦ не должно требовать наличия у пользователей дополнительной квалификации в сфере информационных технологий, кроме базовых знаний в обращении с персональным компьютером, базовых навыков работы в интернет-обозревателях и знаний о Модуле СЦ в объеме документов Руководство пользователя, Руководство администратора По результатам анализа угроз безопасности информации программного обеспечения и испытаний по выявлению уязвимостей в программном обеспечении Системы должна быть предоставлена отчетная документация по формам, утвержденным в Руководстве, и артефакты сборочной среды, подтверждающие проведение испытаний по выявлению уязвимостей в программном обеспечении Систем. Уязвимости подлежат устранению в сроки, обозначенные Заказчиком. В случае обнаружения уязвимого компонента Подрядчик должен заменить/обновить библиотеки. В случае, если уязвимость не подлежит исправлению на программном уровне, Подрядчик должен разработать меры предотвращения угроз безопасности, в том числе правила безопасности для наложенных средств защиты, рекомендации по безопасной настройке конфигурации для устранения потенциальных уязвимостей и снижения рисков информационной безопасности. Уязвимости, найденные ФСБ России, ФСТЭК России, Минцифры России, Роскомнадзором в ходе исполнения Контракта, а также в течение гарантийного периода, должны быть устранены Подрядчиком за свой счет в сроки, согласованные с Заказчиком 4.5.6. Требования к эргономике и технической эстетике Взаимодействие пользователей с Модулем СЦ должно осуществляться посредством визуального графического интерфейса. Ввод-вывод данных, прием управляющих команд и отображение результатов их исполнения должны выполняться в интерактивном режиме. Интерфейс должен быть рассчитан на преимущественное использование манипулятора типа «мышь», то есть управление Модулем СЦ должно осуществляться с помощью набора экранных меню, кнопок, значков и т. п. элементов. Клавиатурный режим ввода должен использоваться главным образом при заполнении и/или редактировании текстовых и числовых полей экранных форм. Все надписи экранных форм, а также сообщения, выдаваемые пользователю (кроме системных сообщений), должны быть на русском языке. Модуль СЦ должен обеспечивать проверку вводимых пользователем данных и предупреждать о некорректно введённых значениях Экранные формы должны проектироваться с учетом требований унификации: – все экранные формы пользовательского интерфейса должны быть выполнены в едином графическом дизайне, с одинаковым расположением основных элементов управления и навигации; – для обозначения сходных операций должны использоваться сходные графические элементы, кнопки и другие управляющие (навигационные) элементы. Термины, используемые для обозначения типовых операций, а также последовательности действий пользователя при их выполнении должны быть унифицированы; – внешнее поведение сходных элементов интерфейса (реакция на наведение указателя «мыши», переключение фокуса, нажатие кнопки) должно реализовываться одинаково. Структура размещения информации и представление этой структуры в Модуле СЦ должны соответствовать следующим требованиям: – пункты меню в пользовательском веб-интерфейсе должны быть сгруппированы в соответствии с тематикой информации, функциональными задачами и технологией работы; – каждому пункту меню должна соответствовать только одна выполняемая функция; – при совершении пользователями ошибочных действий должны выдаваться сообщения об ошибках. Эскизы визуального оформления компонента «Интерактивная карта» представлены в Приложении А. 4.3.6.3.1. Требования к порядку оказания услуги по решению инцидентов, связанных с работой ППО При поступлении от Заказчика обращения (заявки), являющегося неисправностью в работе Модуля СЦ (инцидентом), Исполнитель реагирует на инцидент в СРО в срок не более 30 минут с момента поступления. В случае необходимости, для решения инцидента ответственный специалист должен связаться с инициатором обращения (заявки) для уточнения условий воспроизведения проблемы или для получения дополнительных сведений. После получения необходимых сведений от инициатора обращения (заявки) ответственный специалист производит диагностику с целью выявления причины инцидента и возможных путей устранения. В случае, если инцидент невозможно решить без получения дополнительных сведений от инициатора, и не удается связаться с инициатором в течение пяти рабочих дней, обращение (заявка) отклоняется в связи с недостатком данных для его решения, Заказчику направляется уведомление об отклонении обращения (заявки). Время, в течение которого невозможно связаться с инициатором, вычитается из общего времени обработки обращения (заявки). Все попытки связаться с инициатором должны фиксироваться с указанием даты и времени попытки, используемого способа связи (номер телефона, адрес электронной почты) и результата попытки (не удалось дозвониться, абонент недоступен, и т.д.) Факт и время решения инцидента должны быть зафиксированы и отражены в СРО. В случае, если причиной сбоя в работе Модуля СЦ является выход из строя аппаратного обеспечения или неработоспособность смежной информационной системы, время работы над инцидентом приостанавливается до момента устранения неисправности. В ходе решения инцидентов могут быть выявлены дефекты ППО Модуля СЦ. В случае обнаружения дефектов ППО, Подрядчик информирует об этом Заказчика. Исполнитель может быть привлечен к проверке результата устранения дефекта по инициативе Заказчика. Приоритеты инцидентов приведены в Приложении Б к ТЗ. Детальный порядок оказания услуги по решению инцидентов, связанных с работой ППО Модуля СЦ определен в Регламенте оказания Услуг 4.3.6.4. Требования к услугам адаптационного, конфигурационного и коррекционного сопровождения и доработки Модуля СЦ (в рамках действующих программных модулей и функциональностей) Услуги адаптационного, конфигурационного и коррекционного сопровождения и доработки Модуля СЦ включают: – управление изменениями и адаптация функций Модуля СЦ; – изменение настроек функционирования Модуля СЦ; – внесение изменений и/или модификаций Модуля СЦ (в рамках действующих программных модулей и функциональностей), направленных на улучшение их работоспособности и функциональных возможностей; – подготовка и передача Заказчику SQL запросов в СУБД для получения агрегированной информации из Модуля СЦ, которую невозможно получить с использованием графического пользовательского интерфейса; – адаптация модулей интеграций со смежными информационными системами 4.3.6.4.1. Требования к проведению изменений Основанием для внесения изменений является запрос от Заказчика. Все активности по внесению изменений должны быть согласованы с Заказчиком, а действия Подрядчика при оказании данной услуги должны быть зафиксированы. В рамках данного Технического задания изменениями считаются локальные доработки функционала Модуля СЦ, которые не должны приводить к необходимости выполнения дополнительных аттестационных испытаний или переаттестации АСУ ТК в соответствии с п. 33 приказа от 29.04.2021 № 77 «Об утверждении Порядка организации и проведения работ по аттестации объектов информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну». При необходимости внесения изменений в Модуль СЦ, не связанных с критичным инцидентом, существенно нарушающим работоспособность Модуля СЦ, Заказчик направляет Подрядчику обращение (заявку), в котором излагает суть изменения, которое требуется внести в Модуль СЦ. Исполнитель, в течение 3 (трех) рабочих дней с момента поступления соответствующего обращения (заявки), оценивает техническую возможность реализации запрашиваемого изменения и варианты реализации. По итогу проведения оценки Подрядчик направляет Заказчику заключение о возможности реализации данного изменения с описанием возможных вариантов реализации и согласует с Заказчиком проведение данного изменения При проведении работ по изменению и адаптации Подрядчик должен: – обеспечить выполнение требований безопасной разработки программного обеспечения; – обеспечить предварительное проектирование технических решений и согласование с Заказчиком проекта реализации изменения; – использовать семантическое версионирование (SemVer) в работе, передать Заказчику все артефакты разработки (исходный код и сторонние библиотеки, конфигурации, сборочные и собранные образы и др.); – подготовить полноценное описание функционала, включенного в релиз, с необходимыми схемами и пояснениями к обновлению на стендах Заказчика; – обеспечить тестирование разработанного функционала на стендах Заказчика силами Подрядчика; – решение о переносе измененного ППО на продуктивный стенд принимается Заказчиком по итогу результатов проведенного тестирования; – обеспечить техническое сопровождение процедуры тестирования ППО и переноса измененного ППО на продуктивный стенд Заказчика; – обеспечить экстренное внесение соответствующих изменений в случае выявления некорректной работы продуктивного стенда Заказчика после проведения обновления по итогам разработанного изменения в кратчайшие сроки; – актуализировать при необходимости комплект эксплуатационной документации: o руководство пользователя; o руководство администратора; o иные документы (при необходимости). Результат выполнения изменений должен быть отражен в Отчете по оказанию услуг. Типы и приоритеты изменений могут быть скорректированы в процессе оказания услуг исключительно по согласованию с Заказчиком 4.5.2. Требования к режимам функционирования Модуля СЦ Модуль СЦ должен предусматривать наличие следующих режимов работы: – штатный; – регламентный (профилактический); – аварийный. Основным режимом функционирования является штатный. В штатном режиме все компоненты корректно и полностью выполняют свои функции. Перерывов в работе как Модуля СЦ в целом, так и одного, либо нескольких компонентов не предусмотрено. Режим регламентного (профилактического) обслуживания предназначен для проведения работ по обновлению и техническому обслуживанию компонентов Модуля СЦ, а также резервному копированию данных. При работе в данном режиме допускаются перерывы в работе Модуля СЦ с предварительным информированием пользователей. Состав процедур по регламентному обслуживанию Модуля СЦ и их периодичность определяются Подрядчиком в процессе выполнения работ по созданию Модуля СЦ. В режиме регламентного (профилактического) обслуживания Модуль СЦ может функционировать с частичным ограничением своих функциональных возможностей, либо без ограничения, но со снижением показателей надежности и производительности. Перевод в данный режим работы должен осуществляться сразу после начала выполнения любой операции, отнесенной к этому режиму, с последующим возвратом в штатный режим функционирования сразу после ее завершения. Перевод в указанный режим должен осуществляться при возникновении необходимости проведения работ по обновлению и техническому обслуживанию компонентов Модуля СЦ, а также резервному копированию данных с условием предварительного оповещения пользователей. Аварийный режим функционирования характеризуется отказом одной или нескольких подсистем, вызванных выходом из строя аппаратного и/или программного обеспечения, а также в случае временной неработоспособности каналов связи между серверами. В аварийном режиме осуществляется поиск неисправностей и проведение работ по их устранению. Перевод в аварийный режим должен осуществляться при возникновении сбоев, аварий и прочих незапланированных воздействий, сразу после наступления одной или нескольких аварийных ситуаций, с последующим возвратом в штатный режим функционирования сразу после окончания восстановительных работ. ПО Модуля СЦ должно обладать надежностью, обеспечивающей работу пользователей в произвольном режиме и оперативное восстановление работоспособности при сбоях. В целях обеспечения надежного функционирования ПО должно предусматривать: – сохранение целостности данных при нештатном завершении работы компонентов Модуля СЦ; – сохранение работоспособности программного обеспечения при некорректных действиях пользователя; – резервное копирование базы данных Модуля СЦ. – время восстановления работоспособности Модуля СЦ после отказа не более 4 часов. – отказоустойчивость на уровне 99% при единовременной количестве не менее 200 пользовательских сессий в Модуле СЦ. Указанные характеристики приведены без учета характеристик надежности инфраструктуры и времени передачи информации по каналам связи. При возникновении сбоев в аппаратном обеспечении, включая аварийное отключение электропитания, Модуль СЦ должен автоматически восстанавливать свою работоспособность (не требовать перенастройки) после устранения сбоев и корректного перезапуска аппаратного обеспечения 4.5.7. Требования по сохранности информации при авариях В случае возникновения аварии или сбоя в процессе выполнения пользовательских задач должно быть обеспечено восстановление баз данных до состояния на момент последней завершенной Модулем СЦ транзакции, и структуры файлового хранилища. Все аварийные ситуации должны обрабатываться программно с выдачей соответствующих сообщений, с корректной обработкой ситуации (завершение транзакций, закрытие файлов и т.п.), без потери обрабатываемой информации. В Модуле СЦ должны быть предусмотрены меры, обеспечивающие целостность данных в случае отказа программного обеспечения или аппаратных средств, исключая случаи физического уничтожения носителя или нарушения функциональности носителя, операционной системы или СУБД по вине их производителя либо обслуживающего персонала. Используемые аппаратные и системные платформы должны обеспечивать сохранность и целостность информации в Модуле СЦ при полном или частичном отключении электропитания, аварии сетей телекоммуникации, полном или частичном отказе технических средств Модуля СЦ. Технические решения должны обеспечивать сохранность информации в случае возникновения следующих событий (аварий, отказов и т.п.): – отказ аппаратного обеспечения на сервере; – отключение питания на сервере; – отказ аппаратного обеспечения на рабочей станции; – отключение питания на рабочей станции администратора; – отказ линий связи, в том числе при осуществлении обмена данными 4.5.8. Требования к защите от влияния внешних воздействий Требования к защите от влияния внешних воздействий не предъявляются 4.5.9. Требования к патентной чистоте и патентоспособности 4.5.9.1. Исключительные права на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, базы данных, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, принадлежат Российской Федерации в лице Заказчика. Право собственности на результаты работ, отчетные документы и материалы, полученные в ходе выполнения работ по Контракту, принадлежат Российской Федерации в лице Заказчика и считаются переданными с момента подписания Сторонами Акта сдачи-приемки выполненных работ. Разработанное программное обеспечение поставляется вместе с исходными кодами. 4.5.9.2. Все проектные и технические решения должны отвечать требованиям четвертой части Гражданского кодекса Российской Федерации. Результаты Работ должны быть свободными от возможности предъявления любых прав и притязаний третьих лиц, основанных на промышленной, интеллектуальной или другой собственности. 4.5.9.3 Результаты выполненных Работ не должны повлечь необходимость осуществления Заказчиком закупок программного обеспечения (как исключительных, так и неисключительных прав) для обеспечения функциональности Системы в соответствии с Техническим заданием. При выполнении работ Подрядчик должен использовать только объекты интеллектуальной собственности, права на которые приобретены (получены) и используются без нарушений прав на интеллектуальную собственность третьих лиц или предоставлены Заказчиком 4.3.6.4.2. Требования к изменению настроек функционирования Изменение настроек функционирования может проводиться в рамках допустимых пределов изменения функционирования, заложенных в архитектуру Модуля СЦ. Изменение настроек функционирования включает в себя изменение данных и справочников, изменение форм документов, формируемых Модулем СЦ, изменение и настройку форматов и версий передачи данных в смежные системы. Доработка программного кода Модуля СЦ может допускаться (в случае необходимости) при выполнении работ по адаптации функций Модуля СЦ в части изменения формата передачи данных в смежные информационные системы при условии соблюдения требований пункта 29.3 приказа ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации» 4.3.6.5. Требования к услугам по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности По запросу Заказчика Подрядчик должен провести работу по приведению ППО в соответствие с требованиями по обеспечению информационной безопасности. Критичность уязвимости оценивается в соответствии в соответствии с Методическим документом ФСТЭК России «Методика оценки уровня критичности уязвимостей программных, программно-аппаратных средств» (утвержден ФСТЭК России 30.06.2025), а также с учетом ГОСТ 56545-2015 и международными стандартами (CVSS 3.0 и выше), и задает необходимый срок устранения. В процессе проведения Заказчиком обследования Модуля СЦ и выявления уязвимостей в ППО, связанных с исходным кодом Модуля СЦ и/или используемыми компонентами (библиотеками), Заказчик направляет Подрядчику обращение (заявку) на устранение, с указанием критичности и срочности принятия мер по устранению в СРО. Подрядчик при оказании услуг по обновлению или устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности должен: – провести анализ уязвимостей и связанных с ними исходным кодом и/или используемыми компонентами (библиотеками); – выработать варианты устранения указанных уязвимостей и согласовать с Заказчиком их реализацию; – своевременно внести изменения в исходный код Модуля СЦ и/или используемые компоненты (библиотеки) и подготовить соответствующее обновление; – провести обновление Модуля СЦ в тестовом контуре Заказчика и проинформировать Заказчика о готовности проведения тестирования; – протестировать успешность обновления или устранения уязвимостей в ППО и корректность функционирования Модуля СЦ на тестовом контуре, совместно с Заказчиком; – при невозможности незамедлительного устранения уязвимости приоритетов «Критический» и «Высокий» Подрядчик обязан предоставить исчерпывающий список причин и согласовать план достаточных компенсирующих мер с ответственными сотрудниками Заказчика. Результат внесения изменений отображается в соответствующей записи в СРО и в составе Отчета об оказанных услугах 4.3.6.5.1. Требования к порядку оказания услуг по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности Подрядчик в соответствии с приоритетами обращений и контрольными сроками исполнения (см. Приложение Б к ТЗ) оценивает техническую возможность и сроки устранения уязвимостей, и реализацию обновления Модуля СЦ. По итогу проведения оценки Подрядчик направляет в заявке СРО Заказчику заключение о возможности устранения уязвимостей и/или обновления в ППО и согласует с Заказчиком проведение данных работ Технические меры по обеспечению надежности должны предусматривать: – резервирование критически важных компонентов и данных Системы и отсутствие единой точки отказа; – использование программного резервирования (программной избыточности); – изменение конфигурации используемых средств и применение специализированного ПО, обеспечивающего высокую надёжность. Организационные меры по обеспечению надежности должны быть направлены на минимизацию ошибок пользователей (а также обслуживающего персонала при эксплуатации и проведении работ по обслуживанию), минимизацию времени ремонта или замены вышедших из строя компонентов за счёт: – обеспечения для обслуживающего персонала требуемого уровня квалификации; – регламентации и нормативного обеспечения выполнения работ обслуживающим персоналом; – своевременной диагностики неисправностей. Расчетное значение коэффициента доступности Модуля СЦ должно составлять не менее 0,95. 4.5.3. Требования по диагностированию Модуля СЦ Диагностирование Модуля СЦ должно осуществляться путем анализа записей в системных журналах СУБД, операционных систем серверов, а также с помощью встроенных средств диагностирования общего программного обеспечения Модуля СЦ. Диагностированию подлежат: – сбои и нарушения функционирования технического обеспечения (серверов) Модуля СЦ; – сбои и нарушения функционирования системного программного обеспечения серверов, используемых для работы Модуля СЦ; – сбои и нарушения функционирования прикладного программного обеспечения серверов, используемых для работы Модуля СЦ; – случаи недоступности (отсутствия ответа) или некорректные ответы внешних систем; – сбои и нарушения функционирования СУБД; – сбои при выполнении регламентных операций резервного копирования. При возникновении аварийных ситуаций либо ошибок в программном обеспечении диагностические инструменты должны позволять сохранять набор информации, необходимой для идентификации и устранения проблемы. Модуль СЦ и ее компоненты должны обеспечивать возможность диагностики своей работоспособности с возможностью интеграции с модулем мониторинга АСУ ТК. Набор передаваемых журналов и метрик должен быть определен на этапе технического проектирования 4.5.4. Требования к надежности Должно быть предусмотрено сохранение работоспособности Модуля СЦ при некорректных действиях пользователя и сохранение целостности данных при нештатном завершении работы Модуля СЦ (отказ рабочей станции, потеря сетевого доступа и т.п.). Модуль СЦ должен предоставлять механизмы обеспечения сохранности данных через применение процедур резервного копирования и восстановления, описанных в документации на Систему. Ключевые показатели надежности информационной системы — допустимое время на восстановление работоспособности Модуля СЦ (RTO - recovery time objective) и/или допустимый интервал времени потери изменений в данных при сбоях/отказах (RPO – recovery point objective) должны быть определены Подрядчиком и согласованы с Заказчиком на этапе технического проектирования 4.5.9.4. Подрядчик подтверждает, что обладает всеми правами на передачу Заказчику исключительных прав в соответствии с требованиями настоящего раздела Технического задания. В случае, если к Заказчику по вине Подрядчика будут предъявлены претензии в этой части, иски третьих лиц, связанные с нарушением их прав, Подрядчик принимает на себя такие претензии и иски и возмещает Заказчику все расходы и весь ущерб, понесенный в связи с ними. 4.5.9.5. Подрядчик обязан согласовать с Заказчиком необходимость использования при выполнении работ охраняемых результатов интеллектуальной деятельности, права на которые принадлежат Подрядчику или третьим лицам. 4.5.9.6. В случае, если при выполнении Работ используется готовое программное обеспечение (платформа, подсистема, СУБД и т.д.), которое становится частью (компонентом) Системы, Заказчику передаются полные исключительные права, или неисключительные права (путем заключения лицензионного/сублицензионного договора/соглашения) на такое программное обеспечение со следующими возможностями: – права передаются бессрочно (на весь срок действия исключительных прав); – территория действия Российская Федерация; – должно быть обеспечено право Российской Федерации (в лице Заказчика) передавать, дорабатывать, распространять, развивать результаты работ, созданные в процессе исполнения Контракта, а также перерабатывать такое программное обеспечение. Лицензионное (сублицензионное) соглашение (договор), Акт передачи прав, подписанные Подрядчиком, согласие правообладателя, оформленное в соответствии с положениями Гражданского кодекса Российской Федерации (в случае, если Подрядчик не является правообладателем такого программного обеспечения), инструкция по инсталляции, руководство администратора, руководство пользователя передаются Заказчику в сроки, установленные Техническим заданием для соответствующего функционала Системы Лицензионное (сублицензионное) соглашение (договор) не может возлагать на Заказчика какие-либо обязанности (в т.ч. в части конфиденциальности, предоставления отчетности), не предусмотренные Контрактом. 4.5.9.7. Передача Заказчику исключительных прав, или простых (неисключительных) прав не может повлечь увеличение стоимости Контракта и/или изменение иных существенных условий Контракта. 4.5.9.8. Функциональность Модуля СЦ передается в объеме и в сроки, установленные Техническим заданием. 4.5.9.9. Нарушение условий настоящего раздела Технического задания, в т.ч. отсутствие соответствующего лицензионного (сублицензионного) соглашения (или договора), либо предоставление лицензионного (сублицензионного) соглашения (или договора), не соответствующего требованиям действующего законодательства Российской Федерации или требованиям Контракта, является нарушением существенных условий Контракта. 4.5.9.10. В случае, если в соответствии с пунктом 4.5.9.6 Заказчику передается исключительное право, такая передача осуществляется в порядке, установленном Гражданским кодексом Российской Федерации. 4.5.9.11. В случае, если при выполнении Работ положения пунктов 4.5.9.5-4.5.9.6 не применялись, Подрядчик в составе отчетной документации предоставляет об этом декларацию в свободной форме. Декларация должна содержать сведения о полном соответствии результата Работ требованиям Контракта, а также о неприменении при выполнении работ готового программного обеспечения (платформ, подсистем, СУБД и т.д.), которое стало частью (компонентом) Системы 4.5.9.12. Передача Заказчику комплекта документов, материалов и сведений, предусмотренных нормативными правовыми актами Российской Федерации в сфере информационных технологий, защиты информации, правовой защиты интересов государства в области интеллектуальной собственности, включая документы, подтверждающие отказ авторов (разработчиков) от исключительных прав на передаваемые объекты интеллектуальной собственности в пользу Подрядчика, с проектами заявок на государственную регистрацию в установленном порядке прав Заказчика на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, базы данных, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, осуществляется Подрядчиком в составе отчетной документации, предусмотренной условиями Контракта. 4.5.9.13. По результатам выполнения работ по развитию системы должны быть подготовлены материалы для регистрации доработанной версии Системы (объекта учета) в НФАП в соответствии с требованиями постановления Правительства Российской Федерации от 30 января 2013?г. №?62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин» (с изменениями и дополнениями) в части обязательности размещения результатов работ в национальном фонде алгоритмов и программ для электронных вычислительных машин 4.5.10. Требования по стандартизации и унификации К Модулю СЦ предъявляются следующие требования в части стандартизации и унификации: – работы по развитию Модуля СЦ должны производиться в соответствии с действующими стандартами и нормами Российской Федерации; – при создании и модернизации элементов Модуля СЦ следует руководствоваться действующими в Российской Федерации национальными стандартами и другими нормативно-техническими документами; – используемые оборудование и материалы, подлежащие обязательной сертификации, должны иметь соответствующие сертификаты; – ПО Модуля СЦ должно проектироваться и разрабатываться с учётом обеспечения требований унификации; – применяемые при создании Модуля СЦ технические (форматы данных, протоколы передачи и прочие) и организационные (регламенты, требования, инструкции) решения должны быть доступны и документированы в виде, достаточном для независимой (без обращения к Подрядчику) реализации третьими сторонами; – термины, обозначения и наименования, используемые в ПО, должны быть стандартизованы и унифицированы, выполнены на русском языке; – взаимодействие элементов и их внешнее поведение должно быть реализовано одинаково и производиться по единым правилам 4.3.1.2. Требования к общему порядку оказания услуг Техническая поддержка Модуля СЦ должна быть организована на трех уровнях: – первый и второй уровни технической поддержки организуется Заказчиком; – третий уровень технической поддержки организуется Подрядчиком. Перечень действий на каждом уровне технической поддержки указан в Таблице 5: Таблица 5 – Перечень действий на каждом уровне технической поддержки Уровень технической поддержки Доступные действия Условия передачи задачи на следующий уровень Первый уровень технической поддержки (далее – 1-й уровень) – принимает обращения (заявки) пользователей Модуля СЦ и работников Заказчика; – регистрирует обращения в Модуле СЦ регистрации обращений; – присваивает уникальный идентификационный номер, классифицирует обращения; – самостоятельно решает обращения, которые связаны с недостаточной квалификацией пользователей или настройками в рамках своей компетенции; – взаимодействует с пользователями Модуля СЦ при решении проблемы Передает обращение на второй уровень поддержки в случае невозможности решения на своем уровне Второй уровень технической поддержки (далее – 2-й уровень) – принимает обращения от 1-го уровня; – уточняет классификацию обращения в результате дополнительного анализа; – самостоятельно решает обращения в рамках своей компетенции; – осуществляет техническую и консультационную поддержку Модуля СЦ; – взаимодействует с сотрудниками 1-го и 3-го уровня и пользователями Модуля СЦ; – формирует заявки для 3-го уровня и контролирует исполнение Передает обращение на третий уровень поддержки в случае невозможности решения на своем уровне Третий уровень технической поддержки (далее – 3-й уровень) – принимает обращения от 2-го уровня; – обеспечивает выполнение требований, предъявляемых Контрактом и настоящим Техническим заданием к Услугам, оказываемым Подрядчиком Все поступающие обращения должны быть исполнены Подрядчиком Для обеспечения взаимодействия с Заказчиком Подрядчик со своей стороны определяет ответственных лиц, уполномоченных в структуре Подрядчика за своевременное и качественное оказание Услуг в рамках настоящего ТЗ, а также контактную информацию ответственных лиц (телефон, электронную почту). Подрядчик должен предоставить Заказчику единый адрес электронной почты для приема обращений (заявок) в течение 3 (трех) рабочих дней после заключения Контракта. Указанный в настоящем пункте адрес электронной почты (способ направления обращений (заявок) применяется в случае сбоя в работе СРО Заказчика. Со своей стороны, Заказчик предоставляет Подрядчику перечень и контактную информацию (телефон, электронную почту) уполномоченных лиц для осуществления взаимодействия с указанием зон ответственности. О любых изменениях в контактной информации ответственных лиц Стороны должны уведомить друг друга в течение 1 (одного) рабочего дня с момента возникновения таких изменений посредством уведомления на электронную почту ответственных лиц и/или в письменной форме. В результате оказания услуг по настоящему ТЗ не должны быть изменены исходные коды, дистрибутивы и иные компоненты Модуля СЦ вне согласованных с Заказчиком изменений. Любые изменения исходных кодов, дистрибутивов и иных компонентов Модуля СЦ должны производиться только после согласования с Заказчиком уполномоченными лицами по электронной почте или иным заранее согласованным способом. Не должна быть ухудшена надежность и производительность Модуля СЦ. Оказание услуг по Контракту не должно нарушать требования к информационной безопасности, описанной в документации на Модуль СЦ 4.1. Требования к структуре Модуля СЦ В процессе работ по развитию Системы должны сохраниться основные требования к построению архитектуры Системы в соответствии с принципами трехуровневой архитектуры: 1. уровень хранения данных или уровень базы данных (сервер СУБД); 2. уровень сервера приложений (сервер аналитической обработки); 3. презентационный уровень, обеспечивающий взаимодействие с клиентскими приложениями. В состав Системы должны входить следующие основные компоненты: 4. сервер баз данных; 5. сервер приложений; 6. веб-сервер. Сервер баз данных должен обеспечивать хранение и целостность хранимых данных, создание резервных копий, ведение журнала транзакций, восстановление данных после сбоев. Сервер приложений должен обеспечивать обработку запросов, поступающих от клиентских приложений (через веб-сервер), формирование ответов на запрос в доступном пользователю виде (формирование пользовательских интерфейсов). Веб-сервер должен обеспечивать взаимодействие с оператором и внешними системами по HTTP / HTTPS протоколу в режиме «запрос-ответ» (получения запросов от пользователя и передачи ответа в виде соответствующей информации, обработанной серверами приложений). Взаимодействие Системы с пользователем должно отвечать требованиям модели «тонкого клиента» (т.е. представлять на стороне клиента (пользователя) лишь графический пользовательский интерфейс). Все составляющие Системы должны использовать единую методологию и отвечать единым принципам взаимодействия, надежности и управления. Перечень компонентов Модуля СЦ представлен в Таблице 4. Таблица 4. Перечень компонентов Модуля СЦ, в отношении которых выполняются работы по развитию № п.п. Наименование компонента Модуля СЦ Раздел ТЗ 1 Компонент регистрации событий 4.2.1. 2 Компонент отчетности 4.2.2 3 Компонент визуализации 4.2.3 4 «Интерактивная карта» (компонент создается) 4.2.4 5 Компонент администрирования 4.2.5 4.2. Требования к дорабатываемым функциям модуля СЦ 4.2.1. Развитие компонента регистрации событий (1 очередь) Должны быть выполнены следующие доработки: – обеспечение логирования действий пользователя, связанных с карточкой события; – доработка объектной модели в части создания новых типов сущностей (карточек) с учетом реализуемых интеграций с информационными ресурсами (силы и средства предупреждения и ликвидации ЧС и нештатных ситуаций на транспорте, ТС, ограничения воздушного пространства, неблагоприятные и опасные природные явления); – реализация механизма установления связи между сущностями в Модуле СЦ автоматизированным и ручным способами (события, природные явления, силы и средства предупреждения и ликвидации ЧС и нештатных ситуаций на транспорте, ограничения воздушного пространства, ОТИ, ТС и др.); – отображение в карточке установленных связей между сущностями. Оказание услуг в рамках данного технического задания осуществляется Подрядчиком по обращению (заявке) Заказчика, направляемой посредством СРО Заказчика. Регистрация обращений, поступивших непосредственно в Модуль СЦ регистрации обращений Заказчика, производится сотрудниками Заказчика, которые обеспечивают первый уровень технической поддержки Модуля СЦ. В случае назначения приоритета «Критический» или «Высокий», информация о назначении также дублируется оповещением ответственных представителей Подрядчика посредством звонка на предоставленные номера телефонов. Обращение (заявка) должна содержать следующую информацию: – контакты пользователя/организации; – приоритет обращения, соответствующий Приложению 2 к Регламенту; – время обнаружения; – наименование компонента АСУ ТК - Модуль СЦ; Информация может быть расширена по согласованию с Заказчиком. Обращения (заявки) сотрудников Заказчика должны приниматься Подрядчиком через веб-интерфейс СРО. В процессе обработки обращений (заявок) Подрядчик должен обеспечить выполнение следующих процедур: – прием обращений(заявок) от сотрудников Заказчика; – оказание информационно-консультационной поддержки в соответствии с требованиями настоящего Технического задания; – информирование сотрудников Заказчика о статусе обработки и результатах обработки обращений(заявок). Подрядчик осуществляет обязательную регистрацию и учет всех обращений и заявок, поступивших к Подрядчику от представителей Заказчика в рамках оказания настоящих услуг Примечание: в случае приостановки работы по обращению или заявке (обращение или заявка находится в статусе «Приостановлено»), указываются причины, по которым работы по обращению или заявке приостановлены с указанием перечня действий/информации, запрошенных у инициатора обращения, а также даты, формы и адресата такого запроса. В случае отклонения обращения или заявки (заполняется в случае, если обращению или заявке присваивается статус «Отклонено»), указываются подробно причины такого отклонения, а также фиксируется дата и время перехода в статус «Отклонено». В случае, если обращение или заявка отклонены (отменены) самим Инициатором, то указывается дата и способ, которым от инициатора получено соответствующее уведомление. В случае невыполнения Подрядчиком регламентного времени реагирования или решения обращения (заявки) Заказчик вправе отозвать обращение и направить его Подрядчику повторно. При этом каждое отозванное обращение учитывается в Отчёте об оказанных услугах, как обращение с превышением времени реагирования или решения, но оплате не подлежит. В случае, если обращение (заявка) связано с некачественным выполнением Подрядчиком другой задачи, такое обращение решается в регламентное время, установленное Техническим заданием, при этом оплате такие обращения не подлежат, о чем указывается в Отчете об оказанных услугах в графе «Примечание» 4.2.2. Развитие компонента отчетности (3 очередь) Должна быть обеспечена автоматизация процессов формирования отчетов о ЧС и нештатных ситуациях на транспорте, в т.ч. на основе данных из внешних систем. Включает следующие доработки: – разработка шаблонов отчетов в различных форматах (табличный, текстовый); – реализация выбора фотоматериалов для включения в справку; – форматирование содержимого справок с учетом правил русского языка в отношении окончаний слов (в зависимости от падежа, склонения, числа и рода); – автоматизированное формирование выводов к содержимому справки на основе настраиваемых критериев; – создание интерфейса выбора параметров (фильтрации) для формирования отчетов: o состав полей для включения в отчёт; o настройка диапазонов значений характеристик и дат; o порядок отображения полей; o настройка заголовка. – реализация способа подготовки отчётов в асинхронном режиме (очереди); – реализация интерфейса компонента формирования отчетности для отображения очереди формирования отчетов и статусов их подготовки; – экспорт отчётов в форматы xlsx, csv и справок в форматы pdf, docx. Необходимо разработать не менее 10 шаблонов отчетов и/или справок. Перечень, структура и содержание шаблонов должны быть согласованы с Заказчиком на этапе технического проектирования. 4.2.3. Развитие компонента визуализации (2 очередь) В рамках развития компонента визуализации должны быть выполнены следующие доработки, обеспечивающие: – вывод перечней (списков) сил и средств предупреждения и ликвидации ЧС и нештатных ситуаций на транспорте с отображением мест их постоянного размещения (дислокации) на карте, включая: o отображение зон ответственности на карте; o возможность их фильтрации (по видам транспорта, регионам и пр.); o реализацию инструмента расчета расстояния (с использованием сети автомобильных и железных дорог) между местом события и местами дислокации сил и средств, а также вывода маршрутов на карте; – отображение зон (полигонов) с установленными ограничениями движения в воздушном пространстве на карте; – отображение термических точек; – реализация возможности отображения данных из паспорта региона, отображаемого в модуле iМинтранс (модуль АСУ ТК); – отображение краткой карточки сущностей и ОТИ (краткой информации и/или динамических характеристик объекта) при выборе объекта на карте с возможностью перехода в полную карточку сущности и ОТИ; – отображение данных от Росгидромета, предусматривающих: o отображение неблагоприятных и опасных природных явлений на карте (с заданным периодом обновления данных); o управление отображением явлений на карте, включая настройку состава отображаемых объектов, поиск, фильтрацию, с использованием соответствующей панели управления; o выведение краткой карточки явления при выборе объекта, с возможностью перехода в полную карточку объекта – отображение на карте связанных сущностей и ОТИ; – реализация функции выбора темного и светлого стилей отображения элементов интерфейса, карточек сущностей, картографической основы и объектов, отображаемых на карте; – реализация механизма для выбора картографической основы в одном из распространенных форматов WMTS, TMS, MVT и др. Должна быть предусмотрена возможность настройки перечня картографических основ и параметров доступа к ним; – настройка базового набора дашбордов, содержащих преднастроенные виджеты о количестве событий в разрезе видов транспорта с возможностью перехода к исходным данным (карточкам событий, ОТИ и т.д.), с фильтрацией по параметрам. Параметры фильтрации должны быть определены на этапе технического проектирования. Должно быть обеспечено автоматическое и принудительное обновление данных, отображаемых на дашбордах 4.3.1.3. Требования к регламенту оказания услуг Подрядчик должен руководствоваться Регламентом оказания услуг по технической поддержке Модуля СЦ. Регламент оказания услуг содержит следующую информацию: – порядок оказания услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Модуля СЦ; – порядок оказания услуги по решению инцидентов, связанных с работой ППО; – порядок оказания услуги адаптационного, конфигурационного и коррекционного сопровождения Модуля СЦ (в рамках действующих программных модулей и функциональностей); – порядок оказания услуги по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности. – Регламент содержит следующие формы заявок на оказание услуг: – форма заявки на оказание услуги по информационно-консультационной поддержке сотрудников Заказчика; – форма заявки на оказание услуги по решению инцидентов, связанных с работой ППО; – форма заявки на оказание услуг адаптационного, конфигурационного и коррекционного сопровождения Модуля СЦ (в рамках действующих программных модулей и функциональностей) (приоритет заявки определяется Заказчиком); – форма заявки на оказание услуги по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности 4.3.2. Требования к режиму обеспечения функционирования Модуля СЦ Режим оказания услуг определен в Приложении Б к настоящему ТЗ. По согласованию с Заказчиком, в целях недопущения остановки функционирования Модуля СЦ в период интенсивной работы пользователей в Модуле СЦ, отдельные услуги могут оказываться по специальному графику (в нерабочее время Подрядчика) в соответствии с заявками Заказчика 4.3.3. Требования к качеству оказываемых услуг Качество оказываемых услуг поддерживается Подрядчиком в соответствии с определяемыми данным ТЗ условиями и правилами и контролируется Заказчиком на постоянной основе, в том числе по соблюдению сроков исполнения и подтверждениям исполнения от инициаторов обращений и другим параметрам. По результатам выполнения работ по устранению инцидента должна быть устранена корневая причина инцидента с окончательным решением, устраняющим причину возникновения проблемы и исключающим вероятность повторного возникновения проблемы (инцидента). Время устранения корневых причин проблемы (инцидента) не должно составлять более 40 рабочих часов При проведении работ по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности необходимо выполнить следующее: – Заказчику сформировать заявку на устранение (обновление) в СРО с полным списком обнаруженных уязвимостей и планируемыми работами; – согласовать в рабочем порядке время начала и завершения работ, перечень работ, выполняемых в рамках обновления или устранения уязвимостей в ППО с Заказчиком; – оповестить Заказчика о начале проведения работ на тестовом контуре; – провести работы по обновлению или устранению уязвимостей в ППО на тестовом контуре Модуля СЦ в установленные сроки; – протестировать выполнение работ в тестовом контуре и проинформировать Заказчика о готовности переноса ППО на продуктивный контур; – силами Заказчика обновить продуктивный контур Модуля СЦ, в соответствии с планом устранения и выполненными работами; – совместно с Заказчиком проверить корректность функционирования Модуля СЦ и устранения уязвимостей в продуктивном контуре Модуля СЦ по результатам обновления; – при необходимости актуализировать документацию (описание архитектуры, анкеты постановки на мониторинг и иные документы). Любые изменения в части обновления или устранения уязвимостей в ППО на промышленном контуре Модуля СЦ должны применяться только в случае успешного проведения аналогичных работ на тестовом контуре. Детальный порядок оказания услуги по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности определен в Регламенте оказания Услуг 4.4. Требования к видам обеспечения 4.4.1. Требования к лингвистическому обеспечению Документация на Модуль СЦ должна разрабатываться на русском языке. Взаимодействие пользователей с Модулем СЦ посредством графического интерфейса должно происходить на русском языке за исключением сообщений, зависящих от настроек системного программного обеспечения, установленного на рабочих местах пользователей. При разработке программных решений Модуля СЦ должно быть предусмотрено использование языков программирования высокого уровня, приведенных в Таблице 7. Таблица 7. Языки и средства разработки, специального программного обеспечения Модуля СЦ Категория Наименование Назначение Языки программирования Kotlin Разработка серверной логики и сервисов (backend) JavaScript / TypeScript Разработка клиентской части (frontend) Python Разработка скриптов интеграции, обработки данных и автоматизации Фреймворки и библиотеки Vue.JS Разработка пользовательских интерфейсов (веб-интерфейсы компонентов визуализации и отчетности) React Разработка пользовательских интерфейсов (при необходимости создания сложных интерактивных компонентов) Решения по лингвистическому обеспечению, включая перечень используемых языков программирования, должны быть согласованы с Заказчиком на этапе технического проектирования 4.4.2. Требования к математическому обеспечению Требования к математическому обеспечению не предъявляются. 4.4.3. Требования к метрологическому обеспечению Требования к метрологическому обеспечению не предъявляются. 4.4.4. Требования к организационному обеспечению Требования к организационному обеспечению не предъявляются. 4.4.5. Требования к методическому обеспечению Задачи методического обеспечения Модуля СЦ должны быть обеспечены за счет использования технологических и методических документов касающихся вопросов функционирования транспортного комплекса и разработки и эксплуатации ПО. 4.4.6. Требования к информационному обеспечению Состав, структура и способы организации информационного обеспечения в Модуле СЦ должны быть определены на этапе технического проектирования. Факты информационного обмена с внешними системами должны фиксироваться в соответствующем журнале 4.5.5. Требования к информационной безопасности Работы по защите информации/информационной безопасности, не включенные в состав настоящего раздела, требуемые в соответствии с требованиями постановления Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации», а также нормативно правовых актов в области защиты персональных данных и обеспечения безопасности объектов критической информационной инфраструктуры, будут проведены в рамках исполнения отдельного контракта, заключенного по результатам отдельной закупочной процедуры (не является частью данного ТЗ), включающего: – определение актуальных угроз безопасности информации и актуализация модели угроз безопасности информации (при необходимости); – выполнение требований о согласовании технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России в установленном порядке; – выполнение требований по устранению Подрядчиком замечаний и недостатков, в случае их выявления при согласовании Заказчиком технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России; – выполнение требований к классу защищенности ГИС, уровню защищенности персональных данных и категории значимости объекта КИИ РФ, установленных для Головного центра обработки данных ФГБУ «СИЦ Минтранса России» (далее – ГЦОД); – определение перечня объектов защиты информационной системы; – описание (актуализированных) требований к системе защиты информации, а также к мерам защиты информации информационной системы в зависимости от установленных классов защищенности, уровня защищенности персональных данных и категории значимости объектов КИИ РФ (приказы ФСТЭК России № 21, 117, 239); – выполнение требований к мерам по защите ГИС от атак, направленных на отказ в обслуживании, в соответствии с пунктами 30, 34, 59, 63 Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений, утвержденных приказом ФСТЭК России от 11.04.2025 № 117; – описание (актуализированных) требований по защите информации, подлежащих реализации в информационно телекоммуникационной инфраструктуре ГЦОД; – выполнение требований о применении сертифицированных средств защиты информации, включая их классы защиты и уровни доверия; – выполнение требований о запрете использования с 01.01.2025 органами (организациями) средств защиты информации странами происхождения, которых являются иностранные государства в соответствии с пунктом 6 Указа Президента Российской Федерации от 01.05.2022 № 250; – выполнение требований по обеспечению непрерывного взаимодействия с ГосСОПКА в установленном порядке; 4.5.11. Требования к показателям назначения 4.5.11.1. Требования к показателям назначения мероприятий по развитию Модуля СЦ В рамках выполнения работ по развитию Модуля СЦ, предусмотренных ТЗ, показатель назначения «Количество пользователей» должен соответствовать значениям, приведенным в данном разделе. Пояснения по показателям, связанным с количеством пользователей, приведены в Таблице 8. Таблица 8. Определения показателей, связанных с количеством пользователей в Модуле СЦ № Показатель Определение Расчетное количество пользователей Количество пользователей, работу которых должен обеспечить Модуль СЦ к моменту сдачи работ по Контракту с учетом достижения всех показателей назначения Расчетное количество одновременно работающих пользователей Количество одновременно работающих пользователей, работу которых должен обеспечивать Модуль СЦ к моменту сдачи работ по Контракту с учетом достижения всех показателей назначения Значения показателей количества пользователей, достижение которых необходимо обеспечить, представлено в Таблице 9 Таблица 9. Значения показателей количества пользователей № Показатель Значение 1. Расчетное количество пользователей 1 000 2. Расчетное среднее количество одновременно работающих пользователей 200 Развитие Модуля СЦ должно быть направлено на достижение следующего эффекта (показателя), подставленного в мероприятии 103.002 «Информационно-аналитическая система регулирования на транспорте (АСУ ТК)» ВПЦТ Минтранса России: Выполнение работ по развитию Модуля СЦ предусмотрено мероприятием по развитию АСУ ТК, приведенном в ВПЦТ Минтранса России на 2026-2028 гг: № 103.002 «АСУ ТК» в составе ИТ расхода 103.26.000005 «Развитие предусматривает реализацию ОКР и эффектов, приведенных в Таблице 10. Таблица 10. ОКР и эффекты, приведенные в ВПЦТ Минтранса России на 2026 г. № ОКР Дата ОКР Эффекты 1 Обеспечено информационное взаимодействие с Минобороны России о происшествиях на транспортных объектах 25.12.2026 Сокращено время сбора и передачи сведений для Минобороны России о ЧС и НС на транспорте с 120 до 10 минут 2 Обеспечена автоматизация формирования отчетов о нештатных ситуациях на транспорте, в том числе по данным внешних систем 25.12.2026 Сокращено время на подготовку отчетов о нештатных ситуациях на транспорте с 20 до 5 минут Реализация остальных ОКР не является предметом данного ТЗ и проводится в рамках отдельного технического задания. 4.5.11.2. Требования к показателям назначения мероприятий по эксплуатации Модуля СЦ. Работы по эксплуатации Модуля СЦ не должны обеспечивать режимы функционирования Модуля СЦ, приведенные в разделе 4.5.2 данного ТЗ 4.3.4. Требования к документированию результатов оказываемых услуг Для обеспечения контроля оказываемых услуг по поддержке Модуля СЦ со стороны Заказчика, по окончании каждого отчетного периода по контракту в соответствии с календарным планом, Подрядчик обязан предоставить Заказчику Отчет об оказанных услугах. Отчет должен содержать детальную информацию об оказанных услугах с указанием даты выполненных мероприятий и приложением обосновывающих документов (заявок, запросов, требований) или ссылкой на такие документы, если они содержатся в Модуле СЦ. Информация о выполненных мероприятиях по заявкам должна быть сформирована на основании соответствующих записей СРО по каждому этапу исполнения Контракта. В случае оказания услуги адаптационного, конфигурационного и коррекционного сопровождения Модуля СЦ, должны быть предоставлены документы, подтверждающие выполнение требований п. 29.3 приказа ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации». Фактическое время реагирования и время решения по всем обращениям, поступившим в СРО, формируется в СРО по итогам отчетного периода в разделе «Отчеты». Фактическое время реагирования и время решения по обращениям учитывает суммарное время, затраченное на реагирование и, соответственно, на работу по обращению с момента назначения обращения специалисту Подрядчика или группе исполнителей, ответственным за оказание услуг технической поддержки 3 уровня от начала до завершения работ Подрядчиком. При этом принимается суммарное время нахождения заявки в соответствующих статусах заявки СРО на стороне Подрядчика 4.3.5. Требования к классификации обращений и заявок Обращения и заявки Заказчика классифицируются в соответствии с приоритетами и регламентными сроками, указанными в Приложении 2 к Регламенту. Регистрация обращений и заявок предусматривает создание новой записи в СРО с присвоением поступившему обращению или заявке (новой записи) уникального идентификатора. Запись в СРО должна содержать вопрос или проблему, которую требуется решить или оказать консультацию. Состав обязательной информации, которую должно содержать обращение или заявка, зафиксирован в Регламенте оказания Услуг. Если обращение или заявка автоматически зарегистрированы в СРО при отправке представителем Заказчика, Подрядчик проверяет корректность классификации обращения или заявки и может обратиться к Заказчику с просьбой корректировки, предоставив обоснования в соответствии с настоящей классификацией (Таблица 6) 4.4.7. Требования к программному обеспечению Общесистемное ПО, используемое в составе Модуля СЦ, должно быть зарегистрировано в Едином реестре российских программ для электронных вычислительных машин и баз данных и соответствовать рекомендованным показателям эффективности и соответствующим им значениям индикаторов эффективности перехода подведомственных организаций на использование российского ПО, заданных Приказом Минцифры России от 18.01.2023 № 21 «Об утверждении методических рекомендаций по переходу на использование российского программного обеспечения, в том числе на значимых объектах критической информационной инфраструктуры Российской Федерации, и о реализации мер, направленных на ускоренный переход органов государственной власти и организаций на использование российского программного обеспечения в Российской Федерации». Применяемое в системе программное обеспечение должно соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации, постановления Правительства Российской Федерации от 23 декабря 2024 г. № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц» Прикладное программное обеспечение должно отвечать следующим требованиям: – совместимость программных продуктов в части используемых технических средств, системного программного обеспечения и общесистемной инфраструктуры в пределах требований к техническому обеспечению, а также их информационная совместимость в пределах требований к информационному обмену; – обеспечение трехуровневой архитектуры с разделением на уровень хранения данных (сервер БД), уровень бизнес-логики (сервер приложений) и уровень представления ( 4.4.7.1. Требования к инструментам разработки и процессу контроля версий программного обеспечения 4.4.7.1.1. Система контроля версий Для управления исходным кодом должна использоваться система контроля версий кода, развернутая в инфраструктуре Заказчика. 4.4.7.1.2. Правила именования веток Имя ветки должно соответствовать следующему формату: / / Категории веток: ? feature/ — разработка новой функциональности, а также рефакторинг или удаление существующей; ? fix/ — исправление ошибок; ? hotfix/ — срочные исправления, применяемые в обход стандартного процесса разработки; ? test/ — для проведения экспериментов, не влияющих на основную разработку. Идентификатор задачи: после категории указывается ссылка на задачу (issue) в системе контроля версий кода. Описание: добавляется краткое описание решаемой задачи в формате kebab-case (слова разделяются дефисами, например, add-user-auth). Примеры именования веток: ? feature/#123/add-payment-integration; ? fix/#45/correct-calculation-logic; ? hotfix/#67/urgent-database-connection-patch. 4.4.7.1.3. Правила именования коммитов Сообщение коммита должно соответствовать соглашению Conventional Commits и состоять из категории и описания: : ? fix — исправление ошибки. Примеры сообщений коммитов: ? feat: добавление формы регистрации пользователя; ? fix: исправление ошибки валидации email-адреса; ? refactor: оптимизация алгоритма сортировки данных; ? chore: обновление версий в файле dependencies. 4.4.7.1.4. Модель ветвления В процессе разработки используются следующие основные ветви: ? main / master — стабильная ветка, содержит только код, прошедший полное тестирование и развернутый в продуктивных контурах; ? dev — ветка для интеграции завершенных задач, предназначенная для сборки и тестирования в тестовых средах. Попадание кода в main осуществляется только через Merge Request (MR) из dev – выполнение требований по обеспечению в автоматизированном режиме с Национальной системой противодействия DDoS-атакам (НСПА) Центра мониторинга и управления сетью связи общего пользования ФГУП «ГРЧЦ» в рамках реализации мер по защите ГИС от атак, направленных на отказ в обслуживании; – детализированные требования к составу и содержанию работ по аттестации, а также к их результатам в соответствии с пунктами 13, 15 и 16 требований приказа ФСТЭК России от 29.04.2021 № 77 «Об утверждении Порядка организации и проведения работ по аттестации объектов информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну» 4.5.5.1. Требования к безопасности исходного кода Процесс разработки исходного кода должен соответствовать требованиям законодательства, нормативным правовым актам Российской Федерации, приказу ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по безопасности значимых объектов критической информационной инфраструктуры Российской Федерации», а также учитывать отраслевые практики безопасной разработки. Подрядчик должен предоставить Заказчику Руководство по безопасной разработке программного обеспечения (далее – Руководство), применяемое при разработке исходного кода Модуля СЦ. Руководство должно содержать: · описание процесса безопасной разработки и ролевой модели, отражающей зоны ответственности сотрудников Подрядчика; · описание процессов моделирования, оценки и формирования мер предотвращения угроз, применяемых Подрядчиком; · описание методик, применяемых Подрядчиком при разработке исходного кода (правила написания кода); · описание методик, периодичности проведения и инструментария статического, динамического, композитного и фаззинг тестирования исходного кода, включающего критерии отбора релизных версий ПО, применяемые Подрядчиком в процессе разработки; · описание механизмов безопасности в процессе сборки и доставки (безопасность образов, безопасность секретов, безопасность окружения и сборочной среды), применяемые Подрядчиком; · утвержденные шаблоны отчетной документации (в том числе акты), в соответствии с которыми Заказчик принимает результаты проверок (артефакты сборочного процесса), проведенных Подрядчиком; · описание процедур отслеживания и исправления обнаруженных ошибок и уязвимостей программного обеспечения; · описание способов и сроков доведения Подрядчиком до Заказчика информации об уязвимостях программного обеспечения, о компенсирующих мерах по защите информации или ограничениях по применению программного обеспечения, способов получения пользователями программного обеспечения его обновлений, проверки их целостности и подлинности Подрядчик должен обеспечить реализацию и проведение внутренних проверок мер по разработке безопасного ПО, приведенных в Руководстве. Подрядчик должен провести анализ угроз безопасности информации программного обеспечения в соответствии с ГОСТ 58412-2019 «Защита информации. Разработка безопасного программного обеспечения. Угрозы безопасности информации при разработке программного обеспечения». Подрядчик должен провести испытания по выявлению уязвимостей в программном обеспечении Системы: · проведение статического анализа исходного кода программы; · проведение динамического анализа исходного кода программы; · проведение композитного анализа исходного кода и образов программы; · проведение фаззинг-тестирования программы, направленного на выявление в ней уязвимостей. Испытания по выявлению уязвимостей в программном обеспечении Системы должны быть проведены в рамках: · предварительных испытаний; · опытной эксплуатации; · приемочных испытаний 5. СОСТАВ И СОДЕРЖАНИЕ РАБОТ ПО РАЗВИТИЮ И ТЕХНИЧЕСКОЙ ПОДДЕРЖКЕ МОДУЛЯ СЦ (КАЛЕНДАРНЫЙ ПЛАН) 5 Разработка программного обеспечения (3 очередь, пп. 4.2.2, 4.2.5 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ; – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 3 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 3 очереди; – Руководство по резервному копированию; – Описание ролевой модели; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 09.10.2026 Значение характеристики не может изменяться участником закупки 6 Опытная эксплуатация (1 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акт о завершении опытной эксплуатации 1 очереди; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке 17.09.2026 Окончание: не позднее 26.10.2026 7 Опытная эксплуатация (2 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акт о завершении опытной эксплуатации 2 очереди; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке 26.09.2026 Окончание: не позднее 26.10.2026 8 Опытная эксплуатация (3 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Акт о завершении опытной эксплуатации 3 очереди; – Документ о приемке Начало: с 10.10.2026 Окончание: не позднее 26.10.2026 9 Приемочные испытания Сопроводительным письмом предоставляются Заказчику: – Программа и методика приёмочных испытаний; – Протокол приемочных испытаний; – Исходные коды и дистрибутивы на электронном носителе (при условии внесения изменений, с учетом доработок по результатам опытной эксплуатации и проведенных испытаний); – Комплект рабочей документации на Модуль СЦ (при условии внесения изменений, с учетом доработок по результатам опытной эксплуатации и проведенных испытаний); – Акт приемки Системы в эксплуатацию; – Акт приемки-передачи исключительных прав на объект; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке; – Документы в соответствии с разделом 4.5.9 ТЗ; – Обеспечение гарантийных обязательств Начало: с 27.10.2026 Окончание: не позднее 10.11.2026 10 Услуги по технической поддержке Модуля СЦ (с 11.09.2026 по 15.12.2026) По окончании оказания Услуг сопроводительным письмом предоставляются Заказчику: – Отчет об оказанных Услугах по технической поддержке; – Актуальные на дату окончания оказания Услуг по данному этапу исходные коды прикладного ПО на электронном носителе (в случае внесения изменений); – Инструкция по сборке и развертыванию (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство пользователя (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство администратора (в случае внесения изменений); – Документ о приемке Начало: с 11.09.2026 Окончание: не позднее 15.12.2026 Работы по развитию Системы (за исключением этапов проведения опытной эксплуатации и услуг по технической поддержке) могут быть выполнены досрочно. При досрочном выполнении работ (этапов работ) Подрядчик в письменной форме уведомляет Заказчика о готовности представить для приемки результаты проведения работ в соответствии с требованиями Контракта. Подрядчик также вправе досрочно приступать к работам в рамках очередного этапа при наличии технической, организационной готовности - при условии получения соответствующего согласования Заказчиком. Сдача-приемка результатов выполненных работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная, техническая документация, а также результаты Работ по каждому этапу предоставляется Заказчику в порядке, предусмотренном Контрактом и настоящим Техническим заданием, до размещения Подрядчиком в Единой информационной системе в сфере закупок документа о приемке. Документ о приемке размещается в ЕИС по каждому этапу в соответствии с условиями Контракта. Согласование документов осуществляется в электронном виде посредством переписки с адресов электронной почты Заказчика и Подрядчика, указанных в контракте. Сдача-приемка результатов выполненных работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная техническая документация, а также результаты работ предоставляются Заказчику в порядке, предусмотренном Контрактом и ТЗ, до размещения Подрядчиком в ЕИС документа о приемке. Документ о приемке размещается в ЕИС по каждому этапу в соответствии с условиями Контракта. Этапы выполнения работ по развитию Модуля СЦ приведены в Таблице 11. Таблица 11. Этапы выполнения работ по развитию Модуля СЦ. № этапа Наименование этапа Результат (отчетная документация) Срок исполнения этапа 1 Техническое проектирование Сопроводительным письмом предоставляются Заказчику: · Технический проект, включая следующие документы: – Ведомость технического проекта; – Ведомость машинных носителей информации – Пояснительная записка; – Описание информационного обеспечения системы; – Описание автоматизируемых функций; – Схема функциональной структуры; – Описание организации информационной базы; – Описание программного обеспечения; · Макеты экранных форм компонента «Интерактивная карта»; · Руководство по безопасной разработке программного обеспечения; · Документ о приемке Начало: с даты заключения контракта Окончание: не позднее 31.07.2026 2 Услуги по технической поддержке Модуля СЦ (с даты заключения контракта по 10.09.2026) По окончании оказания Услуг сопроводительным письмом предоставляются Заказчику: – Отчет об оказанных Услугах по технической поддержке; – Актуальные на дату окончания оказания Услуг по данному этапу исходные коды прикладного ПО на электронном носителе (в случае внесения изменений); – Инструкция по сборке и развертыванию (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство пользователя (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство администратора (в случае внесения изменений); – Документ о приемке Начало: с даты заключения контракта Окончание: не позднее 10.09.2026 3 Разработка программного обеспечения (1 очередь, пп. 4.2.1, 4.2.6 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ; – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 1 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 1 очереди; – Руководство по резервному копированию; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 16.09.2026 4 Разработка программного обеспечения (2 очередь, пп. 4.2.3, 4.2.4 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ. – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 2 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 2 очереди; – Руководство по резервному копированию; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 25.09.2026 6. ПОРЯДОК РАЗРАБОТКИ МОДУЛЯ СЦ Проектирование Модуля СЦ должно включать разработку следующих документов: – Ведомость технического проекта; – Ведомость машинных носителей информации – Пояснительная записка; – Описание информационного обеспечения системы; – Описание автоматизируемых функций; – Схема функциональной структуры; – Описание организации информационной базы; – Руководство по безопасной разработке программного обеспечения; – Описание программного обеспечения; – Макеты экранных форм компонента «Интерактивная карта». Структура документов должна соответствовать ГОСТ Р 59795-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов». Разработка Модуля СЦ должна включать в себя: – разработку программного обеспечения в части новых функций Модуля СЦ; – сборка исходного кода, развертывание и настройку доработанного программного обеспечения Модуля СЦ на вычислительных мощностях Заказчика (тестовый контур); – Комплект рабочей документации на Модуль СЦ; – разработку документа «Программа и методика предварительных испытаний»; – разработку документа «Программа и методика приемочных испытаний»; – разработку документа «Программа опытной эксплуатации». Структура документов должна соответствовать ГОСТ Р 59795-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов». В ходе выполнения работ формируется правоустанавливающая, отчетная, рабочая и техническая документация в соответствии с Контрактом и Календарным планом, приведенном в разделе 5. Значение характеристики не может изменяться участником закупки 6.1. Сведения о гарантийном обслуживании Модуля СЦ Под гарантией понимается устранение Подрядчиком своими силами и за свой счет допущенных по его вине недостатков, выявленных после приемки выполненных Работ, как в работе самой Модуля СЦ, так и недостатков в отчетной документации. Если в период гарантийного срока обнаружатся недостатки, то Подрядчик обязан устранить их за свой счет, в сроки, установленные Заказчиком. Гарантийный срок в этом случае продлевается на период устранения недостатков. Срок гарантии: 1 год с даты приемки Заказчиком результатов исполнения Этапа № 9 контракта. Подрядчиком должны быть внесены соответствующие исправления в техническую и рабочую документацию (указанную в пунктах 5 и 6 настоящего ТЗ), связанные с устранением замечаний к работе Модуля СЦ или в случае выявления Заказчиком недостатков в такой документации в период гарантийного срока. Внесение изменений в документацию технического и рабочего проектирования осуществляется в соответствии с ГОСТ 2.503-2023 и ГОСТ Р 2.504-2021. 7. ПОРЯДОК КОНТРОЛЯ И ПРИЕМКИ РЕЗУЛЬТАТОВ ВЫПОЛНЕНИЯ РАБОТ ПО РАЗВИТИЮ МОДУЛЯ СЦ Испытания должны быть организованы и проведены в соответствии с ГОСТ Р 59792-2021 «Информационная технология. Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем». Должны быть проведены следующие виды испытаний: – предварительные испытания; – опытная эксплуатация; – приемочные испытания. Указанные виды испытаний проводятся в отношении не функциональных требований и функциональных возможностей, разрабатываемых в соответствии с настоящим ТЗ. Отдельные виды испытаний проводятся поэтапно в сроки, установленные Календарным планом. Предварительные испытания, опытная эксплуатация, приемочные испытания проводятся комиссией, создаваемой организационно-распорядительным документом Заказчика, который должен определять состав комиссии, порядок ее работы. Методы предварительных испытаний и порядок их проведения должны быть определены в документе «Программа и методика предварительных испытаний», который должен быть утвержден Заказчиком до начала предварительных испытаний. По результатам предварительных испытаний оформляется Протокол предварительных испытания и Акт о приемке в опытную эксплуатацию. Порядок проведения и методы испытаний во время опытной эксплуатации должны быть определены в документе «Программа опытной эксплуатации», который должен быть утвержден Заказчиком до начала опытной эксплуатации. Ход и результаты опытной эксплуатации отражаются в документе «Журнал опытной эксплуатации», и учитываются в ходе приемочных испытаний. По результатам опытной эксплуатации подписывается Акт о завершении опытной эксплуатации Значение характеристики не может изменяться участником закупки До момента подключения внешних ИС, Подрядчиком могут быть использованы эмуляторы ИС для прохождения предварительных испытаний, опытной эксплуатации и приемочных испытаний. В рамках опытной эксплуатации должны быть проведены мероприятия по нагрузочному тестированию Модуля СЦ. Документ «Программа и методика приемочных испытаний» должен быть разработан с учетом недостатков, выявленных в ходе опытной эксплуатации, утвержден Заказчиком до начала приемочных испытаний, при этом проверки Модуля СЦ в части не устраненных недостатков, выявленных в процессе опытной эксплуатации, должны быть вынесены в отдельный раздел «Программы и методики приемочных испытаний». В процессе приемочных испытаний должно быть проверено устранение недостатков, полученных в ходе опытной эксплуатации. После завершения устранения всех замечаний, препятствующих приемке Системы в эксплуатацию, перечисленных в Протоколе приемочных испытаний, Подрядчик должен письменно уведомить Заказчика о том, что все замечания устранены, после чего приемочные испытания по решению Заказчика могут быть проведены повторно. Процедура приемочных испытаний проводится до подписания Протокола приемочных испытаний, не содержащего замечаний, препятствующих приемке Системы в эксплуатацию. Приемочные испытания Системы считаются завершенными успешно, если Протокол приемочных испытаний не содержит замечаний, препятствующих приемке Системы в эксплуатацию 8. ТРЕБОВАНИЯ К СОСТАВУ И СОДЕРЖАНИЮ РАБОТ ПО ПОДГОТОВКЕ МОДУЛЯ СЦ К ВВОДУ В ЭКСПЛУАТАЦИЮ Протоколы предварительных и приемочных испытаний должны содержать вывод о соответствии Модуля СЦ предъявляемым требованиям, а также сроки устранения замечаний и реализации рекомендаций, сформулированных комиссией в ходе предварительных и приемочных испытаний. Условием для передачи Модуля СЦ в промышленную эксплуатацию является устранение всех замечаний. Документация на Модуль СЦ и ее части (техническая и рабочая) должна содержать исчерпывающее описание принятых проектных решений в объеме, достаточном для ее дальнейшего развития и эксплуатации. Техническая и рабочая документация должна содержать описание разработанных результатов работ, в том числе программ для ЭВМ, прикладных программных интерфейсов, алгоритмов и протоколов информационного взаимодействия, технических требований, спецификаций и форматов обмена данными для взаимодействия с другими информационными системами, в объеме, достаточном для их установки, настройки, эксплуатации и развития в дальнейшем без привлечения Подрядчика. Исходные коды передаются в виде и составе, позволяющем провести: – сборку (компиляцию) Модуля СЦ в контролируемой Заказчиком среде; – установку полученной Модуля СЦ на специально подготовленную контролируемую Заказчиком инфраструктуру; – проверку функциональных возможностей Модуля СЦ; – оформление Модуля СЦ в качестве объекта национального фонда алгоритмов и программ для электронных вычислительных машин Значение характеристики не может изменяться участником закупки 8.1. Требования, предъявляемые в соответствии с Приказом Минцифры России от 17.12.2020 № 715 «Об утверждении типовых условий контрактов на выполнение работ по созданию и (или) развитию (модернизации) государственных (муниципальных) и (или) иных информационных систем» Передача исходных кодов, разработанных в ходе выполнения работ, программ для электронных вычислительных машин (далее – программа для ЭВМ) должна сопровождаться передачей всех необходимых для сборки и запуска программы для ЭВМ библиотек зависимостей, программных сценариев (скриптов) для проведения установки (развертывания) программы для ЭВМ. Подрядчик в процессе сдачи-приемки работ по Контракту должен провести демонстрацию процесса и установки (развертывания) разработанных программ для ЭВМ. Документация на Модуль СЦ должна содержать описание принятых проектных решений в объеме, достаточном для ее дальнейшего развития и эксплуатации По результатам проведения приемочных испытаний оформляется Протокол приемочных испытаний и Акт приемки в эксплуатацию. В случае, если взаимодействие с внешними системами не может быть проверено на средах постоянной эксплуатации взаимодействующих систем (по причине неготовности со стороны внешней системы или иным причинам), функции взаимодействия, разработанные в соответствии с требованиями ТЗ, должны быть проверены на тестовых данных с использованием программ-имитаторов взаимодействия. По результатам выполнения этапа приемочных испытаний должны быть подготовлены материалы для регистрации доработанной версии Модуля СЦ (объекта учета) в НФАП в соответствии с требованиями постановления Правительства Российской Федерации от 30 января 2013?г. №?62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин» (с изменениями и дополнениями) в части обязательности размещения результатов работ в национальном фонде алгоритмов и программ для электронных вычислительных машин. Сдача-приемка результатов выполнения Работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная, техническая документация, а также программное обеспечение предоставляется Заказчику в порядке, предусмотренном Контрактом и ТЗ до размещения Подрядчиком в Единой информационной системе в сфере закупок документа о приемке. Результаты проведения опытной эксплуатации, предварительных и приемочных испытаний должны быть зафиксированы в соответствующих протоколах и актах. Выявленные отклонения от настоящего ТЗ, оформляются как недостатки Модуля СЦ 9. ТРЕБОВАНИЯ К ДОКУМЕНТИРОВАНИЮ 9.1. Общие требования Документация на Модуль СЦ должна быть разработана в составе, указанном в разделах 5-8 данного ТЗ, и должна удовлетворять требованиям комплекса стандартов и руководящих документов на автоматизированные системы: – ГОСТ Р 2.105-2019 в части оформления текстовых документов; – ГОСТ 34.201-2020 в части наименования и обозначения документов. Документация на Модуль СЦ должны оформляться на листах формата А4. Допускается для размещения рисунков и таблиц использование листов формата А3 с подшивкой по короткой стороне листа. Документы объемом более 25 (двадцати пяти) листов должны содержать информационную часть, состоящую из аннотации и содержания. Исходные коды должны быть представлены в 1 (одном) экземпляре на электронном носителе, отчетные материалы должны быть представлены в 2 (двух) экземплярах на бумажном носителе (по одному экземпляру для Заказчика и Подрядчика) и в 1 (одном) экземпляре на электронном носителе в формате документов DOCX и PDF. При разработке документов на Модуль СЦ допускается отклонение от требований комплекса стандартов, описанных выше. Документам на Модуль СЦ должны в обязательном порядке присваиваться уникальные децимальные номера в соответствии с порядком, установленном в ГОСТ 34.201-2020. Документ «Программа и методика предварительных испытаний» должен включать приложения с формой протокола предварительных испытаний и формой акта приемки в опытную эксплуатацию. Документ «Программа опытной эксплуатации» должен включать приложение с формой журнала опытной эксплуатации. Документ «Программа и методика приемочных испытаний» должен включать приложения с формой протокола приемочных испытаний и формой акта приемки в эксплуатацию Значение характеристики не может изменяться участником закупки 10. ИСТОЧНИКИ РАЗРАБОТКИ 10.1. Список литературы Специальная литература для разработки ТЗ не использовалась. 10.2. Нормативно-методические документы Список используемых нормативно-методических документов представлен в разделе 1.6 технического задания. ? Приложение А Эскизы визуального оформления компонента «Интерактивная карта» Значение характеристики не может изменяться участником закупки Приложение Б Параметры оказания услуг По устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности 1 Критический не более 30 минут не более 24 часов - критические уязвимости, влияющие на возможную полную недоступность ППО, ключевых функций Системы, ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО без возможности восстановления работоспособности Системы. - Критический уровень CVSS > 8.0 2 Высокий не более 1 часа не более 84 часов - критические уязвимости, влияющие на ошибки и сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО. - Высокий уровень CVSS 5.0 - 8.0 3 Средний не более 4 часов не более 120 часов - уязвимости, влияющие на невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым - Средний уровень CVSS 2.0 - 4.9 4 Низкий не более 8 часов не более 160 часов - уязвимости, влияющие на отклонение в работе ППО, не влияющее на корректную работу функций; - другие сбои и ошибки, затрагивающие основные функции ППО - Низкий уровень CVSS < 2.0 Значение характеристики не может изменяться участником закупки Взаимодействие Заказчика и Подрядчика в части регистрации и контроля времени реагирования и решения обращения (заявки) осуществляется через СРО. Заказчик предоставляет Подрядчику доступ к СРО после заключения Контракта. Поступившие от разных пользователей заявки по поводу однотипных инцидентов или имеющие общую причину должны объединяться в одну заявку. Срок выполнения включает время диагностики инцидента, в ходе которого определяется причина инцидента (проблемы) и способ его устранения. Подрядчик должен обеспечить функционирование Модуля СЦ в соответствии с требованиями и параметрами, указанными в настоящем ТЗ и Регламенте оказании услуг. Основные параметры быстродействия типовых операций в Модуле СЦ указаны в таблице ниже (таблица Б.2.2). Таблица Б.2.2 - Параметры быстродействия Модуля СЦ № п/п Наименование параметра Значение (секунд) 1 Среднее время получения сообщения из очереди сообщений 10 2 Среднее время получения ответа от Системы 5 3 Среднее время открытия карточки реестра 5 Б.1. Базовые параметры оказания Услуг Базовые параметры оказания Услуг приведены ниже: – режимы оказания Услуг (таблица Б.1.1); – сроки предоставления отчетности (таблица Б.1.2). Таблица Б.1.1 - Режимы оказания Услуг № п/п Параметр Значение 1 Режим работы Системы Круглосуточно (24х7) 2 Режим доступности информационно-консультационной поддержки пользователей Системы 2.1 Прием и регистрация обращений (заявок) в СРО Регистрация обращений (заявок) производится круглосуточно в режиме 24х7, без праздников и выходных дней. Обработка заявок первой линией поддержки осуществляется в рабочие дни с 9 до 18 часов 2.2 Консультирование сотрудников Заказчика и пользователей Системы в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 3 Режим доступности по решению инцидентов, связанных с работой ППО: 3.1 - приоритет «Критический» Круглосуточно (24х7) 3.2 - приоритет «Высокий» Круглосуточно (24х7) 3.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 3.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4 Режим доступности услуг по адаптации, конфигурации и коррекционному сопровождению Системы 4.1 - приоритет «Критический» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.2 - приоритет «Высокий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 5 Режим доступности по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности 5.1 - приоритет «Критический» Круглосуточно (24х7) 5.2 - приоритет «Высокий» Круглосуточно (24х7) 5.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 5.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) Таблица Б.1.2. Сроки предоставления отчетности, с момента получения запроса № п/п Параметр Значение 1 Предоставление отчета об оказанных услугах за произвольный период 10 рабочих дней 2 Предоставление подробной информации по инциденту с приоритетом «Критический» 16 рабочих часов 3 Предоставление актуализированной документации 10 рабочих дней Б.2. Приоритеты и регламентные сроки решения обращений (заявок) В зависимости от уровня сбоя в работе Системы обращению (заявке) присваивается один из следующих приоритетов, а также в зависимости от приоритета обращения (заявки) устанавливаются следующие контрольные сроки решения в соответствии с таблицей ниже (Таблица Б.2.1). Таблица Б.2.1 – Приоритеты и регламентные сроки решения обращений (заявок) № п/п Приоритет Максимальное время реагирования Время решения (срок выполнения) Описание приоритета По информационно-консультационной поддержке сотрудников Заказчика и пользователей Системы 1 - не более 1 часа не более 10 часов - По решению инцидентов, связанных с работой ППО: 1 Критический не более 30 минут не более 4 часов - полная недоступность ППО; - недоступность ключевых функций - ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО; - невозможность информационного обмена с ППО для ИС более 4 часов 2 Высокий не более 1 часа не более 8 часов - ошибки/сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; - снижение быстродействия СПО (время отклика ППО на операции превышает 30 секунд); - недоступность управления правами и ролями пользователей 3 Средний не более 4 часов не более 24 часов - невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым -недоступность функции формирования отчетов 4 Низкий не более 8 часов не более 40 часов - отклонение в работе ППО, не влияющее на корректную работу функций; - другие сбои и ошибки, затрагивающие основные функции ППО По адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) 1 Критический не более 40 минут не более 8 часов - изменения, необходимые при проведении аварийно-восстановительных работ для возобновления работоспособности Системы; - изменения, связанные с критичными ошибками, блокирующими возможность оказания государственных услуг и/или чтение и внесение данных в Систему 2 Высокий не более 1 часа не более 40 часов - изменения, относящиеся к обеспечению работоспособности основной функциональности Системы, устраняют выявленные дефекты в работе Системы, оказывающие существенное влияние на работу пользователей в Системе; - изменения, затрагивающие три и более подсистемы/модуля Системы для адаптации 3 Средний не более 4 часов не более 72 часов - изменения, связанные с развитием/улучшением/оптимизацией Системы и выводом новой функциональности в штатном режиме для одного-двух модулей/подсистем; - изменения, связанные с развитием интеграционных механизмов Системы, например обновление существующих и/или реализация новых видов сведений СМЭВ, обновление существующих и/или реализация новых API, адаптация и/или изменение механизмов импорта и экспорта данных Системы и т.д. 4 Низкий не более 8 часов не более 160 часов - изменения, связанные с ошибками/корректировкой/изменением в отображении информации в пользовательском графическом интерфейсе Системы (графика, текст, органы управления, элементы интерфейса) Приложение В Регламент оказания услуг Приложение Д Форма Протокола проверки результатов организационно-штатных и подготовительных мероприятий (шаблон) Протокол проверки результатов организационно-штатных и подготовительных мероприятий Настоящий Протокол содержит результаты проверки организационно-штатных и подготовительных мероприятий, проведенных Исполнителем (Таблица Д.1). Таблица Д.1. Протокол проверки результатов № Мероприятия Подготовительного этапа Результат проверки 1. Определить и направить Заказчику документ «Ответственные за взаимодействия в рамках выполнения работ по техническому сопровождению Системы со стороны Исполнителя». Документ содержит контактную информацию (ФИО, должность, адрес электронной рабочей почты, номер телефона) не менее чем о 2 лицах, ответственных за оказание услуг со стороны Подрядчика Выполнено/Не выполнено 2. Обеспечить подключение специалистов Подрядчика к Системе Выполнено/Не выполнено 3. Обеспечить подключение специалистов Подрядчика к СРО Выполнено/Не выполнено Заказчик Подрядчик /Должность/ /Должность/ ____________________ /Ф.И.О/ ___________________ /Ф.И.О/ М.П. М.П. «_____»_______________________202_г. «_____»_______________________202_г Значение характеристики не может изменяться участником закупки Термины и сокращения В настоящем регламенте используются следующие термины и сокращения на русском и английском языках: Термины/сокращения Полное наименование/описание БЗ (База знаний) База данных Системы регистрации обращений (заявок), созданная для сбора, хранения и поиска способов решения известных проблем в рамках Системы Жизненный цикл обращения (заявки) Совокупность статусов, по которым проходит обращение (заявка), и правила перехода обращения (заявки) из одного статуса в другой Заказчик ФГБУ «СИЦ Минтранса России» – Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» ЗНИ Запрос на изменение – тип заявки, предполагающий внесение изменений в прикладное программное обеспечение Системы ЗНО Запрос на обслуживание – тип заявки, предполагающий работы по предоставлению консультации, предоставление доступа к Системе или стандартизированные типовые изменения конфигураций Системы Инцидент Тип заявки, классифицируемый как нештатное событие в работе компонентов функциональных задач Системы, которое привело или может привести к нарушению или снижению качества функционирования Системы ИС Информационная система Исполнитель Организация, которая определяется по результатам конкурсных процедур Классификация Анализ и заполнение классификационных полей справочными значениями, определяющими последовательность действий и этапов жизненного цикла заявки, а также порядок рассмотрения заявок Консультация Разъяснения по алгоритму работы, требуемых настроек прикладного программного обеспечения и технологии обработки данных при работе с Системой, предоставление информации Маршрутизация Определение процесса движения обращения (заявки) в Системе управления заявками между уровнями технической поддержки и организационными структурами на уровнях поддержки путем назначения обращения (заявки) в соответствии с его классификацией и выставленным приоритетом Обращение (заявка) Устное или письменное обращение пользователя АСУ ТК с вопросом, касающимся работоспособности АСУ ТК, по одному из определённых каналов связи: электронная почта, Система регистрации обращений (заявок) Пользователь Инициатор обращения (заявки) или пользователь Системы ППО Прикладное программное обеспечение Предмет обращения Справочник, классифицирующий типовые запросы в Системе регистрации обращений (заявок), характерные для Системы, выбранное значение определяет маршрутизацию обращения (заявки) (группу ответственных сотрудников) Приоритизация Значение, определяющее время, очередность решения обращений (заявок), ресурсы, привлекаемые для решения обращений (заявок), . Приоритет устанавливается в соответствии с масштабом выявленной проблемы, которая привела или может привести к нарушению или снижению качества функционирования Системы Релиз Выпуск версии прикладного программного обеспечения Системы, от разработки до тестирования и планового обновления Системы на продуктивной среде для установки изменений, связанных с развитием/улучшением/оптимизацией Системы Система, АСУ ТК, Информационно-аналитическая система регулирования на транспорте Информационно-аналитическая система, предназначенная для автоматизации и информационно-аналитического обеспечения процессов управления развитием транспортного комплекса Российской Федерации, обеспечения публичности деятельности органов государственного управления транспортным комплексом, а также обеспечения процессов оказания государственных услуг в электронном виде в сфере транспорта СМЭВ Система межведомственного электронного взаимодействия СПО Системное программное обеспечение СРО Система регистрации обращений (заявок) Статус обращения (заявки) Текущее состояние обращения (заявки) в жизненном цикле процесса оказания технической поддержки Системы СУБД Система управления базами данных Уровень технической поддержки Организационно-структурная часть технической поддержки, имеющая определённые организационно-нормативными документами зоны ответственности, обязанности, а также временные нормативы, в течение которых эти обязательства должны выполняться либо эскалироваться на следующий уровень технической поддержки Услуги Услуги по технической поддержке Информационно-аналитической системы регулирования на транспорте АСУ ТК ФИО Фамилия, имя, отчество Эскалация Процедура повышения внимания к обращению (заявке) путем повышения его приоритета и/или передачи на следующий уровень технической поддержки, а также привлечение ролей, которые могут принимать решения без передачи на следующий уровень технической поддержки API Англ. Application Programming Interface — программный интерфейс приложения, интерфейс прикладного программирования — описание способов (набор классов, процедур, функций, структур или констант), которыми одна компьютерная программа может взаимодействовать с другой программой CVSS Англ. Common Vulnerability Scoring System - открытый стандарт, используемый для расчета количественных оценок уязвимости в безопасности компьютерной системы, обычно с целью понять приоритет ее исправления. В современном инструментарии информационной безопасности используется версия 3.0 и выше с дополнительными метриками к базовым оценкам ID Англ. Identifier – идентификатор, уникальный признак объекта, позволяющий отличать его от других объектов, то есть, идентифицировать SLA Англ. Service Level Agreement - утвержденные условия по обработке обращения (заявки) с установленными метриками времени, которые определяют пороговые значения для эскалации в зависимости от статуса обращения (заявки) (например, время реакции – время от регистрации до осуществления первичной обработки, время решения – время от регистрации обращения (заявки) до его решения и т.д.) SQL Англ. Structured Query Language — «язык структурированных запросов», — декларативный язык программирования, применяемый для создания, модификации и управления данными в реляционной базе данных, управляемой соответствующей СУБД 1 Общие сведения 1.1 Полное наименование Услуг Оказание услуг по технической поддержке Модуля СЦ АСУ ТК в 2026 году. 1.2 Предмет Регламента оказания услуг Требования Технического задания 2 Общие положения 2.1 Цель и задачи оказания услуг Целью технической поддержки Системы является обеспечение ее стабильного и безопасного функционирования и эксплуатации, предупреждение, выявление и устранение сбоев в работе Системы и минимизация их неблагоприятного влияния. Для достижения поставленной цели требуется решение следующих задач: 1. Обеспечение информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы. 2. Поддержание параметров функционирования ППО Системы, удовлетворяющих требованиям производственных процессов, включая их непрерывность. 3. Обеспечение бесперебойного функционирования ППО и своевременное устранение сбоев и аварийных ситуаций в Системе. 4. Своевременное устранение уязвимостей при выявлении таковых, в соответствии с требованиями к обеспечению информационной безопасности. 5. Адаптация, конфигурирование, коррекция программного обеспечения в соответствии с изменениями нормативно-правовой базы и запросами уполномоченных сотрудников органов государственной власти, включая выполнение процедур тестирования и участие в обновлениях ППО на стендах Заказчика. 6. Обеспечение сохранения работоспособности ППО в изменяемой среде эксплуатации. 7. Ведение документации по настоящему контракту и инициирование актуализации документации на Систему по результатам обработки запросов Заказчика и внесения соответствующих изменений в ППО 3.4 Порядок регистрации и сопровождения Заявок Порядок регистрации и сопровождения обращений (заявок) в рамках оказываемых услуг по технической поддержке Системы зависит от типа обращения (заявки): 1. Услуга по решению инцидентов, связанных с работой ППО – тип обращения (заявки) «Инцидент». 2. Услуга по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности – тип обращения (заявки) «Инцидент». 3. Услуга информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы – тип обращения (заявки) «Запрос на обслуживание» (в том числе, консультационный запрос). 4. Услуга адаптационного, конфигурационного и коррекционного сопровождения Системы (в рамках действующих программных модулей и функциональностей) – тип обращения (заявки) «Запрос на изменение». В случае недоступности СРО взаимодействие и информирование Исполнителем о ходе оказания услуги по обращению (заявке), изменению статусов обращений (заявок) осуществляется по согласованию с Заказчиком в соответствии с матрицей взаимодействия, представленной в Приложении 1 к настоящему Регламенту. 3.4.1 Инцидент На рисунке 2 представлена функциональная схема регистрации и сопровождения обращений (заявок) типа «Инцидент». Рисунок 2 - Функциональная схема регистрации и сопровождения обращений (заявок) типа «Инцидент» 3.4.2 Запрос на обслуживание На рисунке 3 представлена функциональная схема регистрации и сопровождения обращения (заявки) типа «ЗНО». Рисунок 3 - Функциональная схема регистрации и сопровождения обращения (заявки) типа «ЗНО» 3.4.3 Запрос на изменение На рисунке 4 представлена функциональная схема регистрации и сопровождения обращений (заявок) типа «ЗНИ». Рисунок 4 - Функциональная схема регистрации и сопровождения обращений (заявок) типа «ЗНИ» 3.5 Порядок классификации и приоритизации обращений (заявок) Классификация является начальной стадией процесса оказания технической поддержки, необходимой для идентификации обращения (заявки) и определения соответствующих действий для его обработки. Для проведения первичной классификации необходимо получить от пользователя и зафиксировать в описании обращения (заявки) подробные сведения о сути запроса, в том числе, для Инцидентов зафиксировать сценарий воспроизведения обнаруженной ошибки. Для проведения вторичной классификации необходимо провести анализ и диагностику для определения корневой причины и затронутой Инцидентом функциональной области (инфраструктура, сеть, ППО). В процессе классификации осуществляется первичная диагностика и оценка проблемы, описанной пользователем Системы в обращении (заявке), в части функционирования и/или удобства использования Системы. Корректная классификация позволяет увеличить скорость обработки обращения (заявки) и решения описанной в обращении (заявке) проблемы при минимальном привлечении ресурсов, в частности, за счет использования известных решений для типовых обращений (заявок), которые должны описываться в БЗ СРО. Классификация позволяет произвести первоначальное назначение обращения (заявки) на ответственного сотрудника и выставить приоритет с учетом приоритизации. Приоритизация применяется для определения критичности описанной в обращении (заявке) проблемы для функционирования ППО Системы. Приоритет рассмотрения обращения (заявки) определяется в процессе ее классификации на основании ряда параметров, вводимых при заполнении обращения (заявки). Приоритизация используется для того, чтобы при одновременном наличии нескольких обращений (заявок) в первую очередь рассматривалась обращения (заявки) с наивысшим приоритетом и не позднее установленных для данного приоритета сроков 4.3. Форма обращения (заявки) на оказание услуг по адаптационному конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) При подаче обращения (заявки) типа «ЗНИ» в СРО указывается (Таблица 7): Таблица 7 – Описание атрибутов формы обращения (заявки) на оказание услуг по адаптационному, конфигурационному и коррекционному сопровождению Системы Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 10) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 9) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 10) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 10) Категория обращения (заявки): запрос на изменение Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 7) Приоритет изменения Время, очередность решения обращения (заявки), ресурсы, привлекаемые для решения обращения (заявки), порядок/процедура действий при решении обращения (заявки) – поле СРО «Приоритет» (см. рисунок 7) Тип изменения Справочник, классифицирующий типовые запросы характерные для Системы – поле СРО «Предмет обращения» (см. рисунок 7) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 7) Текст запроса на оказание услуги по адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 7) На рисунке 7 приведена форма обращения (заявки) типа «ЗНИ» в СРО. Рисунок 7 - Форма обращения (заявки) типа «ЗНИ» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуг по адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей), заполненную в свободной форме 4.4. Форма обращения (заявки) на оказание услуги по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности При подаче обращения (заявки) типа «Инцидент» в СРО указывается (Таблица 8): Таблица 8 – Описание атрибутов формы обращения (заявки) на оказание услуг по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности 2.2 Общее описание процесса оказания сопровождения (технической поддержки) Системы Процесс оказания технической поддержки Системы включает: 1. Поступление обращений (заявок) от пользователей и их регистрацию. 2. Сопровождение обращений (заявок) в соответствии с их классификацией и приоритизацией, в том числе, с их последующей эскалацией. 3. Определение ролей и регламент их взаимодействия при осуществлении деятельности по процессу. 4. Решение обращений (заявок) в установленные настоящим Регламентом сроки. 5. Взаимодействие между 1-м, 2-м и 3-м уровнями технической поддержки, в том числе, с формированием заданий для сопровождения Системы. 6. Контроль качества выполняемых Исполнителем работ, состоящий из проверки сценария, приводящего к ошибке, зафиксированной в Инциденте, и/или к ошибке воспроизведения, а также тестирование внесенных изменений в рамках ЗНИ. 7. Обеспечение мониторинга и проведение анализа процесса обработки поступающих в техническую поддержку обращений (заявок). Техническая поддержка реализуется путем проведения ответственными сотрудниками соответствующей информационно-консультационной деятельности в соответствии с определенными ролями, а также выполнения Исполнителем конкретных действий по своевременному выявлению причин сбоев и аварийных ситуаций и их устранению, а также по адаптации, конфигурированию, корректировке Системы, включая выполнение процедур тестирования и участия в обновлениях Системы. Все роли подразделяются на уровни поддержки, взаимодействующие между собой в соответствии с блок-схемой процесса технической поддержки. Общая схема процесса рассмотрения обращений (заявок) в соответствии с видами технической поддержки представлена на рисунке 1. . Рисунок 1 - Общая схема процесса рассмотрения обращений (заявок) в соответствии с видами технической поддержки 2.3 Каналы связи Должна быть предусмотрена омниканальность в части приема обращений (заявок). Получение обращений (заявок) технической поддержкой происходит по следующим каналам связи: – СРО; – электронная почта; – телефонная линия. Исполнитель обеспечивает прием обращений (заявок) от Заказчика и предоставляет информацию в рамках оказания услуг по техническому сопровождению Системы, руководствуясь матрицей взаимодействия, приведенной в Приложении 1 к настоящему Регламенту 3 Порядок оказания Услуг 3.1 Типы обращений (заявок) Обращения и заявки Заказчика классифицируются в соответствии с приоритетами и регламентными сроками, указанными в Приложении 2 к настоящему Регламенту. Регистрация обращений и заявок предусматривает создание новой записи в СРО с присвоением поступившему обращению или заявке (новой записи) уникального идентификатора. Запись в СРО должна содержать вопрос или проблему, которую требуется решить или оказать консультацию. Если обращение или заявка автоматически зарегистрированы в СРО при отправке представителем Заказчика, Исполнитель проверяет корректность указанного типа обращения (заявки) и может обратиться к Заказчику с просьбой корректировки, предоставив обоснования в соответствии с настоящей классификацией (Таблица 1) Изменение приоритета уже зарегистрированного обращения (заявки) используется в случае появления новых обстоятельств, которые ведут к изменению влияния и/или срочности существующего обращения (заявки). При регистрации обращения (заявки) необходимо провести его приоритизацию. В процессе управления обращениями (заявками) каждому обращению (заявке) присваивается приоритет, принимающий одно из значений: Низкий, Средний, Высокий или Критический. В соответствии с приоритетом определяется время, очередность устранения, , ресурсы, привлекаемые для работ по обращению (заявке), а также может определяться порядок/процедура действий при работе с обращением (заявкой). Заказчиком в зависимости от уровня сбоя в работе Системы обращению (заявке) присваивается приоритет с указанием максимального времени реакции и решения в соответствии с требованиями, указанными в Приложении 2 к настоящему Регламенту 4 Формы обращений (заявок) на оказание услуг по технической поддержке Системы, заполняемые в СРО 4.1. Форма обращения (заявки) на оказание услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы При подаче обращения (заявки) типа «ЗНО» в СРО указывается (Таблица 5): Таблица 5 – Описание атрибутов формы обращения (заявки) на оказание услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 5) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 5) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 5) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 5) Категория обращения: информационно-консультационная поддержка Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 5) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 5) Текст запроса на оказание услуги по информационно-консультационной поддержке сотрудников Заказчика Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 5) На рисунке 5 приведена форма обращения (заявки) типа «ЗНО» в СРО. Рисунок 5 - Форма обращения (заявки) типа «ЗНО» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы, заполненную в свободной форме. Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 8) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 8) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 8) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 8) Категория обращения (заявки): инцидент Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 8) Приоритет Время, очередность решения обращения (заявки), ресурсы, привлекаемые для решения обращения (заявки), порядок/процедура действий при решении обращения (заявки) – поле СРО «Приоритет» (см. рисунок 8) Тип изменения Справочник, классифицирующий типовые запросы характерные для Системы – поле СРО «Предмет обращения» (см. рисунок 8) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 8) Текст запроса на оказание услуги по обновлению или удалению уязвимых компонентов (библиотек) ППО в соответствии с требованиями к обеспечению информационной безопасности Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 8) На рисунке 8 приведена форма обращения (заявки) типа «Инцидент» в СРО. Рисунок 8 - Форма обращения (заявки) типа «Инцидент» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуги по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности, заполненную в свободной форме Приложение 1 к Регламенту Матрица ответственных за взаимодействия в рамках выполнения работ по техническому сопровождению Системы Таблица 1 – Ответственные за взаимодействия в рамках выполнения работ по техническому сопровождению Системы со стороны Исполнителя ФИО Должность Адрес электронной почты Телефон — — — Общий контакт Приложение 2 к Регламенту Приоритеты и регламентные сроки решения обращений (заявок) Приоритеты и регламентные сроки решения обращений (заявок) приведены в таблице 1. Таблица 1 – Приоритеты и регламентные сроки решения обращений (заявок) № п/п Приоритет Максимальное время реагирования Время решения (срок выполнения) Описание приоритета По информационно-консультационной поддержке сотрудников Заказчика и пользователей Системы 1 – не более 1 часа не более 10 часов – Таблица 1 - Типы обращений (заявок) Тип обращения (заявки) Описание Запрос на обслуживание Подготовка SQL запроса к СУБД для решения прикладной задачи и д р. – запрос на любое действие, не являющееся запросом информации и несовершенный на основе происшествия, прямо или косвенно влияющего на работу Системы Консультация (входит в тип обращения (заявки) «Запрос на обслуживание») «Где взять / куда обратиться...?», «Как сделать / выполнить…», «Как это работает…?» - запрос, имеющий своей целью получение информационной поддержки Инцидент Разбор ошибок/сбоев и подготовка материалов (корректировочных релизов, инструкций) для Заказчика для устранения ошибок/сбоев, которые приводят к частичному и полному нарушению работоспособности всех или отдельных функций ППО. Подготовка изменения и материалов, необходимых для проведения аварийно-восстановительных работ для возобновления работоспособности Системы. ЗНИ Подготовка изменений, связанных с изменением, улучшением/оптимизацией Системы и выводом новой модифицированной функциональности в штатном режиме. Подготовка изменений, связанных с модификацией существующих и/или реализация новых интеграционных механизмов для получения/обработки данных внешних систем. Подготовка изменений графического интерфейса по требованиям Заказчика 3.2 Участники технической поддержки, осуществляющие сопровождение обращений (заявок) Техническая поддержка Системы должна быть организована на трех уровнях: 1. Первый и второй уровни технической поддержки организуется Заказчиком. 2. Третий уровень технической поддержки организуется Исполнителем. Зона ответственности каждого уровня технической поддержки указана в Таблице 2. Таблица 2 - Зона ответственности каждого уровня технической поддержки Участники технической поддержки Описание Первый уровень технической поддержки (далее – 1-й уровень) Группа ответственных сотрудников 1-го уровня Заказчика, осуществляющая прием и первичную обработку обращений (заявок) (описание предмета обращения, первичная классификация и приоритизация, определение назначения, маршрутизация обращений (заявок) по назначению), руководствуется в своей работе настоящим Регламентом и БЗ, наполняемой 2-м уровнем поддержки, самостоятельно решает часть обращений (заявок), связанных с недостаточной квалификацией пользователей или настройками в рамках своей компетенции. В случае невозможности решения обращений (заявок) на 1-ом уровне ответственный сотрудник передает ее на 2-й уровень Второй уровень технической поддержки (далее – 2-й уровень) Группа ответственных сотрудников 2-го уровня Заказчика по установленным компетенциям (информационная безопасность, сопровождение и эксплуатация информационно-аналитических систем, развитие информационно-аналитических систем, техническая поддержка информационно-аналитических систем) отвечает за поддержание работоспособности Системы, обработку обращений (заявок) и их решение в регламентные сроки в соответствии с установленными приоритетами. Осуществляет информационно-консультационную поддержку пользователей Системы в рамках своей компетенции. Оказывает экспертную помощь ответственным сотрудникам 1-го уровня в части формирования БЗ, содержащей ответы на часто задаваемые вопросы пользователей, с целью передачи знаний, навыков и инструментария на 1-й уровень для ускорения решения обращений (заявок). В случае невозможности решения обращения (заявки) на 2-ом уровне ответственный сотрудник передает его на 3-й уровень. При выявлении необходимости изменений в ППО Системы инициирует формирование обращения (заявки) и направляет его на группу ответственных сотрудников 3-го уровня по соответствующему классификатору (ЗНО, ЗНИ, и т.д.) 4.2. Форма обращения (заявки) на оказание услуги по решению инцидентов, связанных с работой ППО При подаче обращения (заявки) типа «Инцидент» в СРО указывается (Таблица 6): Таблица 6 – Описание атрибутов формы обращения (заявки) на оказание услуги по решению инцидентов, связанных с работой ППО Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 6) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 6) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 6,) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 6) Категория обращения (заявки): инцидент Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 6) Приоритет изменения Время - одно из значений: Низкий, Средний, Высокий или Критический. Определяет, очередность решения обращения (заявки), ресурсы, привлекаемые для решения обращения (заявки), порядок/процедура действий при решении обращения (заявки) – поле СРО «Приоритет» (см. рисунок 6,) Тип изменения Справочник, классифицирующий типовые запросы характерные для Системы – поле СРО «Предмет обращения» (см. рисунок 6) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 6) Полное описание инцидента, включая скриншоты и описание шагов, приведших к неисправности Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 6) Однократность/неоднократность Круг пользователей или компьютеров, затронутых данным инцидентом Действия, предпринятые для самостоятельного решения инцидента (при наличии) Версии используемого программного обеспечения на клиентской рабочей станции, где воспроизводится ошибка (операционная система, прикладное программное обеспечение) Дополнительная информация На рисунке 6 приведена форма обращения (заявки) типа «Инцидент» в СРО. Рисунок 6 - Форма обращения (заявки) типа «Инцидент» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуги по решению инцидентов, связанных с работой ППО, заполненную в свободной форме По решению инцидентов, связанных с работой ППО 1 Критический не более 30 минут не более 4 часов – полная недоступность ППО; – недоступность ключевых функций; – ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО; – невозможность информационного обмена с ППО для ИС более 4 часов 2 Высокий не более 1 часа не более 8 часов – ошибки/сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; – снижение быстродействия СПО (время отклика ППО на операции превышает 30 секунд); – невозможность управления правами и ролями пользователей 3 Средний не более 4 часов не более 24 часов – невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым недоступность функции формирования отчетов 4 Низкий не более 8 часов не более 40 часов – отклонение в работе ППО, не влияющее на корректную работу функций; – другие сбои и ошибки, затрагивающие основные функции ППО По адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) 1 Критический не более 40 минут не более 8 часов – изменения необходимые при проведении аварийно-восстановительных работ для возобновления работоспособности Системы; – изменения, связанные с критичными ошибками, блокирующими возможность оказания государственных услуг и/или чтение и внесение данных в Систему 2 Высокий не более 1 часа не более 40 часов – изменения относящиеся к обеспечению работоспособности основной функциональности Системы, устраняют выявленные дефекты в работе Системы, оказывающие существенное влияние на процесс оказания государственных услуг и работу пользователей в Системе; – изменения, затрагивающие три и более подсистемы/модуля Системы для адаптации 3 Средний не более 4 часов не более 72 часов – изменения, связанные с развитием/улучшением/оптимизацией Системы и выводом новой функциональности в штатном режиме для одного-двух модулей/подсистем; – изменения, связанные с развитием интеграционных механизмов Системы, например, обновление существующих и/или реализация новых видов сведений СМЭВ, обновление существующих и/или реализация новых API, адаптация и/или изменение механизмов импорта и экспорта данных Системы и т.д. 4 Низкий не более 8 часов не более 160 часов – изменения, связанные с ошибками/ корректировкой/изменение в отображении информации в пользовательском графическом интерфейсе Системы (графика, текст, органы управления, элементы интерфейса) По устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности 1 Критический не более 30 минут не более 24 часов – критические уязвимости, влияющие на возможную полную недоступность ППО, ключевых функций Системы, ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО без возможности восстановления работоспособности Системы; – Критический уровень CVSS > 8.0 2 Высокий не более 1 часа не более 84 часов – критические уязвимости, влияющие на ошибки и сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; – Высокий уровень CVSS 5.0 - 8.0 3 Средний не более 4 часов не более 120 часов – уязвимости, влияющие на невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым; – Средний уровень CVSS 2.0 - 4.9 4 Низкий не более 8 часов не более 160 часов – уязвимости, влияющие на отклонение в работе ППО, не влияющее на корректную работу функций; – другие сбои и ошибки, затрагивающие основные функции ППО; – Низкий уровень CVSS < 2.0 Приложение Г Форма Отчета об оказанных услугах Отчет об оказанных услугах за этап «наименование этапа» в период с «__» _________ по «__» _________. № п/п Наименование услуги Общее количество Номер ОРС Краткое Описание Время реагирования по ТЗ Время реагирования фактическое Время решения по ТЗ Время решения фактическое Результат соблюдения времени реагирования Результат соблюдения времени решения Примечание 1 Услуги по информационно-консультационной поддержке работников Заказчика 2 546782 Консультация по работе Модуля СЦ 1 2 10 часов 11 часов Нет Нет 567123 Консультация по схеме БД 1 1 10 часов 1 час Да Да 2 … … Заказчик Подрядчик /Должность/ /Должность/ ____________________ /Ф.И.О/ ___________________ /Ф.И.О/ М.П. М.П. «_____»_______________________202_г. «_____»_______________________202_г Приложение 1 к Отчету об оказанных услугах Журнал обращений (заявок) на оказание услуги по информационно-консультационной поддержке пользователей Системы (шаблон) Наименование Исполнителя в этапе «наименование этапа» в период с ________________ по _______________ оказал(о) Услугу по поддержке пользователей Системы в объеме, указанном в Таблице 1 Таблица 1 - Журнал обращений (заявок) пользователей Системы № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. ИТОГО зарегистрировано: Всего обращений (заявок): ________ ИТОГО решено: Всего обращений (заявок): ________ Приложение 2 к Отчету об оказанных услугах Журнал обращений (заявок) по решению инцидентов, связанных с работой ППО (шаблон) Наименование Исполнителя в этапе «наименование этапа» в период с ________________ по _______________ оказал(о) Услугу по решению инцидентов в объеме, указанном в Таблице 1. Таблица 1 - Журнал по решению инцидентов № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. ИТОГО зарегистрировано: Всего инцидентов: ________ ИТОГО решено: Всего инцидентов: ________ Приложение 3 к Отчету об оказанных услугах Журнал обращений (заявок) выполнения адаптационного, конфигурационного и коррекционного сопровождения Системы (шаблон) Журнал выполнения адаптации, конфигурации и коррекции Системы сформирован за этап «наименование этапа» в период с «__» _________ по «__» ____________ и представлен в таблице ниже (Таблица 1). Таблица 1 - Журнал выполнения адаптации, конфигурации и коррекции сопровождения Системы № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. Количество выполненных заявок за этап: ________ Приложение 4 к Отчету об оказанных услугах Журнал обращений (заявок) по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности (шаблон) Журнал обращений (заявок) по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности сформирован за этап «наименование этапа» в период с «__» _________ по «__» ____________ и представлен в таблице ниже (Таблица 1). Таблица 1 - Журнал выполнения заявок по устранению уязвимостей в ППО № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. Количество выполненных заявок за этап: ________ Третий уровень технической поддержки (далее – 3-й уровень) Группа ответственных сотрудников Исполнителя, отвечающая за устранение сбоев и аварий, проведение информационно-консультационной поддержки пользователей Системы, проведение адаптации и конфигурирования Системы в объемах действующих контрактов на оказание технической поддержки 3.3 Перечень и описание статусов обращений (заявок) В Таблице 3 приведен перечень статусов обращений (заявок), действующий в СРО, и их описание. Таблица 3 - Перечень статусов обращений (заявок) и их описание Статус Описание Зарегистрирован Обращение (заявка) принято и зарегистрировано Направлен в группу Присваивается при назначении ответственными сотрудниками 1-го уровня группе ответственных сотрудников 2-го уровня по тематике обращения (заявки) после заполнения всей необходимой информации и полей обращения (заявки), а также при его передаче между группами 2-го уровня Передан в группу Присваивается при передаче обращения (заявки) ответственными сотрудниками 2-го уровня на группу ответственных сотрудников 3-го уровня Назначен Присваивается при назначении обращения (заявки) на ответственного сотрудника для его решения в рамках компетенции В работе Присваивается при приеме обращения (заявки) в работу ответственным сотрудником для его решения Решен Присваивается ответственным сотрудником, выполнившим работы по обращению (заявке) Закрыт Присваивается автоматически при решении запроса по обращению (заявке), а также отсутствии дополнительных запросов пользователя в соответствии с действующим SLA, или при подтверждении решения обращения (заявки) со стороны пользователя Запрос доп. информации Присваивается при необходимости запроса дополнительной информации и/или уточнения предмета обращения по обращению (заявке) у пользователя Ответ предоставлен Присваивается после ответа пользователем на запрос дополнительной информации Отклонен Присваивается, если обращение (заявка) не актуальна (по информации от пользователя), отсутствует техническая возможность решения обращения (заявки), предмет обращения не входит в компетенции технической поддержки, или существует влияние доработки на другие компоненты, что нарушает общий порядок работы Системы Согласование Присваивается при необходимости согласования направления обращения (заявки) ответственным сотрудником Заказчика на 3-й уровень Анализ Присваивается при проведении анализа на предмет возможности внесения изменений, связанных с развитием/улучшением/оптимизацией Системы и выводом новой функциональности и оценке ресурсоемкости Тестирование Присваивается Исполнителем при завершении разработки и проведенном предварительном тестировании для последующего осуществления приемочного тестирования Специалистом 2-го уровня Релиз Присваивается ответственным сотрудником Заказчика при принятии решения о возможности вывода доработки в продуктивную среду Утверждение заказчиком Присваивается при согласовании группой профильных специалистов на 2-м уровне поддержки с пользователем технического задания для внесения изменений, связанных с развитием/улучшением/оптимизацией Системы и выводом новой функциональности Доработка Присваивается в случае несогласования Заказчиком работ, проведенных Исполнителем в рамках контрактных обязательств, по внесению изменений, связанных с развитием/улучшением/оптимизацией Системы и выводом новой функциональности в штатном режиме, и необходимости последующего направления Исполнителю для ее доработки Отложен Присваивается в случае невозможности выполнения запроса, изложенного в обращении (заявке), в связи с необходимостью запроса дополнительной информации у третьих сторон - Наименование характеристики - Значение характеристики - Единица измерения характеристики - Инструкция по заполнению характеристик в заявке - ОПРЕДЕЛЕНИЯ, ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ - Автоматизированная система (АС) Система, состоящая из комплекса средств автоматизации, реализующего информационную технологию выполнения установленных функций, и персонала, обеспечивающего его функционирование (ГОСТ Р 59853-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения») АРМ Автоматизированное рабочее место АСУ ТК, Система Информационно-аналитическая система регулирования на транспорте АТС Автоматическая телефонная станция БД База данных ГИС Государственная информационная система ГОСТ Государственный стандарт ГЦОД СИЦ Минтранса России, ГЦОД Головной центр обработки данных ФГБУ «СИЦ Минтранса России» Дашборд Интерактивная аналитическая панель, графический интерфейс. ЕИС Единая информационная система в сфере закупок ЕСИА Единая система идентификации и аутентификации Заказчик Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» КИИ Критическая информационная инфраструктура Кластер Кла?стер (англ. cluster) – объединение нескольких однородных элементов, которое может рассматриваться как самостоятельная единица, обладающая определёнными свойствами Компонент Часть АС, выделенная по определенному признаку или совокупности признаков и рассматриваемая как единое целое (ГОСТ Р 59853-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения») Контракт Контракт на выполнение работ по развитию и оказанию услуг по технической поддержке Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК в 2026 году, заключаемый по результатам проведения конкурентной процедуры закупки в соответствии с требованиями Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» - - Значение характеристики не может изменяться участником закупки - Модуль iМинтранс Модуль сбора данных и представления показателей деятельности Министерства транспорта Российской Федерации iМинтранс АСУ ТК Модуль СЦ Модуль сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК НС Нештатная ситуация НСИ Нормативно-справочная информация ОТИ Объект транспортной инфраструктуры П-ГИС Геоинформационная подсистема П-ИВ Подсистема информационного взаимодействия П-НСИ Подсистема ведения нормативно-справочной информации и метаданных ПО Программное обеспечение Подрядчик, Исполнитель Организация, с которой будет заключен контракт на выполнение работ по развитию Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК П-СД Подсистема сбора данных Работы Работы по развитию Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК СЗИ Средство защиты информации СМЭВ Система межведомственного электронного взаимодействия СУБД Система управления базами данных ТЗ Техническое задание (настоящий документ) ТС Транспортное средство ТК Транспортный комплекс Учреждение Учреждения в области информационной безопасности - ФГБУ «СИЦ Минтранса России» Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации», Заказчик Федеральный закон № 44-ФЗ Федеральный закон от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» ФЗ Функциональная задача ФЗ «Реестр объектов» Функциональная задача «Формирование и ведение единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации» ФСБ России Федеральная служба безопасности Российской Федерации ФСТЭК России Федеральная служба по техническому и экспортному контролю ЧС Чрезвычайная ситуация ЭВМ Электронно-вычислительная машина API От англ. Application Programming Interface – интерфейс прикладного программирования – совокупность инструментов и функций в виде интерфейса для взаимодействия с программой CSS От англ. Cascading Style Sheets — каскадные таблицы стилей FPS От англ. frame per second - количество кадров в секунду HTML От англ. HyperText Markup Language - стандартный язык разметки документов, создающий основу и структуру всех веб-страниц JSON От англ. JavaScript Object Notation – текстовый формат обмена данными, основанный на JavaScript WebAssembly (Wasm) Открытый стандарт, представляющий собой низкоуровневый бинарный формат инструкций, который позволяет выполнять код, написанный на языках C++, Rust или Go, в браузерах с производительностью, близкой к нативной - 1. ОБЩИЕ СВЕДЕНИЯ - – постановление Правительства Российской Федерации от 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 Федерального закона «Об электронной подписи»; - - Значение характеристики не может изменяться участником закупки - – постановление Правительства Российской Федерации от 08.06.2011 № 451 «Об инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг и исполнения государственных и муниципальных функций в электронной форме»; – постановление Правительства Российской Федерации от 30.01.2013 № 62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин»; – приказ ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации»; – приказ ФСТЭК России от 11.04.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений»; – приказ ФСБ России от 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 «Национальный стандарт Российской Федерации. Интеллектуальная собственность. Патентные исследования. Содержание и порядок проведения»; - 1.1. Наименование Системы Полное наименование системы: Информационно-аналитическая система регулирования на транспорте. Условное обозначение системы: АСУ ТК. Полное наименование модуля: Модуль сбора, ведения и анализа информации о нештатных ситуациях на транспорте. Условное обозначение модуля: Модуль СЦ. Модуль СЦ создан в рамках контракта от 05.08.2024 № ОК/24_04 на выполнение работ по развитию АСУ ТК в части создания модуля «Сбора, ведения и анализа информации о нештатных ситуациях на транспорте». Развитие Модуля СЦ осуществлено в рамках контракта от 19.05.2025 № ОК/25_09 на выполнение работ по развитию Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК - – ГОСТ Р 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.7. Сроки начала и окончания работ Начало работ: с даты заключения Контракта. Окончание работ: не позднее 15.12.2026. Работы выполняются в соответствии с этапами. Сроки выполнения этапов работ по развитию и технической поддержке Модуля СЦ определяются Календарным планом. Календарный план, приведен в разделе 5 настоящего ТЗ - 1.2. Шифр темы или номер контракта Присваивается Заказчиком по результатам организации закупочных процедур. 1.2.1. Предмет контракта Выполнение работ по развитию Модуля СЦ. Код по ОКПД2: 62.01.11.000 – услуги по проектированию и разработке информационных технологий для прикладных задач и тестированию программного обеспечения. Оказание услуг по технической поддержке Модуля СЦ. Код по ОКПД2: 62.02.30.000 – услуги по технической поддержке информационных технологий. Выполнение работ по развитию Модуля СЦ предусмотрено с учетом ключевых результатов (ОКР) Ведомственной программы цифровой трансформации Минтранса России на 2026-2028 (далее - ВПЦТ Минтранса России) в составе мероприятия № 103.002 «АСУ ТК» ИТ расхода 103.26.000005 «Развитие Информационно-аналитической системы регулирования на транспорте (АСУ ТК)»: · «Обеспечено информационное взаимодействие с Минобороны о происшествиях на транспортных объектах»; · «Обеспечена автоматизация формирования отчетов о нештатных ситуациях на транспорте, в том числе по данным внешних систем». Выполнение работ по технической поддержке АСУ ТК предусмотрено ВПЦТ Минтранса России в составе мероприятия № 103.002 «АСУ ТК» ИТ расхода 103.26.000021 «Эксплуатация Информационно-аналитической системы регулирования на транспорте (АСУ ТК)» - 1.3. Заказчик Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» (ФГБУ «СИЦ Минтранса России»). Адрес: 107078, Москва, Садовая-Спасская ул., д.18, стр. 1. Оператором Системы является Заказчик - Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» (ФГБУ «СИЦ Минтранса России) - 1.4. Подрядчик Определяется по результатам проведения конкурентной процедуры закупки в соответствии с требованиями Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (далее – Федеральный закон № 44-ФЗ) - 1.5. Основания для выполнения работ Работы осуществляются на основании следующих документов: – постановление Правительства Российской Федерации от 30.12.2003 № 794 «О единой государственной системе предупреждения и ликвидации чрезвычайных ситуаций»; – постановление Правительства Российской Федерации от 08.11.2013 № 1007 «О силах и средствах единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций»; – распоряжение Правительства Российской Федерации от 27.11.2021 № 3363-р «О Транспортной стратегии Российской Федерации до 2030 года с прогнозом на период до 2035 года»; – Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 26.08.2025 №ЕФ-3; – Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 27.11.2025 №ЕФ-23; - 1.8. Общие сведения об источниках и порядке финансирования работ Источником финансирования являются средства субсидии федерального бюджета Российской Федерации, предоставленной в соответствии с абзацем вторым пункта 1 статьи 78.1 Бюджетного кодекса Российской Федерации (код цели 08-01) - 1.9. Порядок оформления и предъявления результатов работ Подрядчик должен передать Заказчику результаты работ в порядке, определенном Контрактом в сроки, установленные п. 5 настоящего ТЗ, в соответствии с Календарным планом - 1.10. Место выполнения Работ Работы выполняются удаленно на комплексе технических средств Заказчика. Адрес размещения комплекса технических средств Заказчика: Московская обл., Богородский район, пос. Горбуша, Радиоцентр. Техническая возможность удаленного подключения обеспечивается Заказчиком (в части предоставления параметров доступа). Оплата телематических и иных услуг, технических и программных средств, необходимых Подрядчику для удаленного подключения и для выполнения требований по информационной безопасности, осуществляется Подрядчиком самостоятельно за свой счет - – Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 19.02.2026 №ЕФ-1; – План мероприятий по профилактике случаев непроизводственного травматизма граждан на железнодорожном транспорте, являющийся приложением к постановлению коллегии Министерства транспорта Российской Федерации от 11.03.2026 № 2 - 1.6. Перечень документов, требования которых должны быть учтены при выполнении работ – Федеральный закон Российской Федерации от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации»; – Федеральный закон Российской Федерации от 27.07.2006 № 152-ФЗ «О персональных данных»; – Федеральный закон Российской Федерации от 06.04.2011 № 63-ФЗ «Об электронной подписи»; – Федеральный закон Российской Федерации от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации»; – Указ Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации»; – Указ Президента Российской Федерации от 01.05.2022 № 250 «О дополнительных мерах по обеспечению информационной безопасности Российской Федерации»; – Указ Президента Российской Федерации от 31.03.2010 № 403 «О создании комплексной системы обеспечения безопасности населения на транспорте»; – постановление Правительства Российской Федерации от 30.07.2004 № 395 «Об утверждении Положения о Министерстве транспорта Российской Федерации»; – постановление Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации»; – постановление Правительства Российской Федерации от 16.11.2015 № 1236 «Об установлении запрета на допуск программного обеспечения, происходящего из иностранных государств, для целей осуществления закупок для обеспечения государственных и муниципальных нужд»; – постановление Правительства Российской Федерации от 23.12.2024 № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц»; - 2. ЦЕЛИ И НАЗНАЧЕНИЕ ВЫПОЛНЕНИЯ РАБОТ - 2.1. Назначение АСУ ТК АСУ ТК предназначена для автоматизации и информационно-аналитического обеспечения процессов управления развитием транспортного комплекса Российской Федерации, обеспечения публичности деятельности органов государственного управления транспортным комплексом. Основными целями АСУ ТК являются: – повышение эффективности процессов управления функционированием и развитием транспортного комплекса на основе создания единой информационной среды и комплекса информационно-аналитических услуг на уровне органов государственного управления ТК; – повышение уровня безопасности ТК на базе получения полной, достоверной и оперативной информации о происходящих изменениях, своевременного выявления негативных тенденций и для принятия соответствующих мер по их устранению и ликвидации последствий - - Значение характеристики не может изменяться участником закупки - Основными задачами АСУ ТК являются: – автоматизация процессов прогнозирования развития транспортного комплекса и поддержки принятия управленческих решений; – автоматизация процессов мониторинга безопасности и устойчивости транспортного комплекса, управления в чрезвычайных и нештатных ситуациях; – автоматизация процессов управления программами и проектами развития и модернизации транспортного комплекса; – автоматизация процессов мониторинга состояния транспортного комплекса, в том числе с использованием набора ключевых показателей эффективности деятельности транспортного комплекса; – информационно-технологическая поддержка взаимодействия субъектов транспортного комплекса Российской Федерации, органов государственного управления и контроля, международных организаций на основе создания единой технологической среды взаимодействия и управления движением данных (и связанных с ними документов) в транспортном комплексе; – использование в процессах управления транспортным комплексом РФ современных технологий электронного документооборота и электронного обмена данными; – организация межведомственного электронного взаимодействия подразделений Министерства транспорта Российской Федерации, подведомственных агентств и службы с другими организациями - 2.2. Назначение и цели развития и технической поддержки Модуля СЦ Назначение Модуля СЦ: – оперативный мониторинг нештатных и чрезвычайных ситуаций на транспорте ; – оповещение заинтересованных лиц и структур о нештатных и чрезвычайных ситуациях; – сбор, обработка и хранение данных о нештатных и чрезвычайных ситуациях. Целями развития Модуля СЦ являются: – расширение состава данных об оперативной обстановке на транспорте; – оптимизация процесса сбора данных об оперативной обстановке на транспорте; – повышение информированности пользователей за счет визуализация данных Модуля СЦ; – автоматизация процесса формирования отчетов о ЧС и нештатной ситуации на транспорте; – обеспечение информационного взаимодействия с заинтересованными организациями по вопросам ведения. - Целями оказания услуг по технической поддержке являются: – обеспечение информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы; – поддержание параметров функционирования ППО Системы, удовлетворяющих требованиям производственных процессов, включая их непрерывность; – обеспечение бесперебойного функционирования ППО и своевременное устранение сбоев и аварийных ситуаций в Системе; – своевременное устранение уязвимостей при выявлении таковых, в соответствии с требованиями к обеспечению информационной безопасности; – адаптация, конфигурирование, коррекция программного обеспечения в соответствии с изменениями нормативно-правовой базы и запросами уполномоченных сотрудников органов государственной власти, включая выполнение процедур тестирования и участие в обновлениях ППО на стендах Заказчика; – обеспечение сохранения работоспособности ППО в изменяемой среде эксплуатации; – ведение документации по настоящему ТЗ, инициирование и актуализация документации на Систему по результатам обработки запросов Заказчика и внесении соответствующих изменений в ППО. Модуль СЦ применяется в деятельности Министерства транспорта Российской Федерации, подведомственных агентств и службы и другими организациями в соответствии с соглашениями об информационном обмене - 3. ХАРАКТЕРИСТИКА ОБЪЕКТА АВТОМАТИЗАЦИИ - Таблица 1 – Перечень платформенных решений и функциональных задач АСУ ТК № Наименование подсистемы/ функциональной задачи/ модуля Назначение 1 Подсистема сбора данных и централизованного хранилища данных Подсистема обеспечивает выполнение сбора данных в АСУ ТК, и в т. ч., в рамках функциональных задач «Формирование и ведение межрегионального транспортного баланса пассажирских перевозок в дальнем (межрегиональном) сообщении» и «Формирование и ведение транспортного паспорта региона» 2 Подсистема информационного взаимодействия Подсистема информационного предназначена для обеспечения информационного взаимодействия подсистем АСУ ТК, а также, взаимодействия АСУ ТК с АС федеральных органов исполнительной власти 3 Подсистема ведения нормативно-справочной информации и метаданных Подсистема предназначена для автоматизации функций формирования и актуализации справочников, классификаторов, реестров и регистров, необходимых для обеспечения информационной поддержки пользователей НСИ и интеграции подсистем АСУ ТК в части применения НСИ 4 Модуль СМЭВ Модуль взаимодействия со СМЭВ представляет собой набор сервисов взаимодействия: сервис синхронного взаимодействия и сервис отправки, осуществляющих дополнительную обработку сообщений, отправляемых в СМЭВ и принимаемых из СМЭВ 5 Геоинформационная подсистема Программное обеспечение геоинформационной подсистемы предназначено для обеспечения смежных подсистем АСУ ТК возможностью работы с картографической информацией, в том числе, отображения на электронных картах объектов транспортной инфраструктуры и получения информации о местоположении, характеристиках контролируемых транспортных объектов 6 Подсистема информационного портала АСУ ТК Подсистема информационного портала предназначена для отображения и входа в функциональные задачи АСУ ТК 7 Подсистема технического портала АСУ ТК Подсистема технического портала АСУ ТК предназначена для управления заявками пользователей и технологического документооборота заявок - - Значение характеристики не может изменяться участником закупки - 8 Подсистема проектного архива АСУ ТК Подсистема проектного архива АСУ ТК предназначена для автоматизации деловых процессов должностных лиц Министерства транспорта Российской Федерации, подведомственных агентств и службы, в том числе, и процессов информационного взаимодействия внутреннего и внешнего характера 9 ФЗ «Реестр объектов» Функциональная задача предназначена для формирования и ведения единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации 10 ФЗ «СТП» Функциональная задача предназначена для организации информационно-аналитической поддержки процессов территориального планирования Российской Федерации в области федерального транспорта 11 ФЗ «МРТБ ПП» Функциональная задача предназначена для формирования и ведения межрегионального транспортного баланса пассажирских перевозок в дальнем (межрегиональном) сообщении 12 ФЗ «МДД» Функциональная задача предназначена для осуществления мониторинга дорожного движения 13 ФЗ «ТПР» Функциональная задача предназначена для формирования и ведения транспортного паспорта региона 14 ФЗ «Данные по грузообороту» Функциональная задача предназначена для обеспечения подсистем и пользователей АСУ ТК данными по грузообороту между Российской Федерацией и зарубежными странами 15 ФЗ «МЖТ» Функциональная задача предназначена для осуществления мониторинга железнодорожного транспорта 16 ФЗ «МГМП» Функциональная задача предназначена для осуществления мониторинга грузопотоков в морских портах с целью формирования единой цифровой среды мониторинга и планирования перевозок в/из портов Дальнего Востока - 17 Модуль ГЭТ Модуль предназначен для получения, хранения данных инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по отдельно взятому предприятию-перевозчику. Формирования отчетов об инвентаризации с детальными данными по каждому разделу инвентаризации с маршрутизацией в муниципалитет / регион / Минтранс. Содержит агрегированные данные инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по всем перевозчикам, относящихся к данному муниципалитету. Формирует сводный отчет по муниципалитету по каждому разделу инвентаризации с маршрутизацией в регион / Минтранс. Формирует агрегированные данные инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по всем перевозчикам, относящиеся к данному региону и по всем муниципалитетам, относящимся к данному региону. Аналитические и статистические данные о состоянии ГЭТ региона. Содержит данные о видах транспорта, цифровых транспортных сервисах и платежных инструментах Региона. Формирует сводный отчет по каждому разделу инвентаризации с маршрутизацией в Минтранс. Формирует агрегированную статистику и аналитику по всем регионам страны в разрезе транспортных средств, маршрутов, пассажиропотоков, инфраструктуры ГЭТ. Данные о рейтинге регионов и перевозчиков на основании выбранных параметров, документооборот с участниками Системы: получение подписанных печатных форм, их утверждение, возврат на доработку. 18 Модуль iМинтранс Модуль создан для отчета по ключевым показателям транспортного комплекса России (Отраслевые и статистические показатели, исполнение бюджета, исполнение поручений, аналитика СМИ, происшествия по видам транспорта). 19 Модуль СЦ Модуль СЦ предназначен для оперативного мониторинга нештатных ситуаций транспортной отрасли, оповещения заинтересованных лиц и структур и предоставления данных о нештатных ситуациях - АСУ ТК осуществляет идентификацию и авторизацию посредством Единой системы идентификации и аутентификации (ЕСИА). Информационный обмен с внешними информационными системами осуществляется посредством СМЭВ 3 и СМЭВ 4. АСУ ТК развернута на вычислительных мощностях ГЦОД СИЦ Минтранса России - 3.2. Описание и текущее состояние объекта автоматизации Модуля СЦ Объектом автоматизации является процесс организации мониторинга информации о НС и ЧС на транспорте. Предметом деятельности Учреждения являются следующие функции: – информационное обеспечение в области транспортной безопасности, защиты населения и территорий от чрезвычайных ситуаций природного и техногенного характера в транспортном комплексе; – подготовка справочных материалов при угрозе возникновения и возникновении чрезвычайных ситуаций и иных происшествий в транспортном комплексе; – взаимодействие и обмен оперативной информацией с органами управления Единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций; – организация оперативного мониторинга обстановки на объектах транспорта при угрозе и возникновении чрезвычайных ситуаций и иных происшествий. Перечень компонентов Модуля СЦ и выполняемые ими функции представлены в Таблице 2 - Таблица 2. Перечень компонентов Модуля СЦ и их функции № п/п Компонент Выполняемые функции 1 Регистрация событий – ведение карточки события; – удаление комментария; – динамическое отображение существующих событий в заданном радиусе и за заданный период; – возможность автоматической проверки вводимых данных в части количества пострадавших; – отображение карточки ОТИ, ТС в соответствии с ФЗ Реестр объектов; – сохранение и отображение версии карточки события; – привязка события к координатам по картографической основе; – указание признака выполнения действия по отработке события; – перевод статуса события; – закрытие карточки события; – публикация информации о событии в канале мессенджера; – возможность перехода из карточки события на картографическую основу для просмотра местоположения события 2 Визуализация – отображение событий на картографической основе в виде пиктограмм; – масштабирование карты; – отображение краткой карточки события при выборе события на картографической основе; – отображение списка событий; – отображение карточки события; – отображение журнала действий пользователя; – отображение дополнительной информации (текстовая информация и приложенные файлы); – отображение справки о событиях и отчета о событиях; – отображение фильтров и количества отфильтрованных объектов; – отображение результатов поиска; – отображение статистики по событиям на экране; – возможность создания события с картографической основы; – отображения картографических слоев в зависимости от примененных фильтров; – возможность настройки шага картографической сети; – возможность настройки географической точки центра карты; – отображение количества непрочитанных сообщений; – возможность перехода к детальной карточке события из краткой карточки события при выборе события на картографической основе - 3 Информирование – ведение справочника способов оповещения (веб-интерфейс, мессенджер); – формирование сценария выполнения оповещения (настройка условий, способа, параметров оповещения); – выполнение оповещений пользователей 4 Отчетность – формирование отчета и справки о событиях; – фильтрация событий для выгрузки в справку о событиях или в отчет о событиях 5 Администрирование – ведение ролей пользователей; – ведение учетных данных пользователей; – ведение справочника организаций; – ведение справочника групп системы мгновенного обмена сообщениями; – выполнение исходящего звонка на контактный телефонный номер организации; – формирование матрицы эскалации событий Архитектура Модуля СЦ представлена на рисунке 1. Рисунок 1. Архитектура Модуля СЦ - 3.3. Состав используемого ПО Модуля СЦ Программная архитектура Модуля СЦ разработана как трехуровневая клиент-серверная архитектура. Архитектура включает в себя следующие уровни: • уровень представления – презентационный уровень, обеспечивающий взаимодействие с пользователя с клиентскими приложениями с использованием веб-браузера («тонкий» клиент); • уровень приложений – реализован в виде сервисов, обеспечивает обработку запросов, поступающих от клиентских приложений, формирование ответов на запрос в доступном пользователю виде (формирование пользовательских интерфейсов); • уровень хранения данных – реализуется как сервер БД и обеспечивает хранение и целостность хранимых данных, создание резервных копий, ведение журнала транзакций, восстановление данных после сбоев. Программная архитектура Модуля СЦ включает в себя сервисы и интерфейсы, указанные в Таблице 3. Таблица 3. Программная архитектура Модуля СЦ Программный сервис/интерфейс Технологии реализации Уровень представления Интерфейс пользователя и администратора (front-end) Javascript Уровень приложений Сервис (GateWay) Kotlin Сервис геокодирования (geocoding-service) Kotlin Сервис уведомлений (notifiсation-service) Kotlin Сервис работы с файлами (file-service) Kotlin Сервис отчетности (report-service) Kotlin Сервис управления событиями (event-service) Kotlin Сервис информирования через мессенджер (messenger-notifier) Python Сервис внешних интеграций (integration-service) Сбор информации из внешних систем и сервисов Брокер сообщений Kafka Уровень хранения данных Файловое хранилище MinIO S3 СУБД Postgres Pro Enterprise - 3.4. Информационное взаимодействие программных сервисов и интерфейсов Модуля СЦ Объект автоматизации функционирует в распределенной информационной среде. Обмен данными осуществляется по защищенным каналам связи (в том числе ведомственным сетям передачи данных). Источники информации включают: · внешние автоматизированные системы (органов государственной власти); · внутренние базы данных (реестры объектов транспортной инфраструктуры, паспорта регионов и пр.); · оперативная информация от персонала, поступающая через автоматизированные рабочие места (АРМ) и мобильные устройства. 3.4.1. Взаимодействие Модуля СЦ со смежными подсистемами АСУ ТК Модуль СЦ входит в состав АСУ ТК и взаимодействует со следующими ее функциональными задачами и подсистемами: · Функциональной задачей «Формирование и ведение единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации» (ФЗ «Реестр объектов»); · Геоинформационной подсистемой АСУ ТК (П-ГИС); · Подсистемой ведения нормативно-справочной информации и метаданных (П-НСИ); · Подсистемой сбора данных и централизованное хранилище данных (П-СД); · Подсистемой информационного взаимодействия (П-ИВ). 3.4.2. Взаимодействие с внешними информационными системами Список внешних информационных систем, с которыми осуществляется взаимодействие Модуля СЦ: · ЕСИА; · мессенджер; · Яндекс Геокодер; · Информационная система «Централизованная система сбора информации систем-112»; · ПВК «Поиск-Море», АИС РПТ; · облачная АТС - 3.5. Требования к эксплуатации Применяемое в Системе программное обеспечение, программно-аппаратные и аппаратные комплексы должны соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации» - 3.1. Описание объекта автоматизации АСУ ТК Объектом автоматизации являются процессы основной и обеспечивающей деятельности, направленные на управление транспортным комплексом, в том числе, процессы информационного взаимодействия с другими организациями и субъектами транспортного комплекса. АСУ ТК относится к государственным информационным системам, а также к информационным системам персональных данных и значимым объектам критической информационной инфраструктуры Российской Федерации. АСУ ТК соответствует требованиям, предъявляемым к: – ГИС второго класса защищенности в соответствии с приказом ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах»; – ИС персональных данных при обеспечении третьего уровня защищенности персональных данных в соответствии с требованиями постановления Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»; – значимым объектам КИИ Российской Федерации второй категории значимости с постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении Правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений». Модуль СЦ является подсистемой АСУ ТК. Перечень платформенных решений и функциональных задач АСУ ТК представлен в Таблице 1 - 4. ТРЕБОВАНИЯ К МОДУЛЮ СЦ - 4.2.4. Создание компонента «Интерактивная карта» (2 очередь) В составе создаваемого компонента должны отображаться данные, доступные в компоненте визуализации. Требования к интерфейсу интерактивной карты: – интерактивная карта должна быть представлена в виде объемной карты с учетом макетов, представленных в Приложении А к ТЗ; – интерфейс должен корректно отображаться на экранах мониторов (разрешение Full HD 1920?1080), телевизоров (разрешение 4К 3840?2160), жидкокристаллических панелей для видеостены, используемой Заказчиком, с параметрами каждой панели: диагональ 55 дюймов, разрешение 1920x1080; – интерфейс должен корректно отображаться на планшетных устройствах с диагональю экрана 10-12 дюймов, конкретные требования должны быть уточнены на этапе технического проектирования; – должна быть обеспечена кластеризация и генерализация отображения объектов на карте при изменении масштаба; – должно быть обеспечено отображение основных характеристик объектов при выборе их на карте; – должно быть обеспечено управление отображением слоев на карте; – должна быть обеспечена настройка цветовой индикации отображаемых объектов транспортной инфраструктуры; – должно быть обеспечено отображение легенды карты, содержащей отображаемые объекты на карте; – должна быть обеспечена возможность одновременного отображения не менее 5 000 ОТИ и ТС на карте. - - Значение характеристики не может изменяться участником закупки - На интерактивной карте должны быть отображены подвижные объекты совместно с объектами транспортной инфраструктуры (ОТИ), включая следующие возможности: § отображение местоположения транспортных средств (воздушный, водный и автомобильный транспорт) на карте в режиме реального времени (с заданным периодом обновления данных); § отображение маршрутов движения всех ТС за выбранный период времени, в том числе с использованием эффектов анимации; § отображение маршрутов движения ТС, связанных с карточкой события: ТС, являющихся участниками события, и ТС, находящиеся в заданном радиусе от события; § управление отображением сущностей и ОТИ на карте, включая настройку состава отображаемых объектов, поиск, фильтрацию, с использованием соответствующей панели управления и наглядным представлением результатов; § автоматическое изменение вида отображения объектов (цветовая индикация) по заданным условиям (например, при достижении критических значений параметров, характеризующих функционирование объекта); Должна обеспечиваться производительность обновления изображения на экране в 30 кадров в секунду на тестовой конфигурации пользовательского устройства (модель Бештау AIO2402/B560, входящая в Реестр российской промышленной продукции под номером 10394100 или аналог) при одновременном отображении не менее 5 000 объектов и 200 уникальных моделей объектов. Макеты интерфейсов Модуля СЦ должны быть предварительно согласованы с Заказчиком и разработаны с учетом требований ГОСТ Р ИСО 9241-161-2016 «Элементы графического пользовательского интерфейса» - Таблица 6. Категории обращений и заявок Категория Примеры Запрос на обслуживание Подготовка SQL запроса к СУБД для решения прикладной задачи и д.р. – запрос на любое действие, не являющееся запросом информации и несовершенный на основе происшествия, прямо или косвенно влияющего на работу Модуля СЦ Консультация «Где взять / куда обратиться...?», «Как сделать / выполнить…», «Как это работает…?» - запрос, имеющий своей целью получение информационной поддержки Инцидент Разбор ошибок/сбоев и подготовка материалов (корректировочных релизов, инструкций) для Заказчика для устранения ошибок/сбоев, которые приводят к частичному и полному нарушению работоспособности всех или отдельных функций ППО. Подготовка изменения и материалов, необходимых для проведения аварийно-восстановительных работ для возобновления работоспособности Модуля СЦ ЗНИ Подготовка изменений, связанных с изменением, улучшением/оптимизацией Модуля СЦ и выводом новой модифицированной функциональности в штатном режиме. Подготовка изменений, связанных с модификацией существующих и/или реализация новых интеграционных механизмов для получения/обработки данных внешних систем. Подготовка изменений графического интерфейса по требованиям Заказчика. Перечень статусов обращений (заявок) приведен в пункте 3.3. Регламента оказания Услуг. Назначение обращению (заявке) статуса «Закрыто» осуществляется Заказчиком только после получения от инициатора обращения (заявки) подтверждения о его исполнении или нахождения обращения (заявки) в статусе «Выполнено» и отсутствия повторных вопросов/запросов по данному обращению (заявки) в течение 5 рабочих дней. Категории и статусы обращений (заявок) могут быть скорректированы в процессе оказания услуг исключительно по согласованию с Заказчиком - 4.3.6. Требования к услугам технической поддержки 4.3.6.1. Требования к организации третьего уровня технической поддержки Основными задачами организации третьего уровня технической поддержки в рамках оказания услуг по технической поддержке Модуля СЦ являются организация эксплуатационной службы Подрядчика, проверка готовности технических и программных средств для обеспечения непрерывного функционирования ППО Модуля СЦ. Подрядчиком должны быть проведены организационно-штатные и подготовительные мероприятия (в т. ч. технические) в рамках организации технической поддержки Модуля СЦ. Подрядчик в течение 5 (пяти) рабочих дней с даты заключения Контракта должен: – определить и направить Заказчику документ «Перечень уполномоченных специалистов», содержащий контактную информацию (ФИО, должность, адрес рабочей электронной почты) лиц, ответственных за оказание услуг со стороны Подрядчика; – обеспечить подключение специалистов Подрядчика к Системе регистрации обращений (заявок) (СРО предоставляется Заказчиком) для оказания услуг; – согласовать с Заказчиком способ доступа Подрядчика к Модулю СЦ. Результат выполнения мероприятий фиксируется в Протоколе проверки результатов организационно-штатных и подготовительных мероприятий (см. Приложение Д к настоящему ТЗ) - 4.2.4.1. Требования к технической реализации компонента «Интерактивная карта» При реализации компонента «Интерактивная карта» должны учитываться требования, указанные ниже. 4.2.4.1.1. Требования к отображению элементов Повторяющихся элементы карты (ТС, ОТИ, события и пр.) должны отрисовываться с использованием аппаратного создания экземпляров объектов на пользовательском устройстве (WebGL/WebGPU)). Отрисовка каждого объекта отдельным запросом не допускается, должна обеспечиваться возможность одновременного отображения не менее 5 000 объектов без снижения производительности (30 кадров в секунду на тестовой конфигурации). 4.2.4.1.2. Уровни детализации объектов Для управления отображением сложных объектов должно быть создано не менее 3-х уровней детализации, отображаемых при изменении масштаба с возможностью автоматического переключения между уровнями. Все отображаемые объекты должны масштабироваться с учетом разрешения экрана пользователя с сохранением качества детализации. 4.2.4.1.3. Полигональная оптимизация и текстурирование При реализации компонента «Интерактивная карта» должна обеспечиваться технология рельефного тестурирования объектов. Не должны использоваться высокополигональные трехмерные модели. Все повторяющиеся элементы должны генерироваться единоразово и повторно использоваться при последующих отображениях. 4.2.4.1.4. Управление памятью Требуется реализовать потоковую загрузку на устройство пользователя элементов карты и текстур. Загрузка данных целиком при старте приложения не допускается. Необходимо реализовать механизм очистки памяти от элементов, которые находятся вне области видимости камеры в течение заданного времени. 4.2.4.1.5. Требования к взаимодействию пользователя с интерфейсом компонента «Интерактивная карта» Программная реализация механизмов управление камерой (масштабирование и навигация) должна быть выполнена с поддержкой технологии WebAssembly (WASM). Элементы управления должны являться неотъемлемой частью интерактивной карты. - 4.2.5. Развитие компонента администрирования (3 очередь) Должна быть выполнена доработка ролевой модели. Ролевая модель должна обеспечивать управление доступом к отдельным объектам Модуля СЦ и их элементам (атрибутам) с разграничением по видам транспорта, регионам и пр., в частности: – определение набора конкретных действий, доступных пользователям (выполняемых над объектом доступа, например, удаление записи, редактирование записи, формирование отчета и др.); – реализация возможности объединения пользователей в группы; – определение прав доступа для групп пользователей; – реализация интерфейса визуальной настройки прав доступа пользователей к объектам Модуля СЦ - 4.3.6.2. Требования к услугам информационно-консультационной поддержки работников Заказчика и пользователей Модуля СЦ Услуги информационно-консультационной поддержки сотрудников Заказчика включают: – обработку обращений и заявок, поступивших от сотрудников Заказчика; – консультирование сотрудников Заказчика и пользователей Модуля СЦ; – актуализацию документации, и других материалов по работе с Модулем СЦ при необходимости. – консультирование и разработку рекомендаций по настройке Модуля СЦ (без изменения программного кода), включая изменение настроек функционирования; – консультации по вопросам использования, настройки и возможностям Модуля СЦ; – консультации по проведению превентивных мер для недопущения аварийных ситуаций в Модуле СЦ; – консультации по предварительной диагностике и локализации возникшей неисправности Модуля СЦ; – консультации по вопросам обеспечения информационной безопасности Модуля СЦ и настройки функций, обеспечивающих корректную работу программного обеспечения для совершения юридически значимых действий в Модуле СЦ; – другие вопросы, связанные с работой Модуля СЦ. 4.3.6.2.1. Требования к порядку оказания услуг информационно-консультационной поддержки работников Заказчика и пользователей Модуля СЦ Подрядчик выполняет консультирование сотрудников Заказчика и пользователей Модуля СЦ. Консультация может быть предоставлена по согласованным с представителем Заказчика каналам коммуникации с регистрацией результата консультации в СРО Подрядчиком. Детальный порядок оказания консультационных услуг определен в Регламенте оказания Услуг - 4.3.6.3. Требования к услугам по решению инцидентов, связанных с работой ППО Подрядчик устраняет неисправности Модуля СЦ, связанные с работой ППО, выявленные в рамках оказания услуг согласно настоящему Техническому заданию, при этом в зону ответственности Подрядчика не входит устранение неисправностей, выявленных на стороне Заказчика и на стороне третьих лиц (провайдера связи, поставщика электропитания и т.д.). Первичная диагностика выявленной неисправности проводится на 1 и 2 уровнях технической поддержки и не входит в зону ответственности Подрядчика. Если при проведении первичной диагностики и попытке устранить неисправности на 1 и 2 уровнях технической поддержки, данную неисправность устранить не удалось и в процессе диагностики было выявлено, что проблема связана с работоспособностью ППО, обращение (заявка) назначается сотруднику Подрядчика, ответственному за оказание услуг технической поддержки 3 уровня. Инцидентами вне зоны ответственности Подрядчика являются: – работоспособность функциональности, выходящая за рамки текущей реализации функций в Модуле СЦ и/или являющаяся расширением требований Заказчика к функциям Модуля СЦ; – проведение профилактических и плановых работ, согласованных с Заказчиком; – нарушение работоспособности функций Модуля СЦ, вызванное проведением работ на стороне Заказчика - 4.2.6. Взаимосвязи с внешними автоматизированными системами (1 очередь) Способы взаимодействия с внешними информационными системами должны быть определены на этапе технического проектирования. Должны быть выполнены следующие доработки: – интеграции с информационными ресурсами в целях получения данных о движении подвижных ТС (воздушные суда, суда водного транспорта); – интеграция с информационным ресурсом в целях получения данных о событиях на железнодорожном транспорте. Реализация интеграций должна включать проектирование и реализацию интеграционных механизмов обмена данными с учетом доступных вариантов реализации, обеспечение защищенных способов взаимодействия, настройку отображения отдельных данных на карте (настройка слоев). Взаимодействия, имеющие каналы связи, выходящие за пределы контролируемой зоны взаимодействующих систем, считаются защищенными, если для их защиты используются программные и/или программно-аппаратные шифровальные (криптографические) средства, сертифицированные ФСБ России (далее – СКЗИ). Выбор СКЗИ, схемы подключения и требуемого класса криптостойкости должен производиться в соответствии с Техническими условиями на подключение к информационным ресурсам ФГБУ «СИЦ Минтранса России» и инструкциями по подключению пользователей к ресурсам инфраструктуры Головного центра обработки данных, утвержденных приказом директора ФБГУ «СИЦ Минтранса России» от 24.05.2024 № 21-ОД - 4.3. Требования к оказанию услуг по технической поддержке Модуля СЦ 4.3.1. Общие требования к оказанию Услуг Техническая поддержка Модуля СЦ должна осуществляться с учетом требований постановления Правительства Российской Федерации от 06.07.2015 N 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации». Подрядчик обязан выполнять требования законодательства в сфере защиты информации, требования по защите информации, информационной безопасности, указанные в локальных нормативных актах ФГБУ «СИЦ Минтранса России», регламентирующих условия информационного взаимодействия, защиты информации и подключения к информационным ресурсам ФГБУ «СИЦ Минтранса России», участвующих в информационном взаимодействии в рамках оказания услуг по технической поддержке АСУ ТК в 2026 году - 4.3.1.1. Требования к составу и содержанию услуг третьего уровня технической поддержки Оказание услуг по технической поддержке Системы осуществляется в рамках этапов в соответствии с календарным планом. Подрядчик в течение 5 рабочих дней с даты заключения Контракта должен предоставить со своей стороны, а Заказчик со своей стороны Матрицу ответственных за взаимодействия в соответствии с Приложением 1 к Регламенту оказания услуг по третьему уровню технической поддержки Модуля СЦ (далее – Регламент, Приложение В). Подрядчик в течение 10 рабочих дней с даты заключения Контракта должен провести мероприятия по организации третьего уровня технической поддержки в соответствии с Регламентом. Услуги по третьему уровню технической поддержки Модуля СЦ должны включать: – организацию Подрядчиком третьего уровня технической поддержки; – информационно-консультационную поддержку работников Заказчика; – решение инцидентов, связанных с работой ППО; – адаптационное, конфигурационное и коррекционное сопровождение Модуля СЦ (в рамках действующих программных модулей и функциональности); – устранение уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности - Работы по устранению неисправности приостанавливаются (по согласованию с Заказчиком) в следующих случаях: – если Подрядчиком в результате диагностики выявлено, что неисправность находится в зоне ответственности Заказчика. Подрядчик информирует Заказчика о выявленной неисправности в зоне его ответственности по согласованным каналам связи; – требуется действие со стороны Заказчика – до момента выполнения данного действия Заказчика. Заказчик информируется о необходимых действиях по согласованным каналам связи; – отсутствие возможности связаться со специалистами Заказчика, участие которых необходимо для устранения неисправности; – требуется доставить оборудование на объект – до момента доставки и установки оборудования. В случаях, представленных выше, время приостановки работ не входит в учет продолжительности устранения неисправности. Учет времени устранения неисправности Подрядчиком считается с момента назначения Инцидента специалисту Подрядчика, ответственному за оказание услуг технической поддержки 3 уровня. Подтверждение необходимости приостановления работ находится в зоне ответственности Подрядчика. Приостановление сроков выполнения задач в соответствии с настоящим пунктом подтверждается Заказчиком по мотивированному обращению Подрядчика в СРО, основанному на данных диагностики или на иных фактических обстоятельствах - В случае непринятия Подрядчиком необходимых мер по информированию Заказчика (отсутствие надлежащего обращения от Подрядчика или отсутствие уведомления о необходимости осуществления каких-либо действий Заказчиком) не может являться основанием для приостановления работ по устранению неисправности. В отдельных случаях Подрядчику может потребоваться выполнение технологических работ для устранения причин неисправности или недопущения повторения их в будущем. Для обеспечения устранения неисправности Модуля СЦ Заказчиком проводится классификация в соответствии с приоритетами по степени срочности их устранения. Продолжительность устранения неисправности, а также периодичность информирования Подрядчиком Заказчика о ходе устранения неисправности, определены в Регламенте оказания услуг. При подаче обращения (заявки) наивысшего приоритета через СРО Заказчик должен дополнительно проинформировать службу поддержки Подрядчика о созданном обращении (заявки) по телефону уполномоченного сотрудника Подрядчика. При этом временем подачи обращения (заявки) считается время подачи обращения (заявки) через СРО - 4.4.7.1.5. Требования к используемым зависимостям (библиотекам) Все внешние зависимости проекта должны быть зафиксированы с указанием точных версий. Для контроля версий зависимостей в репозиторий обязательно должны быть включены следующие файлы: · Для JavaScript: package-lock.json или yarn.lock; · Для Python: requirements.txt (с зафиксированными версиями) или Pipfile.lock; · Для Go: go.mod и go.sum; Загрузка всех зависимостей должна производиться исключительно через внутренний прокси-репозиторий Заказчика, настроенный в соответствующем системе менеджере пакетов. Запрещается: · Использование плавающих версий (например, ^1.2.3, ~4.5.0, latest); · Использование библиотек, содержащих критические уязвимости, в том числе зарегистрированные в реестре CVE (Common Vulnerabilities and Exposures). 4.4.7.1.6. Требования к процессу непрерывной интеграции (CI) Сборка программного обеспечения, включая этапы компиляции, тестирования и анализа кода, должна выполняться исключительно в инфраструктуре непрерывной интеграции Заказчика. 4.4.7.1.7. Требования к хранению артефактов сборки Все артефакты сборки (результирующие пакеты, Docker-образы и т.д.) подлежат обязательному хранению в предназначенной для этого инфраструктуре Заказчика (артефакторий). Запрещается размещение финальных артефактов сборки на сторонних ресурсах - 4.4.8. Требования к техническому обеспечению Количество серверов, подключаемых и настраиваемых сервисов, их параметров, схемы соединений и настройки межсетевого взаимодействия должны быть согласованы с Заказчиком на этапе № 1 Техническое проектирование. Доступ к комплексу технических средств предоставляется Заказчиком по письменному запросу Подрядчика. Применяемые в Системе программно-аппаратные и аппаратные комплексы должны соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации», требованиям Постановления Правительства Российской Федерации от 23 декабря 2024 г. № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц». Модуль СЦ, работающий в составе АСУ ТК, развернут на вычислительных мощностях ГЦОД СИЦ Минтранса России - 4.5. Общие технические требования 4.5.1. Требования к численности и квалификации персонала и пользователей Модуля СЦ Программное обеспечение Модуля СЦ не должно требовать изменения штатной численности персонала Заказчика. Программное обеспечение Модуля СЦ не должно требовать наличия у пользователей дополнительной квалификации в сфере информационных технологий, кроме базовых знаний в обращении с персональным компьютером, базовых навыков работы в интернет-обозревателях и знаний о Модуле СЦ в объеме документов Руководство пользователя, Руководство администратора - По результатам анализа угроз безопасности информации программного обеспечения и испытаний по выявлению уязвимостей в программном обеспечении Системы должна быть предоставлена отчетная документация по формам, утвержденным в Руководстве, и артефакты сборочной среды, подтверждающие проведение испытаний по выявлению уязвимостей в программном обеспечении Систем. Уязвимости подлежат устранению в сроки, обозначенные Заказчиком. В случае обнаружения уязвимого компонента Подрядчик должен заменить/обновить библиотеки. В случае, если уязвимость не подлежит исправлению на программном уровне, Подрядчик должен разработать меры предотвращения угроз безопасности, в том числе правила безопасности для наложенных средств защиты, рекомендации по безопасной настройке конфигурации для устранения потенциальных уязвимостей и снижения рисков информационной безопасности. Уязвимости, найденные ФСБ России, ФСТЭК России, Минцифры России, Роскомнадзором в ходе исполнения Контракта, а также в течение гарантийного периода, должны быть устранены Подрядчиком за свой счет в сроки, согласованные с Заказчиком - 4.5.6. Требования к эргономике и технической эстетике Взаимодействие пользователей с Модулем СЦ должно осуществляться посредством визуального графического интерфейса. Ввод-вывод данных, прием управляющих команд и отображение результатов их исполнения должны выполняться в интерактивном режиме. Интерфейс должен быть рассчитан на преимущественное использование манипулятора типа «мышь», то есть управление Модулем СЦ должно осуществляться с помощью набора экранных меню, кнопок, значков и т. п. элементов. Клавиатурный режим ввода должен использоваться главным образом при заполнении и/или редактировании текстовых и числовых полей экранных форм. Все надписи экранных форм, а также сообщения, выдаваемые пользователю (кроме системных сообщений), должны быть на русском языке. Модуль СЦ должен обеспечивать проверку вводимых пользователем данных и предупреждать о некорректно введённых значениях - Экранные формы должны проектироваться с учетом требований унификации: – все экранные формы пользовательского интерфейса должны быть выполнены в едином графическом дизайне, с одинаковым расположением основных элементов управления и навигации; – для обозначения сходных операций должны использоваться сходные графические элементы, кнопки и другие управляющие (навигационные) элементы. Термины, используемые для обозначения типовых операций, а также последовательности действий пользователя при их выполнении должны быть унифицированы; – внешнее поведение сходных элементов интерфейса (реакция на наведение указателя «мыши», переключение фокуса, нажатие кнопки) должно реализовываться одинаково. Структура размещения информации и представление этой структуры в Модуле СЦ должны соответствовать следующим требованиям: – пункты меню в пользовательском веб-интерфейсе должны быть сгруппированы в соответствии с тематикой информации, функциональными задачами и технологией работы; – каждому пункту меню должна соответствовать только одна выполняемая функция; – при совершении пользователями ошибочных действий должны выдаваться сообщения об ошибках. Эскизы визуального оформления компонента «Интерактивная карта» представлены в Приложении А. - 4.3.6.3.1. Требования к порядку оказания услуги по решению инцидентов, связанных с работой ППО При поступлении от Заказчика обращения (заявки), являющегося неисправностью в работе Модуля СЦ (инцидентом), Исполнитель реагирует на инцидент в СРО в срок не более 30 минут с момента поступления. В случае необходимости, для решения инцидента ответственный специалист должен связаться с инициатором обращения (заявки) для уточнения условий воспроизведения проблемы или для получения дополнительных сведений. После получения необходимых сведений от инициатора обращения (заявки) ответственный специалист производит диагностику с целью выявления причины инцидента и возможных путей устранения. В случае, если инцидент невозможно решить без получения дополнительных сведений от инициатора, и не удается связаться с инициатором в течение пяти рабочих дней, обращение (заявка) отклоняется в связи с недостатком данных для его решения, Заказчику направляется уведомление об отклонении обращения (заявки). Время, в течение которого невозможно связаться с инициатором, вычитается из общего времени обработки обращения (заявки). Все попытки связаться с инициатором должны фиксироваться с указанием даты и времени попытки, используемого способа связи (номер телефона, адрес электронной почты) и результата попытки (не удалось дозвониться, абонент недоступен, и т.д.) - Факт и время решения инцидента должны быть зафиксированы и отражены в СРО. В случае, если причиной сбоя в работе Модуля СЦ является выход из строя аппаратного обеспечения или неработоспособность смежной информационной системы, время работы над инцидентом приостанавливается до момента устранения неисправности. В ходе решения инцидентов могут быть выявлены дефекты ППО Модуля СЦ. В случае обнаружения дефектов ППО, Подрядчик информирует об этом Заказчика. Исполнитель может быть привлечен к проверке результата устранения дефекта по инициативе Заказчика. Приоритеты инцидентов приведены в Приложении Б к ТЗ. Детальный порядок оказания услуги по решению инцидентов, связанных с работой ППО Модуля СЦ определен в Регламенте оказания Услуг - 4.3.6.4. Требования к услугам адаптационного, конфигурационного и коррекционного сопровождения и доработки Модуля СЦ (в рамках действующих программных модулей и функциональностей) Услуги адаптационного, конфигурационного и коррекционного сопровождения и доработки Модуля СЦ включают: – управление изменениями и адаптация функций Модуля СЦ; – изменение настроек функционирования Модуля СЦ; – внесение изменений и/или модификаций Модуля СЦ (в рамках действующих программных модулей и функциональностей), направленных на улучшение их работоспособности и функциональных возможностей; – подготовка и передача Заказчику SQL запросов в СУБД для получения агрегированной информации из Модуля СЦ, которую невозможно получить с использованием графического пользовательского интерфейса; – адаптация модулей интеграций со смежными информационными системами - 4.3.6.4.1. Требования к проведению изменений Основанием для внесения изменений является запрос от Заказчика. Все активности по внесению изменений должны быть согласованы с Заказчиком, а действия Подрядчика при оказании данной услуги должны быть зафиксированы. В рамках данного Технического задания изменениями считаются локальные доработки функционала Модуля СЦ, которые не должны приводить к необходимости выполнения дополнительных аттестационных испытаний или переаттестации АСУ ТК в соответствии с п. 33 приказа от 29.04.2021 № 77 «Об утверждении Порядка организации и проведения работ по аттестации объектов информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну». При необходимости внесения изменений в Модуль СЦ, не связанных с критичным инцидентом, существенно нарушающим работоспособность Модуля СЦ, Заказчик направляет Подрядчику обращение (заявку), в котором излагает суть изменения, которое требуется внести в Модуль СЦ. Исполнитель, в течение 3 (трех) рабочих дней с момента поступления соответствующего обращения (заявки), оценивает техническую возможность реализации запрашиваемого изменения и варианты реализации. По итогу проведения оценки Подрядчик направляет Заказчику заключение о возможности реализации данного изменения с описанием возможных вариантов реализации и согласует с Заказчиком проведение данного изменения - При проведении работ по изменению и адаптации Подрядчик должен: – обеспечить выполнение требований безопасной разработки программного обеспечения; – обеспечить предварительное проектирование технических решений и согласование с Заказчиком проекта реализации изменения; – использовать семантическое версионирование (SemVer) в работе, передать Заказчику все артефакты разработки (исходный код и сторонние библиотеки, конфигурации, сборочные и собранные образы и др.); – подготовить полноценное описание функционала, включенного в релиз, с необходимыми схемами и пояснениями к обновлению на стендах Заказчика; – обеспечить тестирование разработанного функционала на стендах Заказчика силами Подрядчика; – решение о переносе измененного ППО на продуктивный стенд принимается Заказчиком по итогу результатов проведенного тестирования; – обеспечить техническое сопровождение процедуры тестирования ППО и переноса измененного ППО на продуктивный стенд Заказчика; – обеспечить экстренное внесение соответствующих изменений в случае выявления некорректной работы продуктивного стенда Заказчика после проведения обновления по итогам разработанного изменения в кратчайшие сроки; – актуализировать при необходимости комплект эксплуатационной документации: o руководство пользователя; o руководство администратора; o иные документы (при необходимости). Результат выполнения изменений должен быть отражен в Отчете по оказанию услуг. Типы и приоритеты изменений могут быть скорректированы в процессе оказания услуг исключительно по согласованию с Заказчиком - 4.5.2. Требования к режимам функционирования Модуля СЦ Модуль СЦ должен предусматривать наличие следующих режимов работы: – штатный; – регламентный (профилактический); – аварийный. Основным режимом функционирования является штатный. В штатном режиме все компоненты корректно и полностью выполняют свои функции. Перерывов в работе как Модуля СЦ в целом, так и одного, либо нескольких компонентов не предусмотрено. Режим регламентного (профилактического) обслуживания предназначен для проведения работ по обновлению и техническому обслуживанию компонентов Модуля СЦ, а также резервному копированию данных. При работе в данном режиме допускаются перерывы в работе Модуля СЦ с предварительным информированием пользователей. Состав процедур по регламентному обслуживанию Модуля СЦ и их периодичность определяются Подрядчиком в процессе выполнения работ по созданию Модуля СЦ. В режиме регламентного (профилактического) обслуживания Модуль СЦ может функционировать с частичным ограничением своих функциональных возможностей, либо без ограничения, но со снижением показателей надежности и производительности. Перевод в данный режим работы должен осуществляться сразу после начала выполнения любой операции, отнесенной к этому режиму, с последующим возвратом в штатный режим функционирования сразу после ее завершения. Перевод в указанный режим должен осуществляться при возникновении необходимости проведения работ по обновлению и техническому обслуживанию компонентов Модуля СЦ, а также резервному копированию данных с условием предварительного оповещения пользователей. Аварийный режим функционирования характеризуется отказом одной или нескольких подсистем, вызванных выходом из строя аппаратного и/или программного обеспечения, а также в случае временной неработоспособности каналов связи между серверами. - В аварийном режиме осуществляется поиск неисправностей и проведение работ по их устранению. Перевод в аварийный режим должен осуществляться при возникновении сбоев, аварий и прочих незапланированных воздействий, сразу после наступления одной или нескольких аварийных ситуаций, с последующим возвратом в штатный режим функционирования сразу после окончания восстановительных работ. ПО Модуля СЦ должно обладать надежностью, обеспечивающей работу пользователей в произвольном режиме и оперативное восстановление работоспособности при сбоях. В целях обеспечения надежного функционирования ПО должно предусматривать: – сохранение целостности данных при нештатном завершении работы компонентов Модуля СЦ; – сохранение работоспособности программного обеспечения при некорректных действиях пользователя; – резервное копирование базы данных Модуля СЦ. – время восстановления работоспособности Модуля СЦ после отказа не более 4 часов. – отказоустойчивость на уровне 99% при единовременной количестве не менее 200 пользовательских сессий в Модуле СЦ. Указанные характеристики приведены без учета характеристик надежности инфраструктуры и времени передачи информации по каналам связи. При возникновении сбоев в аппаратном обеспечении, включая аварийное отключение электропитания, Модуль СЦ должен автоматически восстанавливать свою работоспособность (не требовать перенастройки) после устранения сбоев и корректного перезапуска аппаратного обеспечения - 4.5.7. Требования по сохранности информации при авариях В случае возникновения аварии или сбоя в процессе выполнения пользовательских задач должно быть обеспечено восстановление баз данных до состояния на момент последней завершенной Модулем СЦ транзакции, и структуры файлового хранилища. Все аварийные ситуации должны обрабатываться программно с выдачей соответствующих сообщений, с корректной обработкой ситуации (завершение транзакций, закрытие файлов и т.п.), без потери обрабатываемой информации. В Модуле СЦ должны быть предусмотрены меры, обеспечивающие целостность данных в случае отказа программного обеспечения или аппаратных средств, исключая случаи физического уничтожения носителя или нарушения функциональности носителя, операционной системы или СУБД по вине их производителя либо обслуживающего персонала. Используемые аппаратные и системные платформы должны обеспечивать сохранность и целостность информации в Модуле СЦ при полном или частичном отключении электропитания, аварии сетей телекоммуникации, полном или частичном отказе технических средств Модуля СЦ. Технические решения должны обеспечивать сохранность информации в случае возникновения следующих событий (аварий, отказов и т.п.): – отказ аппаратного обеспечения на сервере; – отключение питания на сервере; – отказ аппаратного обеспечения на рабочей станции; – отключение питания на рабочей станции администратора; – отказ линий связи, в том числе при осуществлении обмена данными - 4.5.8. Требования к защите от влияния внешних воздействий Требования к защите от влияния внешних воздействий не предъявляются - 4.5.9. Требования к патентной чистоте и патентоспособности 4.5.9.1. Исключительные права на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, базы данных, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, принадлежат Российской Федерации в лице Заказчика. Право собственности на результаты работ, отчетные документы и материалы, полученные в ходе выполнения работ по Контракту, принадлежат Российской Федерации в лице Заказчика и считаются переданными с момента подписания Сторонами Акта сдачи-приемки выполненных работ. Разработанное программное обеспечение поставляется вместе с исходными кодами. 4.5.9.2. Все проектные и технические решения должны отвечать требованиям четвертой части Гражданского кодекса Российской Федерации. Результаты Работ должны быть свободными от возможности предъявления любых прав и притязаний третьих лиц, основанных на промышленной, интеллектуальной или другой собственности. 4.5.9.3 Результаты выполненных Работ не должны повлечь необходимость осуществления Заказчиком закупок программного обеспечения (как исключительных, так и неисключительных прав) для обеспечения функциональности Системы в соответствии с Техническим заданием. При выполнении работ Подрядчик должен использовать только объекты интеллектуальной собственности, права на которые приобретены (получены) и используются без нарушений прав на интеллектуальную собственность третьих лиц или предоставлены Заказчиком - 4.3.6.4.2. Требования к изменению настроек функционирования Изменение настроек функционирования может проводиться в рамках допустимых пределов изменения функционирования, заложенных в архитектуру Модуля СЦ. Изменение настроек функционирования включает в себя изменение данных и справочников, изменение форм документов, формируемых Модулем СЦ, изменение и настройку форматов и версий передачи данных в смежные системы. Доработка программного кода Модуля СЦ может допускаться (в случае необходимости) при выполнении работ по адаптации функций Модуля СЦ в части изменения формата передачи данных в смежные информационные системы при условии соблюдения требований пункта 29.3 приказа ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации» - 4.3.6.5. Требования к услугам по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности По запросу Заказчика Подрядчик должен провести работу по приведению ППО в соответствие с требованиями по обеспечению информационной безопасности. Критичность уязвимости оценивается в соответствии в соответствии с Методическим документом ФСТЭК России «Методика оценки уровня критичности уязвимостей программных, программно-аппаратных средств» (утвержден ФСТЭК России 30.06.2025), а также с учетом ГОСТ 56545-2015 и международными стандартами (CVSS 3.0 и выше), и задает необходимый срок устранения. В процессе проведения Заказчиком обследования Модуля СЦ и выявления уязвимостей в ППО, связанных с исходным кодом Модуля СЦ и/или используемыми компонентами (библиотеками), Заказчик направляет Подрядчику обращение (заявку) на устранение, с указанием критичности и срочности принятия мер по устранению в СРО. - Подрядчик при оказании услуг по обновлению или устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности должен: – провести анализ уязвимостей и связанных с ними исходным кодом и/или используемыми компонентами (библиотеками); – выработать варианты устранения указанных уязвимостей и согласовать с Заказчиком их реализацию; – своевременно внести изменения в исходный код Модуля СЦ и/или используемые компоненты (библиотеки) и подготовить соответствующее обновление; – провести обновление Модуля СЦ в тестовом контуре Заказчика и проинформировать Заказчика о готовности проведения тестирования; – протестировать успешность обновления или устранения уязвимостей в ППО и корректность функционирования Модуля СЦ на тестовом контуре, совместно с Заказчиком; – при невозможности незамедлительного устранения уязвимости приоритетов «Критический» и «Высокий» Подрядчик обязан предоставить исчерпывающий список причин и согласовать план достаточных компенсирующих мер с ответственными сотрудниками Заказчика. Результат внесения изменений отображается в соответствующей записи в СРО и в составе Отчета об оказанных услугах - 4.3.6.5.1. Требования к порядку оказания услуг по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности Подрядчик в соответствии с приоритетами обращений и контрольными сроками исполнения (см. Приложение Б к ТЗ) оценивает техническую возможность и сроки устранения уязвимостей, и реализацию обновления Модуля СЦ. По итогу проведения оценки Подрядчик направляет в заявке СРО Заказчику заключение о возможности устранения уязвимостей и/или обновления в ППО и согласует с Заказчиком проведение данных работ - Технические меры по обеспечению надежности должны предусматривать: – резервирование критически важных компонентов и данных Системы и отсутствие единой точки отказа; – использование программного резервирования (программной избыточности); – изменение конфигурации используемых средств и применение специализированного ПО, обеспечивающего высокую надёжность. Организационные меры по обеспечению надежности должны быть направлены на минимизацию ошибок пользователей (а также обслуживающего персонала при эксплуатации и проведении работ по обслуживанию), минимизацию времени ремонта или замены вышедших из строя компонентов за счёт: – обеспечения для обслуживающего персонала требуемого уровня квалификации; – регламентации и нормативного обеспечения выполнения работ обслуживающим персоналом; – своевременной диагностики неисправностей. Расчетное значение коэффициента доступности Модуля СЦ должно составлять не менее 0,95. - 4.5.3. Требования по диагностированию Модуля СЦ Диагностирование Модуля СЦ должно осуществляться путем анализа записей в системных журналах СУБД, операционных систем серверов, а также с помощью встроенных средств диагностирования общего программного обеспечения Модуля СЦ. Диагностированию подлежат: – сбои и нарушения функционирования технического обеспечения (серверов) Модуля СЦ; – сбои и нарушения функционирования системного программного обеспечения серверов, используемых для работы Модуля СЦ; – сбои и нарушения функционирования прикладного программного обеспечения серверов, используемых для работы Модуля СЦ; – случаи недоступности (отсутствия ответа) или некорректные ответы внешних систем; – сбои и нарушения функционирования СУБД; – сбои при выполнении регламентных операций резервного копирования. При возникновении аварийных ситуаций либо ошибок в программном обеспечении диагностические инструменты должны позволять сохранять набор информации, необходимой для идентификации и устранения проблемы. Модуль СЦ и ее компоненты должны обеспечивать возможность диагностики своей работоспособности с возможностью интеграции с модулем мониторинга АСУ ТК. Набор передаваемых журналов и метрик должен быть определен на этапе технического проектирования - 4.5.4. Требования к надежности Должно быть предусмотрено сохранение работоспособности Модуля СЦ при некорректных действиях пользователя и сохранение целостности данных при нештатном завершении работы Модуля СЦ (отказ рабочей станции, потеря сетевого доступа и т.п.). Модуль СЦ должен предоставлять механизмы обеспечения сохранности данных через применение процедур резервного копирования и восстановления, описанных в документации на Систему. Ключевые показатели надежности информационной системы — допустимое время на восстановление работоспособности Модуля СЦ (RTO - recovery time objective) и/или допустимый интервал времени потери изменений в данных при сбоях/отказах (RPO – recovery point objective) должны быть определены Подрядчиком и согласованы с Заказчиком на этапе технического проектирования - 4.5.9.4. Подрядчик подтверждает, что обладает всеми правами на передачу Заказчику исключительных прав в соответствии с требованиями настоящего раздела Технического задания. В случае, если к Заказчику по вине Подрядчика будут предъявлены претензии в этой части, иски третьих лиц, связанные с нарушением их прав, Подрядчик принимает на себя такие претензии и иски и возмещает Заказчику все расходы и весь ущерб, понесенный в связи с ними. 4.5.9.5. Подрядчик обязан согласовать с Заказчиком необходимость использования при выполнении работ охраняемых результатов интеллектуальной деятельности, права на которые принадлежат Подрядчику или третьим лицам. 4.5.9.6. В случае, если при выполнении Работ используется готовое программное обеспечение (платформа, подсистема, СУБД и т.д.), которое становится частью (компонентом) Системы, Заказчику передаются полные исключительные права, или неисключительные права (путем заключения лицензионного/сублицензионного договора/соглашения) на такое программное обеспечение со следующими возможностями: – права передаются бессрочно (на весь срок действия исключительных прав); – территория действия Российская Федерация; – должно быть обеспечено право Российской Федерации (в лице Заказчика) передавать, дорабатывать, распространять, развивать результаты работ, созданные в процессе исполнения Контракта, а также перерабатывать такое программное обеспечение. Лицензионное (сублицензионное) соглашение (договор), Акт передачи прав, подписанные Подрядчиком, согласие правообладателя, оформленное в соответствии с положениями Гражданского кодекса Российской Федерации (в случае, если Подрядчик не является правообладателем такого программного обеспечения), инструкция по инсталляции, руководство администратора, руководство пользователя передаются Заказчику в сроки, установленные Техническим заданием для соответствующего функционала Системы - Лицензионное (сублицензионное) соглашение (договор) не может возлагать на Заказчика какие-либо обязанности (в т.ч. в части конфиденциальности, предоставления отчетности), не предусмотренные Контрактом. 4.5.9.7. Передача Заказчику исключительных прав, или простых (неисключительных) прав не может повлечь увеличение стоимости Контракта и/или изменение иных существенных условий Контракта. 4.5.9.8. Функциональность Модуля СЦ передается в объеме и в сроки, установленные Техническим заданием. 4.5.9.9. Нарушение условий настоящего раздела Технического задания, в т.ч. отсутствие соответствующего лицензионного (сублицензионного) соглашения (или договора), либо предоставление лицензионного (сублицензионного) соглашения (или договора), не соответствующего требованиям действующего законодательства Российской Федерации или требованиям Контракта, является нарушением существенных условий Контракта. 4.5.9.10. В случае, если в соответствии с пунктом 4.5.9.6 Заказчику передается исключительное право, такая передача осуществляется в порядке, установленном Гражданским кодексом Российской Федерации. 4.5.9.11. В случае, если при выполнении Работ положения пунктов 4.5.9.5-4.5.9.6 не применялись, Подрядчик в составе отчетной документации предоставляет об этом декларацию в свободной форме. Декларация должна содержать сведения о полном соответствии результата Работ требованиям Контракта, а также о неприменении при выполнении работ готового программного обеспечения (платформ, подсистем, СУБД и т.д.), которое стало частью (компонентом) Системы - 4.5.9.12. Передача Заказчику комплекта документов, материалов и сведений, предусмотренных нормативными правовыми актами Российской Федерации в сфере информационных технологий, защиты информации, правовой защиты интересов государства в области интеллектуальной собственности, включая документы, подтверждающие отказ авторов (разработчиков) от исключительных прав на передаваемые объекты интеллектуальной собственности в пользу Подрядчика, с проектами заявок на государственную регистрацию в установленном порядке прав Заказчика на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, базы данных, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, осуществляется Подрядчиком в составе отчетной документации, предусмотренной условиями Контракта. 4.5.9.13. По результатам выполнения работ по развитию системы должны быть подготовлены материалы для регистрации доработанной версии Системы (объекта учета) в НФАП в соответствии с требованиями постановления Правительства Российской Федерации от 30 января 2013?г. №?62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин» (с изменениями и дополнениями) в части обязательности размещения результатов работ в национальном фонде алгоритмов и программ для электронных вычислительных машин - 4.5.10. Требования по стандартизации и унификации К Модулю СЦ предъявляются следующие требования в части стандартизации и унификации: – работы по развитию Модуля СЦ должны производиться в соответствии с действующими стандартами и нормами Российской Федерации; – при создании и модернизации элементов Модуля СЦ следует руководствоваться действующими в Российской Федерации национальными стандартами и другими нормативно-техническими документами; – используемые оборудование и материалы, подлежащие обязательной сертификации, должны иметь соответствующие сертификаты; – ПО Модуля СЦ должно проектироваться и разрабатываться с учётом обеспечения требований унификации; – применяемые при создании Модуля СЦ технические (форматы данных, протоколы передачи и прочие) и организационные (регламенты, требования, инструкции) решения должны быть доступны и документированы в виде, достаточном для независимой (без обращения к Подрядчику) реализации третьими сторонами; – термины, обозначения и наименования, используемые в ПО, должны быть стандартизованы и унифицированы, выполнены на русском языке; – взаимодействие элементов и их внешнее поведение должно быть реализовано одинаково и производиться по единым правилам - 4.3.1.2. Требования к общему порядку оказания услуг Техническая поддержка Модуля СЦ должна быть организована на трех уровнях: – первый и второй уровни технической поддержки организуется Заказчиком; – третий уровень технической поддержки организуется Подрядчиком. Перечень действий на каждом уровне технической поддержки указан в Таблице 5: Таблица 5 – Перечень действий на каждом уровне технической поддержки Уровень технической поддержки Доступные действия Условия передачи задачи на следующий уровень Первый уровень технической поддержки (далее – 1-й уровень) – принимает обращения (заявки) пользователей Модуля СЦ и работников Заказчика; – регистрирует обращения в Модуле СЦ регистрации обращений; – присваивает уникальный идентификационный номер, классифицирует обращения; – самостоятельно решает обращения, которые связаны с недостаточной квалификацией пользователей или настройками в рамках своей компетенции; – взаимодействует с пользователями Модуля СЦ при решении проблемы Передает обращение на второй уровень поддержки в случае невозможности решения на своем уровне Второй уровень технической поддержки (далее – 2-й уровень) – принимает обращения от 1-го уровня; – уточняет классификацию обращения в результате дополнительного анализа; – самостоятельно решает обращения в рамках своей компетенции; – осуществляет техническую и консультационную поддержку Модуля СЦ; – взаимодействует с сотрудниками 1-го и 3-го уровня и пользователями Модуля СЦ; – формирует заявки для 3-го уровня и контролирует исполнение Передает обращение на третий уровень поддержки в случае невозможности решения на своем уровне Третий уровень технической поддержки (далее – 3-й уровень) – принимает обращения от 2-го уровня; – обеспечивает выполнение требований, предъявляемых Контрактом и настоящим Техническим заданием к Услугам, оказываемым Подрядчиком Все поступающие обращения должны быть исполнены Подрядчиком - Для обеспечения взаимодействия с Заказчиком Подрядчик со своей стороны определяет ответственных лиц, уполномоченных в структуре Подрядчика за своевременное и качественное оказание Услуг в рамках настоящего ТЗ, а также контактную информацию ответственных лиц (телефон, электронную почту). Подрядчик должен предоставить Заказчику единый адрес электронной почты для приема обращений (заявок) в течение 3 (трех) рабочих дней после заключения Контракта. Указанный в настоящем пункте адрес электронной почты (способ направления обращений (заявок) применяется в случае сбоя в работе СРО Заказчика. Со своей стороны, Заказчик предоставляет Подрядчику перечень и контактную информацию (телефон, электронную почту) уполномоченных лиц для осуществления взаимодействия с указанием зон ответственности. О любых изменениях в контактной информации ответственных лиц Стороны должны уведомить друг друга в течение 1 (одного) рабочего дня с момента возникновения таких изменений посредством уведомления на электронную почту ответственных лиц и/или в письменной форме. В результате оказания услуг по настоящему ТЗ не должны быть изменены исходные коды, дистрибутивы и иные компоненты Модуля СЦ вне согласованных с Заказчиком изменений. Любые изменения исходных кодов, дистрибутивов и иных компонентов Модуля СЦ должны производиться только после согласования с Заказчиком уполномоченными лицами по электронной почте или иным заранее согласованным способом. Не должна быть ухудшена надежность и производительность Модуля СЦ. Оказание услуг по Контракту не должно нарушать требования к информационной безопасности, описанной в документации на Модуль СЦ - 4.1. Требования к структуре Модуля СЦ В процессе работ по развитию Системы должны сохраниться основные требования к построению архитектуры Системы в соответствии с принципами трехуровневой архитектуры: 1. уровень хранения данных или уровень базы данных (сервер СУБД); 2. уровень сервера приложений (сервер аналитической обработки); 3. презентационный уровень, обеспечивающий взаимодействие с клиентскими приложениями. В состав Системы должны входить следующие основные компоненты: 4. сервер баз данных; 5. сервер приложений; 6. веб-сервер. Сервер баз данных должен обеспечивать хранение и целостность хранимых данных, создание резервных копий, ведение журнала транзакций, восстановление данных после сбоев. Сервер приложений должен обеспечивать обработку запросов, поступающих от клиентских приложений (через веб-сервер), формирование ответов на запрос в доступном пользователю виде (формирование пользовательских интерфейсов). Веб-сервер должен обеспечивать взаимодействие с оператором и внешними системами по HTTP / HTTPS протоколу в режиме «запрос-ответ» (получения запросов от пользователя и передачи ответа в виде соответствующей информации, обработанной серверами приложений). Взаимодействие Системы с пользователем должно отвечать требованиям модели «тонкого клиента» (т.е. представлять на стороне клиента (пользователя) лишь графический пользовательский интерфейс). Все составляющие Системы должны использовать единую методологию и отвечать единым принципам взаимодействия, надежности и управления. Перечень компонентов Модуля СЦ представлен в Таблице 4. Таблица 4. Перечень компонентов Модуля СЦ, в отношении которых выполняются работы по развитию № п.п. Наименование компонента Модуля СЦ Раздел ТЗ 1 Компонент регистрации событий 4.2.1. 2 Компонент отчетности 4.2.2 3 Компонент визуализации 4.2.3 4 «Интерактивная карта» (компонент создается) 4.2.4 5 Компонент администрирования 4.2.5 - 4.2. Требования к дорабатываемым функциям модуля СЦ 4.2.1. Развитие компонента регистрации событий (1 очередь) Должны быть выполнены следующие доработки: – обеспечение логирования действий пользователя, связанных с карточкой события; – доработка объектной модели в части создания новых типов сущностей (карточек) с учетом реализуемых интеграций с информационными ресурсами (силы и средства предупреждения и ликвидации ЧС и нештатных ситуаций на транспорте, ТС, ограничения воздушного пространства, неблагоприятные и опасные природные явления); – реализация механизма установления связи между сущностями в Модуле СЦ автоматизированным и ручным способами (события, природные явления, силы и средства предупреждения и ликвидации ЧС и нештатных ситуаций на транспорте, ограничения воздушного пространства, ОТИ, ТС и др.); – отображение в карточке установленных связей между сущностями. - Оказание услуг в рамках данного технического задания осуществляется Подрядчиком по обращению (заявке) Заказчика, направляемой посредством СРО Заказчика. Регистрация обращений, поступивших непосредственно в Модуль СЦ регистрации обращений Заказчика, производится сотрудниками Заказчика, которые обеспечивают первый уровень технической поддержки Модуля СЦ. В случае назначения приоритета «Критический» или «Высокий», информация о назначении также дублируется оповещением ответственных представителей Подрядчика посредством звонка на предоставленные номера телефонов. Обращение (заявка) должна содержать следующую информацию: – контакты пользователя/организации; – приоритет обращения, соответствующий Приложению 2 к Регламенту; – время обнаружения; – наименование компонента АСУ ТК - Модуль СЦ; Информация может быть расширена по согласованию с Заказчиком. Обращения (заявки) сотрудников Заказчика должны приниматься Подрядчиком через веб-интерфейс СРО. В процессе обработки обращений (заявок) Подрядчик должен обеспечить выполнение следующих процедур: – прием обращений(заявок) от сотрудников Заказчика; – оказание информационно-консультационной поддержки в соответствии с требованиями настоящего Технического задания; – информирование сотрудников Заказчика о статусе обработки и результатах обработки обращений(заявок). Подрядчик осуществляет обязательную регистрацию и учет всех обращений и заявок, поступивших к Подрядчику от представителей Заказчика в рамках оказания настоящих услуг - Примечание: в случае приостановки работы по обращению или заявке (обращение или заявка находится в статусе «Приостановлено»), указываются причины, по которым работы по обращению или заявке приостановлены с указанием перечня действий/информации, запрошенных у инициатора обращения, а также даты, формы и адресата такого запроса. В случае отклонения обращения или заявки (заполняется в случае, если обращению или заявке присваивается статус «Отклонено»), указываются подробно причины такого отклонения, а также фиксируется дата и время перехода в статус «Отклонено». В случае, если обращение или заявка отклонены (отменены) самим Инициатором, то указывается дата и способ, которым от инициатора получено соответствующее уведомление. В случае невыполнения Подрядчиком регламентного времени реагирования или решения обращения (заявки) Заказчик вправе отозвать обращение и направить его Подрядчику повторно. При этом каждое отозванное обращение учитывается в Отчёте об оказанных услугах, как обращение с превышением времени реагирования или решения, но оплате не подлежит. В случае, если обращение (заявка) связано с некачественным выполнением Подрядчиком другой задачи, такое обращение решается в регламентное время, установленное Техническим заданием, при этом оплате такие обращения не подлежат, о чем указывается в Отчете об оказанных услугах в графе «Примечание» - 4.2.2. Развитие компонента отчетности (3 очередь) Должна быть обеспечена автоматизация процессов формирования отчетов о ЧС и нештатных ситуациях на транспорте, в т.ч. на основе данных из внешних систем. Включает следующие доработки: – разработка шаблонов отчетов в различных форматах (табличный, текстовый); – реализация выбора фотоматериалов для включения в справку; – форматирование содержимого справок с учетом правил русского языка в отношении окончаний слов (в зависимости от падежа, склонения, числа и рода); – автоматизированное формирование выводов к содержимому справки на основе настраиваемых критериев; – создание интерфейса выбора параметров (фильтрации) для формирования отчетов: o состав полей для включения в отчёт; o настройка диапазонов значений характеристик и дат; o порядок отображения полей; o настройка заголовка. – реализация способа подготовки отчётов в асинхронном режиме (очереди); – реализация интерфейса компонента формирования отчетности для отображения очереди формирования отчетов и статусов их подготовки; – экспорт отчётов в форматы xlsx, csv и справок в форматы pdf, docx. Необходимо разработать не менее 10 шаблонов отчетов и/или справок. Перечень, структура и содержание шаблонов должны быть согласованы с Заказчиком на этапе технического проектирования. - 4.2.3. Развитие компонента визуализации (2 очередь) В рамках развития компонента визуализации должны быть выполнены следующие доработки, обеспечивающие: – вывод перечней (списков) сил и средств предупреждения и ликвидации ЧС и нештатных ситуаций на транспорте с отображением мест их постоянного размещения (дислокации) на карте, включая: o отображение зон ответственности на карте; o возможность их фильтрации (по видам транспорта, регионам и пр.); o реализацию инструмента расчета расстояния (с использованием сети автомобильных и железных дорог) между местом события и местами дислокации сил и средств, а также вывода маршрутов на карте; – отображение зон (полигонов) с установленными ограничениями движения в воздушном пространстве на карте; – отображение термических точек; – реализация возможности отображения данных из паспорта региона, отображаемого в модуле iМинтранс (модуль АСУ ТК); – отображение краткой карточки сущностей и ОТИ (краткой информации и/или динамических характеристик объекта) при выборе объекта на карте с возможностью перехода в полную карточку сущности и ОТИ; – отображение данных от Росгидромета, предусматривающих: o отображение неблагоприятных и опасных природных явлений на карте (с заданным периодом обновления данных); o управление отображением явлений на карте, включая настройку состава отображаемых объектов, поиск, фильтрацию, с использованием соответствующей панели управления; o выведение краткой карточки явления при выборе объекта, с возможностью перехода в полную карточку объекта - – отображение на карте связанных сущностей и ОТИ; – реализация функции выбора темного и светлого стилей отображения элементов интерфейса, карточек сущностей, картографической основы и объектов, отображаемых на карте; – реализация механизма для выбора картографической основы в одном из распространенных форматов WMTS, TMS, MVT и др. Должна быть предусмотрена возможность настройки перечня картографических основ и параметров доступа к ним; – настройка базового набора дашбордов, содержащих преднастроенные виджеты о количестве событий в разрезе видов транспорта с возможностью перехода к исходным данным (карточкам событий, ОТИ и т.д.), с фильтрацией по параметрам. Параметры фильтрации должны быть определены на этапе технического проектирования. Должно быть обеспечено автоматическое и принудительное обновление данных, отображаемых на дашбордах - 4.3.1.3. Требования к регламенту оказания услуг Подрядчик должен руководствоваться Регламентом оказания услуг по технической поддержке Модуля СЦ. Регламент оказания услуг содержит следующую информацию: – порядок оказания услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Модуля СЦ; – порядок оказания услуги по решению инцидентов, связанных с работой ППО; – порядок оказания услуги адаптационного, конфигурационного и коррекционного сопровождения Модуля СЦ (в рамках действующих программных модулей и функциональностей); – порядок оказания услуги по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности. – Регламент содержит следующие формы заявок на оказание услуг: – форма заявки на оказание услуги по информационно-консультационной поддержке сотрудников Заказчика; – форма заявки на оказание услуги по решению инцидентов, связанных с работой ППО; – форма заявки на оказание услуг адаптационного, конфигурационного и коррекционного сопровождения Модуля СЦ (в рамках действующих программных модулей и функциональностей) (приоритет заявки определяется Заказчиком); – форма заявки на оказание услуги по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности - 4.3.2. Требования к режиму обеспечения функционирования Модуля СЦ Режим оказания услуг определен в Приложении Б к настоящему ТЗ. По согласованию с Заказчиком, в целях недопущения остановки функционирования Модуля СЦ в период интенсивной работы пользователей в Модуле СЦ, отдельные услуги могут оказываться по специальному графику (в нерабочее время Подрядчика) в соответствии с заявками Заказчика - 4.3.3. Требования к качеству оказываемых услуг Качество оказываемых услуг поддерживается Подрядчиком в соответствии с определяемыми данным ТЗ условиями и правилами и контролируется Заказчиком на постоянной основе, в том числе по соблюдению сроков исполнения и подтверждениям исполнения от инициаторов обращений и другим параметрам. По результатам выполнения работ по устранению инцидента должна быть устранена корневая причина инцидента с окончательным решением, устраняющим причину возникновения проблемы и исключающим вероятность повторного возникновения проблемы (инцидента). Время устранения корневых причин проблемы (инцидента) не должно составлять более 40 рабочих часов - При проведении работ по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности необходимо выполнить следующее: – Заказчику сформировать заявку на устранение (обновление) в СРО с полным списком обнаруженных уязвимостей и планируемыми работами; – согласовать в рабочем порядке время начала и завершения работ, перечень работ, выполняемых в рамках обновления или устранения уязвимостей в ППО с Заказчиком; – оповестить Заказчика о начале проведения работ на тестовом контуре; – провести работы по обновлению или устранению уязвимостей в ППО на тестовом контуре Модуля СЦ в установленные сроки; – протестировать выполнение работ в тестовом контуре и проинформировать Заказчика о готовности переноса ППО на продуктивный контур; – силами Заказчика обновить продуктивный контур Модуля СЦ, в соответствии с планом устранения и выполненными работами; – совместно с Заказчиком проверить корректность функционирования Модуля СЦ и устранения уязвимостей в продуктивном контуре Модуля СЦ по результатам обновления; – при необходимости актуализировать документацию (описание архитектуры, анкеты постановки на мониторинг и иные документы). Любые изменения в части обновления или устранения уязвимостей в ППО на промышленном контуре Модуля СЦ должны применяться только в случае успешного проведения аналогичных работ на тестовом контуре. Детальный порядок оказания услуги по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности определен в Регламенте оказания Услуг - 4.4. Требования к видам обеспечения 4.4.1. Требования к лингвистическому обеспечению Документация на Модуль СЦ должна разрабатываться на русском языке. Взаимодействие пользователей с Модулем СЦ посредством графического интерфейса должно происходить на русском языке за исключением сообщений, зависящих от настроек системного программного обеспечения, установленного на рабочих местах пользователей. При разработке программных решений Модуля СЦ должно быть предусмотрено использование языков программирования высокого уровня, приведенных в Таблице 7. Таблица 7. Языки и средства разработки, специального программного обеспечения Модуля СЦ Категория Наименование Назначение Языки программирования Kotlin Разработка серверной логики и сервисов (backend) JavaScript / TypeScript Разработка клиентской части (frontend) Python Разработка скриптов интеграции, обработки данных и автоматизации Фреймворки и библиотеки Vue.JS Разработка пользовательских интерфейсов (веб-интерфейсы компонентов визуализации и отчетности) React Разработка пользовательских интерфейсов (при необходимости создания сложных интерактивных компонентов) Решения по лингвистическому обеспечению, включая перечень используемых языков программирования, должны быть согласованы с Заказчиком на этапе технического проектирования - 4.4.2. Требования к математическому обеспечению Требования к математическому обеспечению не предъявляются. 4.4.3. Требования к метрологическому обеспечению Требования к метрологическому обеспечению не предъявляются. 4.4.4. Требования к организационному обеспечению Требования к организационному обеспечению не предъявляются. 4.4.5. Требования к методическому обеспечению Задачи методического обеспечения Модуля СЦ должны быть обеспечены за счет использования технологических и методических документов касающихся вопросов функционирования транспортного комплекса и разработки и эксплуатации ПО. 4.4.6. Требования к информационному обеспечению Состав, структура и способы организации информационного обеспечения в Модуле СЦ должны быть определены на этапе технического проектирования. Факты информационного обмена с внешними системами должны фиксироваться в соответствующем журнале - 4.5.5. Требования к информационной безопасности Работы по защите информации/информационной безопасности, не включенные в состав настоящего раздела, требуемые в соответствии с требованиями постановления Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации», а также нормативно правовых актов в области защиты персональных данных и обеспечения безопасности объектов критической информационной инфраструктуры, будут проведены в рамках исполнения отдельного контракта, заключенного по результатам отдельной закупочной процедуры (не является частью данного ТЗ), включающего: – определение актуальных угроз безопасности информации и актуализация модели угроз безопасности информации (при необходимости); – выполнение требований о согласовании технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России в установленном порядке; – выполнение требований по устранению Подрядчиком замечаний и недостатков, в случае их выявления при согласовании Заказчиком технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России; – выполнение требований к классу защищенности ГИС, уровню защищенности персональных данных и категории значимости объекта КИИ РФ, установленных для Головного центра обработки данных ФГБУ «СИЦ Минтранса России» (далее – ГЦОД); - – определение перечня объектов защиты информационной системы; – описание (актуализированных) требований к системе защиты информации, а также к мерам защиты информации информационной системы в зависимости от установленных классов защищенности, уровня защищенности персональных данных и категории значимости объектов КИИ РФ (приказы ФСТЭК России № 21, 117, 239); – выполнение требований к мерам по защите ГИС от атак, направленных на отказ в обслуживании, в соответствии с пунктами 30, 34, 59, 63 Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений, утвержденных приказом ФСТЭК России от 11.04.2025 № 117; – описание (актуализированных) требований по защите информации, подлежащих реализации в информационно телекоммуникационной инфраструктуре ГЦОД; – выполнение требований о применении сертифицированных средств защиты информации, включая их классы защиты и уровни доверия; – выполнение требований о запрете использования с 01.01.2025 органами (организациями) средств защиты информации странами происхождения, которых являются иностранные государства в соответствии с пунктом 6 Указа Президента Российской Федерации от 01.05.2022 № 250; – выполнение требований по обеспечению непрерывного взаимодействия с ГосСОПКА в установленном порядке; - 4.5.11. Требования к показателям назначения 4.5.11.1. Требования к показателям назначения мероприятий по развитию Модуля СЦ В рамках выполнения работ по развитию Модуля СЦ, предусмотренных ТЗ, показатель назначения «Количество пользователей» должен соответствовать значениям, приведенным в данном разделе. Пояснения по показателям, связанным с количеством пользователей, приведены в Таблице 8. Таблица 8. Определения показателей, связанных с количеством пользователей в Модуле СЦ № Показатель Определение Расчетное количество пользователей Количество пользователей, работу которых должен обеспечить Модуль СЦ к моменту сдачи работ по Контракту с учетом достижения всех показателей назначения Расчетное количество одновременно работающих пользователей Количество одновременно работающих пользователей, работу которых должен обеспечивать Модуль СЦ к моменту сдачи работ по Контракту с учетом достижения всех показателей назначения Значения показателей количества пользователей, достижение которых необходимо обеспечить, представлено в Таблице 9 - Таблица 9. Значения показателей количества пользователей № Показатель Значение 1. Расчетное количество пользователей 1 000 2. Расчетное среднее количество одновременно работающих пользователей 200 Развитие Модуля СЦ должно быть направлено на достижение следующего эффекта (показателя), подставленного в мероприятии 103.002 «Информационно-аналитическая система регулирования на транспорте (АСУ ТК)» ВПЦТ Минтранса России: Выполнение работ по развитию Модуля СЦ предусмотрено мероприятием по развитию АСУ ТК, приведенном в ВПЦТ Минтранса России на 2026-2028 гг: № 103.002 «АСУ ТК» в составе ИТ расхода 103.26.000005 «Развитие предусматривает реализацию ОКР и эффектов, приведенных в Таблице 10. Таблица 10. ОКР и эффекты, приведенные в ВПЦТ Минтранса России на 2026 г. № ОКР Дата ОКР Эффекты 1 Обеспечено информационное взаимодействие с Минобороны России о происшествиях на транспортных объектах 25.12.2026 Сокращено время сбора и передачи сведений для Минобороны России о ЧС и НС на транспорте с 120 до 10 минут 2 Обеспечена автоматизация формирования отчетов о нештатных ситуациях на транспорте, в том числе по данным внешних систем 25.12.2026 Сокращено время на подготовку отчетов о нештатных ситуациях на транспорте с 20 до 5 минут Реализация остальных ОКР не является предметом данного ТЗ и проводится в рамках отдельного технического задания. - 4.5.11.2. Требования к показателям назначения мероприятий по эксплуатации Модуля СЦ. Работы по эксплуатации Модуля СЦ не должны обеспечивать режимы функционирования Модуля СЦ, приведенные в разделе 4.5.2 данного ТЗ - 4.3.4. Требования к документированию результатов оказываемых услуг Для обеспечения контроля оказываемых услуг по поддержке Модуля СЦ со стороны Заказчика, по окончании каждого отчетного периода по контракту в соответствии с календарным планом, Подрядчик обязан предоставить Заказчику Отчет об оказанных услугах. Отчет должен содержать детальную информацию об оказанных услугах с указанием даты выполненных мероприятий и приложением обосновывающих документов (заявок, запросов, требований) или ссылкой на такие документы, если они содержатся в Модуле СЦ. Информация о выполненных мероприятиях по заявкам должна быть сформирована на основании соответствующих записей СРО по каждому этапу исполнения Контракта. В случае оказания услуги адаптационного, конфигурационного и коррекционного сопровождения Модуля СЦ, должны быть предоставлены документы, подтверждающие выполнение требований п. 29.3 приказа ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации». Фактическое время реагирования и время решения по всем обращениям, поступившим в СРО, формируется в СРО по итогам отчетного периода в разделе «Отчеты». Фактическое время реагирования и время решения по обращениям учитывает суммарное время, затраченное на реагирование и, соответственно, на работу по обращению с момента назначения обращения специалисту Подрядчика или группе исполнителей, ответственным за оказание услуг технической поддержки 3 уровня от начала до завершения работ Подрядчиком. При этом принимается суммарное время нахождения заявки в соответствующих статусах заявки СРО на стороне Подрядчика - 4.3.5. Требования к классификации обращений и заявок Обращения и заявки Заказчика классифицируются в соответствии с приоритетами и регламентными сроками, указанными в Приложении 2 к Регламенту. Регистрация обращений и заявок предусматривает создание новой записи в СРО с присвоением поступившему обращению или заявке (новой записи) уникального идентификатора. Запись в СРО должна содержать вопрос или проблему, которую требуется решить или оказать консультацию. Состав обязательной информации, которую должно содержать обращение или заявка, зафиксирован в Регламенте оказания Услуг. Если обращение или заявка автоматически зарегистрированы в СРО при отправке представителем Заказчика, Подрядчик проверяет корректность классификации обращения или заявки и может обратиться к Заказчику с просьбой корректировки, предоставив обоснования в соответствии с настоящей классификацией (Таблица 6) - 4.4.7. Требования к программному обеспечению Общесистемное ПО, используемое в составе Модуля СЦ, должно быть зарегистрировано в Едином реестре российских программ для электронных вычислительных машин и баз данных и соответствовать рекомендованным показателям эффективности и соответствующим им значениям индикаторов эффективности перехода подведомственных организаций на использование российского ПО, заданных Приказом Минцифры России от 18.01.2023 № 21 «Об утверждении методических рекомендаций по переходу на использование российского программного обеспечения, в том числе на значимых объектах критической информационной инфраструктуры Российской Федерации, и о реализации мер, направленных на ускоренный переход органов государственной власти и организаций на использование российского программного обеспечения в Российской Федерации». Применяемое в системе программное обеспечение должно соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации, постановления Правительства Российской Федерации от 23 декабря 2024 г. № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц» - Прикладное программное обеспечение должно отвечать следующим требованиям: – совместимость программных продуктов в части используемых технических средств, системного программного обеспечения и общесистемной инфраструктуры в пределах требований к техническому обеспечению, а также их информационная совместимость в пределах требований к информационному обмену; – обеспечение трехуровневой архитектуры с разделением на уровень хранения данных (сервер БД), уровень бизнес-логики (сервер приложений) и уровень представления ( - 4.4.7.1. Требования к инструментам разработки и процессу контроля версий программного обеспечения 4.4.7.1.1. Система контроля версий Для управления исходным кодом должна использоваться система контроля версий кода, развернутая в инфраструктуре Заказчика. 4.4.7.1.2. Правила именования веток Имя ветки должно соответствовать следующему формату: / / Категории веток: ? feature/ — разработка новой функциональности, а также рефакторинг или удаление существующей; ? fix/ — исправление ошибок; ? hotfix/ — срочные исправления, применяемые в обход стандартного процесса разработки; ? test/ — для проведения экспериментов, не влияющих на основную разработку. Идентификатор задачи: после категории указывается ссылка на задачу (issue) в системе контроля версий кода. Описание: добавляется краткое описание решаемой задачи в формате kebab-case (слова разделяются дефисами, например, add-user-auth). Примеры именования веток: ? feature/#123/add-payment-integration; ? fix/#45/correct-calculation-logic; ? hotfix/#67/urgent-database-connection-patch. 4.4.7.1.3. Правила именования коммитов Сообщение коммита должно соответствовать соглашению Conventional Commits и состоять из категории и описания: : ? fix — исправление ошибки. Примеры сообщений коммитов: ? feat: добавление формы регистрации пользователя; ? fix: исправление ошибки валидации email-адреса; ? refactor: оптимизация алгоритма сортировки данных; ? chore: обновление версий в файле dependencies. 4.4.7.1.4. Модель ветвления В процессе разработки используются следующие основные ветви: ? main / master — стабильная ветка, содержит только код, прошедший полное тестирование и развернутый в продуктивных контурах; ? dev — ветка для интеграции завершенных задач, предназначенная для сборки и тестирования в тестовых средах. Попадание кода в main осуществляется только через Merge Request (MR) из dev - – выполнение требований по обеспечению в автоматизированном режиме с Национальной системой противодействия DDoS-атакам (НСПА) Центра мониторинга и управления сетью связи общего пользования ФГУП «ГРЧЦ» в рамках реализации мер по защите ГИС от атак, направленных на отказ в обслуживании; – детализированные требования к составу и содержанию работ по аттестации, а также к их результатам в соответствии с пунктами 13, 15 и 16 требований приказа ФСТЭК России от 29.04.2021 № 77 «Об утверждении Порядка организации и проведения работ по аттестации объектов информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну» - 4.5.5.1. Требования к безопасности исходного кода Процесс разработки исходного кода должен соответствовать требованиям законодательства, нормативным правовым актам Российской Федерации, приказу ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по безопасности значимых объектов критической информационной инфраструктуры Российской Федерации», а также учитывать отраслевые практики безопасной разработки. Подрядчик должен предоставить Заказчику Руководство по безопасной разработке программного обеспечения (далее – Руководство), применяемое при разработке исходного кода Модуля СЦ. Руководство должно содержать: · описание процесса безопасной разработки и ролевой модели, отражающей зоны ответственности сотрудников Подрядчика; · описание процессов моделирования, оценки и формирования мер предотвращения угроз, применяемых Подрядчиком; · описание методик, применяемых Подрядчиком при разработке исходного кода (правила написания кода); · описание методик, периодичности проведения и инструментария статического, динамического, композитного и фаззинг тестирования исходного кода, включающего критерии отбора релизных версий ПО, применяемые Подрядчиком в процессе разработки; · описание механизмов безопасности в процессе сборки и доставки (безопасность образов, безопасность секретов, безопасность окружения и сборочной среды), применяемые Подрядчиком; · утвержденные шаблоны отчетной документации (в том числе акты), в соответствии с которыми Заказчик принимает результаты проверок (артефакты сборочного процесса), проведенных Подрядчиком; · описание процедур отслеживания и исправления обнаруженных ошибок и уязвимостей программного обеспечения; · описание способов и сроков доведения Подрядчиком до Заказчика информации об уязвимостях программного обеспечения, о компенсирующих мерах по защите информации или ограничениях по применению программного обеспечения, способов получения пользователями программного обеспечения его обновлений, проверки их целостности и подлинности - Подрядчик должен обеспечить реализацию и проведение внутренних проверок мер по разработке безопасного ПО, приведенных в Руководстве. Подрядчик должен провести анализ угроз безопасности информации программного обеспечения в соответствии с ГОСТ 58412-2019 «Защита информации. Разработка безопасного программного обеспечения. Угрозы безопасности информации при разработке программного обеспечения». Подрядчик должен провести испытания по выявлению уязвимостей в программном обеспечении Системы: · проведение статического анализа исходного кода программы; · проведение динамического анализа исходного кода программы; · проведение композитного анализа исходного кода и образов программы; · проведение фаззинг-тестирования программы, направленного на выявление в ней уязвимостей. Испытания по выявлению уязвимостей в программном обеспечении Системы должны быть проведены в рамках: · предварительных испытаний; · опытной эксплуатации; · приемочных испытаний - 5. СОСТАВ И СОДЕРЖАНИЕ РАБОТ ПО РАЗВИТИЮ И ТЕХНИЧЕСКОЙ ПОДДЕРЖКЕ МОДУЛЯ СЦ (КАЛЕНДАРНЫЙ ПЛАН) - 5 Разработка программного обеспечения (3 очередь, пп. 4.2.2, 4.2.5 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ; – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 3 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 3 очереди; – Руководство по резервному копированию; – Описание ролевой модели; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 09.10.2026 - - Значение характеристики не может изменяться участником закупки - 6 Опытная эксплуатация (1 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акт о завершении опытной эксплуатации 1 очереди; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке 17.09.2026 Окончание: не позднее 26.10.2026 - 7 Опытная эксплуатация (2 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акт о завершении опытной эксплуатации 2 очереди; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке 26.09.2026 Окончание: не позднее 26.10.2026 - 8 Опытная эксплуатация (3 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Акт о завершении опытной эксплуатации 3 очереди; – Документ о приемке Начало: с 10.10.2026 Окончание: не позднее 26.10.2026 - 9 Приемочные испытания Сопроводительным письмом предоставляются Заказчику: – Программа и методика приёмочных испытаний; – Протокол приемочных испытаний; – Исходные коды и дистрибутивы на электронном носителе (при условии внесения изменений, с учетом доработок по результатам опытной эксплуатации и проведенных испытаний); – Комплект рабочей документации на Модуль СЦ (при условии внесения изменений, с учетом доработок по результатам опытной эксплуатации и проведенных испытаний); – Акт приемки Системы в эксплуатацию; – Акт приемки-передачи исключительных прав на объект; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке; – Документы в соответствии с разделом 4.5.9 ТЗ; – Обеспечение гарантийных обязательств Начало: с 27.10.2026 Окончание: не позднее 10.11.2026 - 10 Услуги по технической поддержке Модуля СЦ (с 11.09.2026 по 15.12.2026) По окончании оказания Услуг сопроводительным письмом предоставляются Заказчику: – Отчет об оказанных Услугах по технической поддержке; – Актуальные на дату окончания оказания Услуг по данному этапу исходные коды прикладного ПО на электронном носителе (в случае внесения изменений); – Инструкция по сборке и развертыванию (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство пользователя (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство администратора (в случае внесения изменений); – Документ о приемке Начало: с 11.09.2026 Окончание: не позднее 15.12.2026 - Работы по развитию Системы (за исключением этапов проведения опытной эксплуатации и услуг по технической поддержке) могут быть выполнены досрочно. При досрочном выполнении работ (этапов работ) Подрядчик в письменной форме уведомляет Заказчика о готовности представить для приемки результаты проведения работ в соответствии с требованиями Контракта. Подрядчик также вправе досрочно приступать к работам в рамках очередного этапа при наличии технической, организационной готовности - при условии получения соответствующего согласования Заказчиком. Сдача-приемка результатов выполненных работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная, техническая документация, а также результаты Работ по каждому этапу предоставляется Заказчику в порядке, предусмотренном Контрактом и настоящим Техническим заданием, до размещения Подрядчиком в Единой информационной системе в сфере закупок документа о приемке. Документ о приемке размещается в ЕИС по каждому этапу в соответствии с условиями Контракта. Согласование документов осуществляется в электронном виде посредством переписки с адресов электронной почты Заказчика и Подрядчика, указанных в контракте. - Сдача-приемка результатов выполненных работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная техническая документация, а также результаты работ предоставляются Заказчику в порядке, предусмотренном Контрактом и ТЗ, до размещения Подрядчиком в ЕИС документа о приемке. Документ о приемке размещается в ЕИС по каждому этапу в соответствии с условиями Контракта. Этапы выполнения работ по развитию Модуля СЦ приведены в Таблице 11. Таблица 11. Этапы выполнения работ по развитию Модуля СЦ. № этапа Наименование этапа Результат (отчетная документация) Срок исполнения этапа - 1 Техническое проектирование Сопроводительным письмом предоставляются Заказчику: · Технический проект, включая следующие документы: – Ведомость технического проекта; – Ведомость машинных носителей информации – Пояснительная записка; – Описание информационного обеспечения системы; – Описание автоматизируемых функций; – Схема функциональной структуры; – Описание организации информационной базы; – Описание программного обеспечения; · Макеты экранных форм компонента «Интерактивная карта»; · Руководство по безопасной разработке программного обеспечения; · Документ о приемке Начало: с даты заключения контракта Окончание: не позднее 31.07.2026 - 2 Услуги по технической поддержке Модуля СЦ (с даты заключения контракта по 10.09.2026) По окончании оказания Услуг сопроводительным письмом предоставляются Заказчику: – Отчет об оказанных Услугах по технической поддержке; – Актуальные на дату окончания оказания Услуг по данному этапу исходные коды прикладного ПО на электронном носителе (в случае внесения изменений); – Инструкция по сборке и развертыванию (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство пользователя (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство администратора (в случае внесения изменений); – Документ о приемке Начало: с даты заключения контракта Окончание: не позднее 10.09.2026 - 3 Разработка программного обеспечения (1 очередь, пп. 4.2.1, 4.2.6 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ; – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 1 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 1 очереди; – Руководство по резервному копированию; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 16.09.2026 - 4 Разработка программного обеспечения (2 очередь, пп. 4.2.3, 4.2.4 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ. – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 2 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 2 очереди; – Руководство по резервному копированию; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 25.09.2026 - 6. ПОРЯДОК РАЗРАБОТКИ МОДУЛЯ СЦ - Проектирование Модуля СЦ должно включать разработку следующих документов: – Ведомость технического проекта; – Ведомость машинных носителей информации – Пояснительная записка; – Описание информационного обеспечения системы; – Описание автоматизируемых функций; – Схема функциональной структуры; – Описание организации информационной базы; – Руководство по безопасной разработке программного обеспечения; – Описание программного обеспечения; – Макеты экранных форм компонента «Интерактивная карта». Структура документов должна соответствовать ГОСТ Р 59795-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов». Разработка Модуля СЦ должна включать в себя: – разработку программного обеспечения в части новых функций Модуля СЦ; – сборка исходного кода, развертывание и настройку доработанного программного обеспечения Модуля СЦ на вычислительных мощностях Заказчика (тестовый контур); – Комплект рабочей документации на Модуль СЦ; – разработку документа «Программа и методика предварительных испытаний»; – разработку документа «Программа и методика приемочных испытаний»; – разработку документа «Программа опытной эксплуатации». Структура документов должна соответствовать ГОСТ Р 59795-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов». В ходе выполнения работ формируется правоустанавливающая, отчетная, рабочая и техническая документация в соответствии с Контрактом и Календарным планом, приведенном в разделе 5. - - Значение характеристики не может изменяться участником закупки - 6.1. Сведения о гарантийном обслуживании Модуля СЦ Под гарантией понимается устранение Подрядчиком своими силами и за свой счет допущенных по его вине недостатков, выявленных после приемки выполненных Работ, как в работе самой Модуля СЦ, так и недостатков в отчетной документации. Если в период гарантийного срока обнаружатся недостатки, то Подрядчик обязан устранить их за свой счет, в сроки, установленные Заказчиком. Гарантийный срок в этом случае продлевается на период устранения недостатков. Срок гарантии: 1 год с даты приемки Заказчиком результатов исполнения Этапа № 9 контракта. Подрядчиком должны быть внесены соответствующие исправления в техническую и рабочую документацию (указанную в пунктах 5 и 6 настоящего ТЗ), связанные с устранением замечаний к работе Модуля СЦ или в случае выявления Заказчиком недостатков в такой документации в период гарантийного срока. Внесение изменений в документацию технического и рабочего проектирования осуществляется в соответствии с ГОСТ 2.503-2023 и ГОСТ Р 2.504-2021. - 7. ПОРЯДОК КОНТРОЛЯ И ПРИЕМКИ РЕЗУЛЬТАТОВ ВЫПОЛНЕНИЯ РАБОТ ПО РАЗВИТИЮ МОДУЛЯ СЦ - Испытания должны быть организованы и проведены в соответствии с ГОСТ Р 59792-2021 «Информационная технология. Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем». Должны быть проведены следующие виды испытаний: – предварительные испытания; – опытная эксплуатация; – приемочные испытания. Указанные виды испытаний проводятся в отношении не функциональных требований и функциональных возможностей, разрабатываемых в соответствии с настоящим ТЗ. Отдельные виды испытаний проводятся поэтапно в сроки, установленные Календарным планом. Предварительные испытания, опытная эксплуатация, приемочные испытания проводятся комиссией, создаваемой организационно-распорядительным документом Заказчика, который должен определять состав комиссии, порядок ее работы. Методы предварительных испытаний и порядок их проведения должны быть определены в документе «Программа и методика предварительных испытаний», который должен быть утвержден Заказчиком до начала предварительных испытаний. По результатам предварительных испытаний оформляется Протокол предварительных испытания и Акт о приемке в опытную эксплуатацию. Порядок проведения и методы испытаний во время опытной эксплуатации должны быть определены в документе «Программа опытной эксплуатации», который должен быть утвержден Заказчиком до начала опытной эксплуатации. Ход и результаты опытной эксплуатации отражаются в документе «Журнал опытной эксплуатации», и учитываются в ходе приемочных испытаний. По результатам опытной эксплуатации подписывается Акт о завершении опытной эксплуатации - - Значение характеристики не может изменяться участником закупки - До момента подключения внешних ИС, Подрядчиком могут быть использованы эмуляторы ИС для прохождения предварительных испытаний, опытной эксплуатации и приемочных испытаний. В рамках опытной эксплуатации должны быть проведены мероприятия по нагрузочному тестированию Модуля СЦ. Документ «Программа и методика приемочных испытаний» должен быть разработан с учетом недостатков, выявленных в ходе опытной эксплуатации, утвержден Заказчиком до начала приемочных испытаний, при этом проверки Модуля СЦ в части не устраненных недостатков, выявленных в процессе опытной эксплуатации, должны быть вынесены в отдельный раздел «Программы и методики приемочных испытаний». В процессе приемочных испытаний должно быть проверено устранение недостатков, полученных в ходе опытной эксплуатации. После завершения устранения всех замечаний, препятствующих приемке Системы в эксплуатацию, перечисленных в Протоколе приемочных испытаний, Подрядчик должен письменно уведомить Заказчика о том, что все замечания устранены, после чего приемочные испытания по решению Заказчика могут быть проведены повторно. Процедура приемочных испытаний проводится до подписания Протокола приемочных испытаний, не содержащего замечаний, препятствующих приемке Системы в эксплуатацию. Приемочные испытания Системы считаются завершенными успешно, если Протокол приемочных испытаний не содержит замечаний, препятствующих приемке Системы в эксплуатацию - 8. ТРЕБОВАНИЯ К СОСТАВУ И СОДЕРЖАНИЮ РАБОТ ПО ПОДГОТОВКЕ МОДУЛЯ СЦ К ВВОДУ В ЭКСПЛУАТАЦИЮ - Протоколы предварительных и приемочных испытаний должны содержать вывод о соответствии Модуля СЦ предъявляемым требованиям, а также сроки устранения замечаний и реализации рекомендаций, сформулированных комиссией в ходе предварительных и приемочных испытаний. Условием для передачи Модуля СЦ в промышленную эксплуатацию является устранение всех замечаний. Документация на Модуль СЦ и ее части (техническая и рабочая) должна содержать исчерпывающее описание принятых проектных решений в объеме, достаточном для ее дальнейшего развития и эксплуатации. Техническая и рабочая документация должна содержать описание разработанных результатов работ, в том числе программ для ЭВМ, прикладных программных интерфейсов, алгоритмов и протоколов информационного взаимодействия, технических требований, спецификаций и форматов обмена данными для взаимодействия с другими информационными системами, в объеме, достаточном для их установки, настройки, эксплуатации и развития в дальнейшем без привлечения Подрядчика. Исходные коды передаются в виде и составе, позволяющем провести: – сборку (компиляцию) Модуля СЦ в контролируемой Заказчиком среде; – установку полученной Модуля СЦ на специально подготовленную контролируемую Заказчиком инфраструктуру; – проверку функциональных возможностей Модуля СЦ; – оформление Модуля СЦ в качестве объекта национального фонда алгоритмов и программ для электронных вычислительных машин - - Значение характеристики не может изменяться участником закупки - 8.1. Требования, предъявляемые в соответствии с Приказом Минцифры России от 17.12.2020 № 715 «Об утверждении типовых условий контрактов на выполнение работ по созданию и (или) развитию (модернизации) государственных (муниципальных) и (или) иных информационных систем» Передача исходных кодов, разработанных в ходе выполнения работ, программ для электронных вычислительных машин (далее – программа для ЭВМ) должна сопровождаться передачей всех необходимых для сборки и запуска программы для ЭВМ библиотек зависимостей, программных сценариев (скриптов) для проведения установки (развертывания) программы для ЭВМ. Подрядчик в процессе сдачи-приемки работ по Контракту должен провести демонстрацию процесса и установки (развертывания) разработанных программ для ЭВМ. Документация на Модуль СЦ должна содержать описание принятых проектных решений в объеме, достаточном для ее дальнейшего развития и эксплуатации - По результатам проведения приемочных испытаний оформляется Протокол приемочных испытаний и Акт приемки в эксплуатацию. В случае, если взаимодействие с внешними системами не может быть проверено на средах постоянной эксплуатации взаимодействующих систем (по причине неготовности со стороны внешней системы или иным причинам), функции взаимодействия, разработанные в соответствии с требованиями ТЗ, должны быть проверены на тестовых данных с использованием программ-имитаторов взаимодействия. По результатам выполнения этапа приемочных испытаний должны быть подготовлены материалы для регистрации доработанной версии Модуля СЦ (объекта учета) в НФАП в соответствии с требованиями постановления Правительства Российской Федерации от 30 января 2013?г. №?62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин» (с изменениями и дополнениями) в части обязательности размещения результатов работ в национальном фонде алгоритмов и программ для электронных вычислительных машин. Сдача-приемка результатов выполнения Работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная, техническая документация, а также программное обеспечение предоставляется Заказчику в порядке, предусмотренном Контрактом и ТЗ до размещения Подрядчиком в Единой информационной системе в сфере закупок документа о приемке. Результаты проведения опытной эксплуатации, предварительных и приемочных испытаний должны быть зафиксированы в соответствующих протоколах и актах. Выявленные отклонения от настоящего ТЗ, оформляются как недостатки Модуля СЦ - 9. ТРЕБОВАНИЯ К ДОКУМЕНТИРОВАНИЮ - 9.1. Общие требования Документация на Модуль СЦ должна быть разработана в составе, указанном в разделах 5-8 данного ТЗ, и должна удовлетворять требованиям комплекса стандартов и руководящих документов на автоматизированные системы: – ГОСТ Р 2.105-2019 в части оформления текстовых документов; – ГОСТ 34.201-2020 в части наименования и обозначения документов. Документация на Модуль СЦ должны оформляться на листах формата А4. Допускается для размещения рисунков и таблиц использование листов формата А3 с подшивкой по короткой стороне листа. Документы объемом более 25 (двадцати пяти) листов должны содержать информационную часть, состоящую из аннотации и содержания. Исходные коды должны быть представлены в 1 (одном) экземпляре на электронном носителе, отчетные материалы должны быть представлены в 2 (двух) экземплярах на бумажном носителе (по одному экземпляру для Заказчика и Подрядчика) и в 1 (одном) экземпляре на электронном носителе в формате документов DOCX и PDF. При разработке документов на Модуль СЦ допускается отклонение от требований комплекса стандартов, описанных выше. Документам на Модуль СЦ должны в обязательном порядке присваиваться уникальные децимальные номера в соответствии с порядком, установленном в ГОСТ 34.201-2020. Документ «Программа и методика предварительных испытаний» должен включать приложения с формой протокола предварительных испытаний и формой акта приемки в опытную эксплуатацию. Документ «Программа опытной эксплуатации» должен включать приложение с формой журнала опытной эксплуатации. Документ «Программа и методика приемочных испытаний» должен включать приложения с формой протокола приемочных испытаний и формой акта приемки в эксплуатацию - - Значение характеристики не может изменяться участником закупки - 10. ИСТОЧНИКИ РАЗРАБОТКИ - 10.1. Список литературы Специальная литература для разработки ТЗ не использовалась. 10.2. Нормативно-методические документы Список используемых нормативно-методических документов представлен в разделе 1.6 технического задания. ? Приложение А Эскизы визуального оформления компонента «Интерактивная карта» - - Значение характеристики не может изменяться участником закупки - Приложение Б Параметры оказания услуг - По устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности 1 Критический не более 30 минут не более 24 часов - критические уязвимости, влияющие на возможную полную недоступность ППО, ключевых функций Системы, ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО без возможности восстановления работоспособности Системы. - Критический уровень CVSS > 8.0 2 Высокий не более 1 часа не более 84 часов - критические уязвимости, влияющие на ошибки и сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО. - Высокий уровень CVSS 5.0 - 8.0 3 Средний не более 4 часов не более 120 часов - уязвимости, влияющие на невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым - Средний уровень CVSS 2.0 - 4.9 4 Низкий не более 8 часов не более 160 часов - уязвимости, влияющие на отклонение в работе ППО, не влияющее на корректную работу функций; - другие сбои и ошибки, затрагивающие основные функции ППО - Низкий уровень CVSS < 2.0 - - Значение характеристики не может изменяться участником закупки - Взаимодействие Заказчика и Подрядчика в части регистрации и контроля времени реагирования и решения обращения (заявки) осуществляется через СРО. Заказчик предоставляет Подрядчику доступ к СРО после заключения Контракта. Поступившие от разных пользователей заявки по поводу однотипных инцидентов или имеющие общую причину должны объединяться в одну заявку. Срок выполнения включает время диагностики инцидента, в ходе которого определяется причина инцидента (проблемы) и способ его устранения. Подрядчик должен обеспечить функционирование Модуля СЦ в соответствии с требованиями и параметрами, указанными в настоящем ТЗ и Регламенте оказании услуг. Основные параметры быстродействия типовых операций в Модуле СЦ указаны в таблице ниже (таблица Б.2.2). Таблица Б.2.2 - Параметры быстродействия Модуля СЦ № п/п Наименование параметра Значение (секунд) 1 Среднее время получения сообщения из очереди сообщений 10 2 Среднее время получения ответа от Системы 5 3 Среднее время открытия карточки реестра 5 - Б.1. Базовые параметры оказания Услуг Базовые параметры оказания Услуг приведены ниже: – режимы оказания Услуг (таблица Б.1.1); – сроки предоставления отчетности (таблица Б.1.2). Таблица Б.1.1 - Режимы оказания Услуг № п/п Параметр Значение - 1 Режим работы Системы Круглосуточно (24х7) 2 Режим доступности информационно-консультационной поддержки пользователей Системы 2.1 Прием и регистрация обращений (заявок) в СРО Регистрация обращений (заявок) производится круглосуточно в режиме 24х7, без праздников и выходных дней. Обработка заявок первой линией поддержки осуществляется в рабочие дни с 9 до 18 часов 2.2 Консультирование сотрудников Заказчика и пользователей Системы в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 3 Режим доступности по решению инцидентов, связанных с работой ППО: 3.1 - приоритет «Критический» Круглосуточно (24х7) 3.2 - приоритет «Высокий» Круглосуточно (24х7) 3.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 3.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4 Режим доступности услуг по адаптации, конфигурации и коррекционному сопровождению Системы 4.1 - приоритет «Критический» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.2 - приоритет «Высокий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 5 Режим доступности по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности 5.1 - приоритет «Критический» Круглосуточно (24х7) 5.2 - приоритет «Высокий» Круглосуточно (24х7) 5.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 5.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) - Таблица Б.1.2. Сроки предоставления отчетности, с момента получения запроса № п/п Параметр Значение 1 Предоставление отчета об оказанных услугах за произвольный период 10 рабочих дней 2 Предоставление подробной информации по инциденту с приоритетом «Критический» 16 рабочих часов 3 Предоставление актуализированной документации 10 рабочих дней - Б.2. Приоритеты и регламентные сроки решения обращений (заявок) В зависимости от уровня сбоя в работе Системы обращению (заявке) присваивается один из следующих приоритетов, а также в зависимости от приоритета обращения (заявки) устанавливаются следующие контрольные сроки решения в соответствии с таблицей ниже (Таблица Б.2.1). Таблица Б.2.1 – Приоритеты и регламентные сроки решения обращений (заявок) № п/п Приоритет Максимальное время реагирования Время решения (срок выполнения) Описание приоритета По информационно-консультационной поддержке сотрудников Заказчика и пользователей Системы 1 - не более 1 часа не более 10 часов - По решению инцидентов, связанных с работой ППО: 1 Критический не более 30 минут не более 4 часов - полная недоступность ППО; - недоступность ключевых функций - ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО; - невозможность информационного обмена с ППО для ИС более 4 часов 2 Высокий не более 1 часа не более 8 часов - ошибки/сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; - снижение быстродействия СПО (время отклика ППО на операции превышает 30 секунд); - недоступность управления правами и ролями пользователей 3 Средний не более 4 часов не более 24 часов - невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым -недоступность функции формирования отчетов 4 Низкий не более 8 часов не более 40 часов - отклонение в работе ППО, не влияющее на корректную работу функций; - другие сбои и ошибки, затрагивающие основные функции ППО - По адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) 1 Критический не более 40 минут не более 8 часов - изменения, необходимые при проведении аварийно-восстановительных работ для возобновления работоспособности Системы; - изменения, связанные с критичными ошибками, блокирующими возможность оказания государственных услуг и/или чтение и внесение данных в Систему 2 Высокий не более 1 часа не более 40 часов - изменения, относящиеся к обеспечению работоспособности основной функциональности Системы, устраняют выявленные дефекты в работе Системы, оказывающие существенное влияние на работу пользователей в Системе; - изменения, затрагивающие три и более подсистемы/модуля Системы для адаптации 3 Средний не более 4 часов не более 72 часов - изменения, связанные с развитием/улучшением/оптимизацией Системы и выводом новой функциональности в штатном режиме для одного-двух модулей/подсистем; - изменения, связанные с развитием интеграционных механизмов Системы, например обновление существующих и/или реализация новых видов сведений СМЭВ, обновление существующих и/или реализация новых API, адаптация и/или изменение механизмов импорта и экспорта данных Системы и т.д. 4 Низкий не более 8 часов не более 160 часов - изменения, связанные с ошибками/корректировкой/изменением в отображении информации в пользовательском графическом интерфейсе Системы (графика, текст, органы управления, элементы интерфейса) - Приложение В Регламент оказания услуг - Приложение Д Форма Протокола проверки результатов организационно-штатных и подготовительных мероприятий (шаблон) Протокол проверки результатов организационно-штатных и подготовительных мероприятий Настоящий Протокол содержит результаты проверки организационно-штатных и подготовительных мероприятий, проведенных Исполнителем (Таблица Д.1). Таблица Д.1. Протокол проверки результатов № Мероприятия Подготовительного этапа Результат проверки 1. Определить и направить Заказчику документ «Ответственные за взаимодействия в рамках выполнения работ по техническому сопровождению Системы со стороны Исполнителя». Документ содержит контактную информацию (ФИО, должность, адрес электронной рабочей почты, номер телефона) не менее чем о 2 лицах, ответственных за оказание услуг со стороны Подрядчика Выполнено/Не выполнено 2. Обеспечить подключение специалистов Подрядчика к Системе Выполнено/Не выполнено 3. Обеспечить подключение специалистов Подрядчика к СРО Выполнено/Не выполнено Заказчик Подрядчик /Должность/ /Должность/ ____________________ /Ф.И.О/ ___________________ /Ф.И.О/ М.П. М.П. «_____»_______________________202_г. «_____»_______________________202_г - - Значение характеристики не может изменяться участником закупки - Термины и сокращения В настоящем регламенте используются следующие термины и сокращения на русском и английском языках: Термины/сокращения Полное наименование/описание БЗ (База знаний) База данных Системы регистрации обращений (заявок), созданная для сбора, хранения и поиска способов решения известных проблем в рамках Системы Жизненный цикл обращения (заявки) Совокупность статусов, по которым проходит обращение (заявка), и правила перехода обращения (заявки) из одного статуса в другой Заказчик ФГБУ «СИЦ Минтранса России» – Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» ЗНИ Запрос на изменение – тип заявки, предполагающий внесение изменений в прикладное программное обеспечение Системы ЗНО Запрос на обслуживание – тип заявки, предполагающий работы по предоставлению консультации, предоставление доступа к Системе или стандартизированные типовые изменения конфигураций Системы Инцидент Тип заявки, классифицируемый как нештатное событие в работе компонентов функциональных задач Системы, которое привело или может привести к нарушению или снижению качества функционирования Системы ИС Информационная система Исполнитель Организация, которая определяется по результатам конкурсных процедур Классификация Анализ и заполнение классификационных полей справочными значениями, определяющими последовательность действий и этапов жизненного цикла заявки, а также порядок рассмотрения заявок Консультация Разъяснения по алгоритму работы, требуемых настроек прикладного программного обеспечения и технологии обработки данных при работе с Системой, предоставление информации Маршрутизация Определение процесса движения обращения (заявки) в Системе управления заявками между уровнями технической поддержки и организационными структурами на уровнях поддержки путем назначения обращения (заявки) в соответствии с его классификацией и выставленным приоритетом - Обращение (заявка) Устное или письменное обращение пользователя АСУ ТК с вопросом, касающимся работоспособности АСУ ТК, по одному из определённых каналов связи: электронная почта, Система регистрации обращений (заявок) Пользователь Инициатор обращения (заявки) или пользователь Системы ППО Прикладное программное обеспечение Предмет обращения Справочник, классифицирующий типовые запросы в Системе регистрации обращений (заявок), характерные для Системы, выбранное значение определяет маршрутизацию обращения (заявки) (группу ответственных сотрудников) Приоритизация Значение, определяющее время, очередность решения обращений (заявок), ресурсы, привлекаемые для решения обращений (заявок), . Приоритет устанавливается в соответствии с масштабом выявленной проблемы, которая привела или может привести к нарушению или снижению качества функционирования Системы Релиз Выпуск версии прикладного программного обеспечения Системы, от разработки до тестирования и планового обновления Системы на продуктивной среде для установки изменений, связанных с развитием/улучшением/оптимизацией Системы Система, АСУ ТК, Информационно-аналитическая система регулирования на транспорте Информационно-аналитическая система, предназначенная для автоматизации и информационно-аналитического обеспечения процессов управления развитием транспортного комплекса Российской Федерации, обеспечения публичности деятельности органов государственного управления транспортным комплексом, а также обеспечения процессов оказания государственных услуг в электронном виде в сфере транспорта СМЭВ Система межведомственного электронного взаимодействия СПО Системное программное обеспечение СРО Система регистрации обращений (заявок) Статус обращения (заявки) Текущее состояние обращения (заявки) в жизненном цикле процесса оказания технической поддержки Системы СУБД Система управления базами данных - Уровень технической поддержки Организационно-структурная часть технической поддержки, имеющая определённые организационно-нормативными документами зоны ответственности, обязанности, а также временные нормативы, в течение которых эти обязательства должны выполняться либо эскалироваться на следующий уровень технической поддержки Услуги Услуги по технической поддержке Информационно-аналитической системы регулирования на транспорте АСУ ТК ФИО Фамилия, имя, отчество Эскалация Процедура повышения внимания к обращению (заявке) путем повышения его приоритета и/или передачи на следующий уровень технической поддержки, а также привлечение ролей, которые могут принимать решения без передачи на следующий уровень технической поддержки API Англ. Application Programming Interface — программный интерфейс приложения, интерфейс прикладного программирования — описание способов (набор классов, процедур, функций, структур или констант), которыми одна компьютерная программа может взаимодействовать с другой программой - CVSS Англ. Common Vulnerability Scoring System - открытый стандарт, используемый для расчета количественных оценок уязвимости в безопасности компьютерной системы, обычно с целью понять приоритет ее исправления. В современном инструментарии информационной безопасности используется версия 3.0 и выше с дополнительными метриками к базовым оценкам ID Англ. Identifier – идентификатор, уникальный признак объекта, позволяющий отличать его от других объектов, то есть, идентифицировать SLA Англ. Service Level Agreement - утвержденные условия по обработке обращения (заявки) с установленными метриками времени, которые определяют пороговые значения для эскалации в зависимости от статуса обращения (заявки) (например, время реакции – время от регистрации до осуществления первичной обработки, время решения – время от регистрации обращения (заявки) до его решения и т.д.) SQL Англ. Structured Query Language — «язык структурированных запросов», — декларативный язык программирования, применяемый для создания, модификации и управления данными в реляционной базе данных, управляемой соответствующей СУБД - 1 Общие сведения 1.1 Полное наименование Услуг Оказание услуг по технической поддержке Модуля СЦ АСУ ТК в 2026 году. 1.2 Предмет Регламента оказания услуг Требования Технического задания - 2 Общие положения 2.1 Цель и задачи оказания услуг Целью технической поддержки Системы является обеспечение ее стабильного и безопасного функционирования и эксплуатации, предупреждение, выявление и устранение сбоев в работе Системы и минимизация их неблагоприятного влияния. Для достижения поставленной цели требуется решение следующих задач: 1. Обеспечение информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы. 2. Поддержание параметров функционирования ППО Системы, удовлетворяющих требованиям производственных процессов, включая их непрерывность. 3. Обеспечение бесперебойного функционирования ППО и своевременное устранение сбоев и аварийных ситуаций в Системе. 4. Своевременное устранение уязвимостей при выявлении таковых, в соответствии с требованиями к обеспечению информационной безопасности. 5. Адаптация, конфигурирование, коррекция программного обеспечения в соответствии с изменениями нормативно-правовой базы и запросами уполномоченных сотрудников органов государственной власти, включая выполнение процедур тестирования и участие в обновлениях ППО на стендах Заказчика. 6. Обеспечение сохранения работоспособности ППО в изменяемой среде эксплуатации. 7. Ведение документации по настоящему контракту и инициирование актуализации документации на Систему по результатам обработки запросов Заказчика и внесения соответствующих изменений в ППО - 3.4 Порядок регистрации и сопровождения Заявок Порядок регистрации и сопровождения обращений (заявок) в рамках оказываемых услуг по технической поддержке Системы зависит от типа обращения (заявки): 1. Услуга по решению инцидентов, связанных с работой ППО – тип обращения (заявки) «Инцидент». 2. Услуга по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности – тип обращения (заявки) «Инцидент». 3. Услуга информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы – тип обращения (заявки) «Запрос на обслуживание» (в том числе, консультационный запрос). 4. Услуга адаптационного, конфигурационного и коррекционного сопровождения Системы (в рамках действующих программных модулей и функциональностей) – тип обращения (заявки) «Запрос на изменение». В случае недоступности СРО взаимодействие и информирование Исполнителем о ходе оказания услуги по обращению (заявке), изменению статусов обращений (заявок) осуществляется по согласованию с Заказчиком в соответствии с матрицей взаимодействия, представленной в Приложении 1 к настоящему Регламенту. - 3.4.1 Инцидент На рисунке 2 представлена функциональная схема регистрации и сопровождения обращений (заявок) типа «Инцидент». Рисунок 2 - Функциональная схема регистрации и сопровождения обращений (заявок) типа «Инцидент» 3.4.2 Запрос на обслуживание На рисунке 3 представлена функциональная схема регистрации и сопровождения обращения (заявки) типа «ЗНО». Рисунок 3 - Функциональная схема регистрации и сопровождения обращения (заявки) типа «ЗНО» 3.4.3 Запрос на изменение На рисунке 4 представлена функциональная схема регистрации и сопровождения обращений (заявок) типа «ЗНИ». Рисунок 4 - Функциональная схема регистрации и сопровождения обращений (заявок) типа «ЗНИ» - 3.5 Порядок классификации и приоритизации обращений (заявок) Классификация является начальной стадией процесса оказания технической поддержки, необходимой для идентификации обращения (заявки) и определения соответствующих действий для его обработки. Для проведения первичной классификации необходимо получить от пользователя и зафиксировать в описании обращения (заявки) подробные сведения о сути запроса, в том числе, для Инцидентов зафиксировать сценарий воспроизведения обнаруженной ошибки. Для проведения вторичной классификации необходимо провести анализ и диагностику для определения корневой причины и затронутой Инцидентом функциональной области (инфраструктура, сеть, ППО). В процессе классификации осуществляется первичная диагностика и оценка проблемы, описанной пользователем Системы в обращении (заявке), в части функционирования и/или удобства использования Системы. Корректная классификация позволяет увеличить скорость обработки обращения (заявки) и решения описанной в обращении (заявке) проблемы при минимальном привлечении ресурсов, в частности, за счет использования известных решений для типовых обращений (заявок), которые должны описываться в БЗ СРО. Классификация позволяет произвести первоначальное назначение обращения (заявки) на ответственного сотрудника и выставить приоритет с учетом приоритизации. Приоритизация применяется для определения критичности описанной в обращении (заявке) проблемы для функционирования ППО Системы. Приоритет рассмотрения обращения (заявки) определяется в процессе ее классификации на основании ряда параметров, вводимых при заполнении обращения (заявки). Приоритизация используется для того, чтобы при одновременном наличии нескольких обращений (заявок) в первую очередь рассматривалась обращения (заявки) с наивысшим приоритетом и не позднее установленных для данного приоритета сроков - 4.3. Форма обращения (заявки) на оказание услуг по адаптационному конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) При подаче обращения (заявки) типа «ЗНИ» в СРО указывается (Таблица 7): Таблица 7 – Описание атрибутов формы обращения (заявки) на оказание услуг по адаптационному, конфигурационному и коррекционному сопровождению Системы Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 10) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 9) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 10) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 10) Категория обращения (заявки): запрос на изменение Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 7) Приоритет изменения Время, очередность решения обращения (заявки), ресурсы, привлекаемые для решения обращения (заявки), порядок/процедура действий при решении обращения (заявки) – поле СРО «Приоритет» (см. рисунок 7) Тип изменения Справочник, классифицирующий типовые запросы характерные для Системы – поле СРО «Предмет обращения» (см. рисунок 7) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 7) Текст запроса на оказание услуги по адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 7) - На рисунке 7 приведена форма обращения (заявки) типа «ЗНИ» в СРО. Рисунок 7 - Форма обращения (заявки) типа «ЗНИ» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуг по адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей), заполненную в свободной форме - 4.4. Форма обращения (заявки) на оказание услуги по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности При подаче обращения (заявки) типа «Инцидент» в СРО указывается (Таблица 8): Таблица 8 – Описание атрибутов формы обращения (заявки) на оказание услуг по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности - 2.2 Общее описание процесса оказания сопровождения (технической поддержки) Системы Процесс оказания технической поддержки Системы включает: 1. Поступление обращений (заявок) от пользователей и их регистрацию. 2. Сопровождение обращений (заявок) в соответствии с их классификацией и приоритизацией, в том числе, с их последующей эскалацией. 3. Определение ролей и регламент их взаимодействия при осуществлении деятельности по процессу. 4. Решение обращений (заявок) в установленные настоящим Регламентом сроки. 5. Взаимодействие между 1-м, 2-м и 3-м уровнями технической поддержки, в том числе, с формированием заданий для сопровождения Системы. 6. Контроль качества выполняемых Исполнителем работ, состоящий из проверки сценария, приводящего к ошибке, зафиксированной в Инциденте, и/или к ошибке воспроизведения, а также тестирование внесенных изменений в рамках ЗНИ. 7. Обеспечение мониторинга и проведение анализа процесса обработки поступающих в техническую поддержку обращений (заявок). Техническая поддержка реализуется путем проведения ответственными сотрудниками соответствующей информационно-консультационной деятельности в соответствии с определенными ролями, а также выполнения Исполнителем конкретных действий по своевременному выявлению причин сбоев и аварийных ситуаций и их устранению, а также по адаптации, конфигурированию, корректировке Системы, включая выполнение процедур тестирования и участия в обновлениях Системы. Все роли подразделяются на уровни поддержки, взаимодействующие между собой в соответствии с блок-схемой процесса технической поддержки. Общая схема процесса рассмотрения обращений (заявок) в соответствии с видами технической поддержки представлена на рисунке 1. . Рисунок 1 - Общая схема процесса рассмотрения обращений (заявок) в соответствии с видами технической поддержки - 2.3 Каналы связи Должна быть предусмотрена омниканальность в части приема обращений (заявок). Получение обращений (заявок) технической поддержкой происходит по следующим каналам связи: – СРО; – электронная почта; – телефонная линия. Исполнитель обеспечивает прием обращений (заявок) от Заказчика и предоставляет информацию в рамках оказания услуг по техническому сопровождению Системы, руководствуясь матрицей взаимодействия, приведенной в Приложении 1 к настоящему Регламенту - 3 Порядок оказания Услуг 3.1 Типы обращений (заявок) Обращения и заявки Заказчика классифицируются в соответствии с приоритетами и регламентными сроками, указанными в Приложении 2 к настоящему Регламенту. Регистрация обращений и заявок предусматривает создание новой записи в СРО с присвоением поступившему обращению или заявке (новой записи) уникального идентификатора. Запись в СРО должна содержать вопрос или проблему, которую требуется решить или оказать консультацию. Если обращение или заявка автоматически зарегистрированы в СРО при отправке представителем Заказчика, Исполнитель проверяет корректность указанного типа обращения (заявки) и может обратиться к Заказчику с просьбой корректировки, предоставив обоснования в соответствии с настоящей классификацией (Таблица 1) - Изменение приоритета уже зарегистрированного обращения (заявки) используется в случае появления новых обстоятельств, которые ведут к изменению влияния и/или срочности существующего обращения (заявки). При регистрации обращения (заявки) необходимо провести его приоритизацию. В процессе управления обращениями (заявками) каждому обращению (заявке) присваивается приоритет, принимающий одно из значений: Низкий, Средний, Высокий или Критический. В соответствии с приоритетом определяется время, очередность устранения, , ресурсы, привлекаемые для работ по обращению (заявке), а также может определяться порядок/процедура действий при работе с обращением (заявкой). Заказчиком в зависимости от уровня сбоя в работе Системы обращению (заявке) присваивается приоритет с указанием максимального времени реакции и решения в соответствии с требованиями, указанными в Приложении 2 к настоящему Регламенту - 4 Формы обращений (заявок) на оказание услуг по технической поддержке Системы, заполняемые в СРО 4.1. Форма обращения (заявки) на оказание услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы При подаче обращения (заявки) типа «ЗНО» в СРО указывается (Таблица 5): Таблица 5 – Описание атрибутов формы обращения (заявки) на оказание услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 5) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 5) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 5) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 5) Категория обращения: информационно-консультационная поддержка Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 5) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 5) Текст запроса на оказание услуги по информационно-консультационной поддержке сотрудников Заказчика Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 5) - На рисунке 5 приведена форма обращения (заявки) типа «ЗНО» в СРО. Рисунок 5 - Форма обращения (заявки) типа «ЗНО» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы, заполненную в свободной форме. - Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 8) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 8) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 8) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 8) Категория обращения (заявки): инцидент Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 8) Приоритет Время, очередность решения обращения (заявки), ресурсы, привлекаемые для решения обращения (заявки), порядок/процедура действий при решении обращения (заявки) – поле СРО «Приоритет» (см. рисунок 8) Тип изменения Справочник, классифицирующий типовые запросы характерные для Системы – поле СРО «Предмет обращения» (см. рисунок 8) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 8) Текст запроса на оказание услуги по обновлению или удалению уязвимых компонентов (библиотек) ППО в соответствии с требованиями к обеспечению информационной безопасности Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 8) - На рисунке 8 приведена форма обращения (заявки) типа «Инцидент» в СРО. Рисунок 8 - Форма обращения (заявки) типа «Инцидент» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуги по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности, заполненную в свободной форме - Приложение 1 к Регламенту Матрица ответственных за взаимодействия в рамках выполнения работ по техническому сопровождению Системы Таблица 1 – Ответственные за взаимодействия в рамках выполнения работ по техническому сопровождению Системы со стороны Исполнителя ФИО Должность Адрес электронной почты Телефон — — — Общий контакт - Приложение 2 к Регламенту Приоритеты и регламентные сроки решения обращений (заявок) Приоритеты и регламентные сроки решения обращений (заявок) приведены в таблице 1. Таблица 1 – Приоритеты и регламентные сроки решения обращений (заявок) № п/п Приоритет Максимальное время реагирования Время решения (срок выполнения) Описание приоритета - По информационно-консультационной поддержке сотрудников Заказчика и пользователей Системы 1 – не более 1 часа не более 10 часов – - Таблица 1 - Типы обращений (заявок) Тип обращения (заявки) Описание Запрос на обслуживание Подготовка SQL запроса к СУБД для решения прикладной задачи и д р. – запрос на любое действие, не являющееся запросом информации и несовершенный на основе происшествия, прямо или косвенно влияющего на работу Системы Консультация (входит в тип обращения (заявки) «Запрос на обслуживание») «Где взять / куда обратиться...?», «Как сделать / выполнить…», «Как это работает…?» - запрос, имеющий своей целью получение информационной поддержки Инцидент Разбор ошибок/сбоев и подготовка материалов (корректировочных релизов, инструкций) для Заказчика для устранения ошибок/сбоев, которые приводят к частичному и полному нарушению работоспособности всех или отдельных функций ППО. Подготовка изменения и материалов, необходимых для проведения аварийно-восстановительных работ для возобновления работоспособности Системы. ЗНИ Подготовка изменений, связанных с изменением, улучшением/оптимизацией Системы и выводом новой модифицированной функциональности в штатном режиме. Подготовка изменений, связанных с модификацией существующих и/или реализация новых интеграционных механизмов для получения/обработки данных внешних систем. Подготовка изменений графического интерфейса по требованиям Заказчика - 3.2 Участники технической поддержки, осуществляющие сопровождение обращений (заявок) Техническая поддержка Системы должна быть организована на трех уровнях: 1. Первый и второй уровни технической поддержки организуется Заказчиком. 2. Третий уровень технической поддержки организуется Исполнителем. Зона ответственности каждого уровня технической поддержки указана в Таблице 2. Таблица 2 - Зона ответственности каждого уровня технической поддержки Участники технической поддержки Описание - Первый уровень технической поддержки (далее – 1-й уровень) Группа ответственных сотрудников 1-го уровня Заказчика, осуществляющая прием и первичную обработку обращений (заявок) (описание предмета обращения, первичная классификация и приоритизация, определение назначения, маршрутизация обращений (заявок) по назначению), руководствуется в своей работе настоящим Регламентом и БЗ, наполняемой 2-м уровнем поддержки, самостоятельно решает часть обращений (заявок), связанных с недостаточной квалификацией пользователей или настройками в рамках своей компетенции. В случае невозможности решения обращений (заявок) на 1-ом уровне ответственный сотрудник передает ее на 2-й уровень - Второй уровень технической поддержки (далее – 2-й уровень) Группа ответственных сотрудников 2-го уровня Заказчика по установленным компетенциям (информационная безопасность, сопровождение и эксплуатация информационно-аналитических систем, развитие информационно-аналитических систем, техническая поддержка информационно-аналитических систем) отвечает за поддержание работоспособности Системы, обработку обращений (заявок) и их решение в регламентные сроки в соответствии с установленными приоритетами. Осуществляет информационно-консультационную поддержку пользователей Системы в рамках своей компетенции. Оказывает экспертную помощь ответственным сотрудникам 1-го уровня в части формирования БЗ, содержащей ответы на часто задаваемые вопросы пользователей, с целью передачи знаний, навыков и инструментария на 1-й уровень для ускорения решения обращений (заявок). В случае невозможности решения обращения (заявки) на 2-ом уровне ответственный сотрудник передает его на 3-й уровень. При выявлении необходимости изменений в ППО Системы инициирует формирование обращения (заявки) и направляет его на группу ответственных сотрудников 3-го уровня по соответствующему классификатору (ЗНО, ЗНИ, и т.д.) - 4.2. Форма обращения (заявки) на оказание услуги по решению инцидентов, связанных с работой ППО При подаче обращения (заявки) типа «Инцидент» в СРО указывается (Таблица 6): Таблица 6 – Описание атрибутов формы обращения (заявки) на оказание услуги по решению инцидентов, связанных с работой ППО Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 6) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 6) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 6,) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 6) Категория обращения (заявки): инцидент Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 6) Приоритет изменения Время - одно из значений: Низкий, Средний, Высокий или Критический. Определяет, очередность решения обращения (заявки), ресурсы, привлекаемые для решения обращения (заявки), порядок/процедура действий при решении обращения (заявки) – поле СРО «Приоритет» (см. рисунок 6,) - Тип изменения Справочник, классифицирующий типовые запросы характерные для Системы – поле СРО «Предмет обращения» (см. рисунок 6) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 6) Полное описание инцидента, включая скриншоты и описание шагов, приведших к неисправности Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 6) Однократность/неоднократность Круг пользователей или компьютеров, затронутых данным инцидентом Действия, предпринятые для самостоятельного решения инцидента (при наличии) Версии используемого программного обеспечения на клиентской рабочей станции, где воспроизводится ошибка (операционная система, прикладное программное обеспечение) Дополнительная информация - На рисунке 6 приведена форма обращения (заявки) типа «Инцидент» в СРО. Рисунок 6 - Форма обращения (заявки) типа «Инцидент» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуги по решению инцидентов, связанных с работой ППО, заполненную в свободной форме - По решению инцидентов, связанных с работой ППО 1 Критический не более 30 минут не более 4 часов – полная недоступность ППО; – недоступность ключевых функций; – ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО; – невозможность информационного обмена с ППО для ИС более 4 часов 2 Высокий не более 1 часа не более 8 часов – ошибки/сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; – снижение быстродействия СПО (время отклика ППО на операции превышает 30 секунд); – невозможность управления правами и ролями пользователей 3 Средний не более 4 часов не более 24 часов – невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым недоступность функции формирования отчетов 4 Низкий не более 8 часов не более 40 часов – отклонение в работе ППО, не влияющее на корректную работу функций; – другие сбои и ошибки, затрагивающие основные функции ППО - По адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) 1 Критический не более 40 минут не более 8 часов – изменения необходимые при проведении аварийно-восстановительных работ для возобновления работоспособности Системы; – изменения, связанные с критичными ошибками, блокирующими возможность оказания государственных услуг и/или чтение и внесение данных в Систему 2 Высокий не более 1 часа не более 40 часов – изменения относящиеся к обеспечению работоспособности основной функциональности Системы, устраняют выявленные дефекты в работе Системы, оказывающие существенное влияние на процесс оказания государственных услуг и работу пользователей в Системе; – изменения, затрагивающие три и более подсистемы/модуля Системы для адаптации 3 Средний не более 4 часов не более 72 часов – изменения, связанные с развитием/улучшением/оптимизацией Системы и выводом новой функциональности в штатном режиме для одного-двух модулей/подсистем; – изменения, связанные с развитием интеграционных механизмов Системы, например, обновление существующих и/или реализация новых видов сведений СМЭВ, обновление существующих и/или реализация новых API, адаптация и/или изменение механизмов импорта и экспорта данных Системы и т.д. 4 Низкий не более 8 часов не более 160 часов – изменения, связанные с ошибками/ корректировкой/изменение в отображении информации в пользовательском графическом интерфейсе Системы (графика, текст, органы управления, элементы интерфейса) - По устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности 1 Критический не более 30 минут не более 24 часов – критические уязвимости, влияющие на возможную полную недоступность ППО, ключевых функций Системы, ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО без возможности восстановления работоспособности Системы; – Критический уровень CVSS > 8.0 2 Высокий не более 1 часа не более 84 часов – критические уязвимости, влияющие на ошибки и сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; – Высокий уровень CVSS 5.0 - 8.0 3 Средний не более 4 часов не более 120 часов – уязвимости, влияющие на невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым; – Средний уровень CVSS 2.0 - 4.9 4 Низкий не более 8 часов не более 160 часов – уязвимости, влияющие на отклонение в работе ППО, не влияющее на корректную работу функций; – другие сбои и ошибки, затрагивающие основные функции ППО; – Низкий уровень CVSS < 2.0 - Приложение Г Форма Отчета об оказанных услугах Отчет об оказанных услугах за этап «наименование этапа» в период с «__» _________ по «__» _________. № п/п Наименование услуги Общее количество Номер ОРС Краткое Описание Время реагирования по ТЗ Время реагирования фактическое Время решения по ТЗ Время решения фактическое Результат соблюдения времени реагирования Результат соблюдения времени решения Примечание 1 Услуги по информационно-консультационной поддержке работников Заказчика 2 546782 Консультация по работе Модуля СЦ 1 2 10 часов 11 часов Нет Нет 567123 Консультация по схеме БД 1 1 10 часов 1 час Да Да 2 … … Заказчик Подрядчик /Должность/ /Должность/ ____________________ /Ф.И.О/ ___________________ /Ф.И.О/ М.П. М.П. «_____»_______________________202_г. «_____»_______________________202_г - Приложение 1 к Отчету об оказанных услугах Журнал обращений (заявок) на оказание услуги по информационно-консультационной поддержке пользователей Системы (шаблон) Наименование Исполнителя в этапе «наименование этапа» в период с ________________ по _______________ оказал(о) Услугу по поддержке пользователей Системы в объеме, указанном в Таблице 1 Таблица 1 - Журнал обращений (заявок) пользователей Системы № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. ИТОГО зарегистрировано: Всего обращений (заявок): ________ ИТОГО решено: Всего обращений (заявок): ________ - Приложение 2 к Отчету об оказанных услугах Журнал обращений (заявок) по решению инцидентов, связанных с работой ППО (шаблон) Наименование Исполнителя в этапе «наименование этапа» в период с ________________ по _______________ оказал(о) Услугу по решению инцидентов в объеме, указанном в Таблице 1. Таблица 1 - Журнал по решению инцидентов № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. ИТОГО зарегистрировано: Всего инцидентов: ________ ИТОГО решено: Всего инцидентов: ________ - Приложение 3 к Отчету об оказанных услугах Журнал обращений (заявок) выполнения адаптационного, конфигурационного и коррекционного сопровождения Системы (шаблон) Журнал выполнения адаптации, конфигурации и коррекции Системы сформирован за этап «наименование этапа» в период с «__» _________ по «__» ____________ и представлен в таблице ниже (Таблица 1). Таблица 1 - Журнал выполнения адаптации, конфигурации и коррекции сопровождения Системы № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. Количество выполненных заявок за этап: ________ - Приложение 4 к Отчету об оказанных услугах Журнал обращений (заявок) по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности (шаблон) Журнал обращений (заявок) по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности сформирован за этап «наименование этапа» в период с «__» _________ по «__» ____________ и представлен в таблице ниже (Таблица 1). Таблица 1 - Журнал выполнения заявок по устранению уязвимостей в ППО № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. Количество выполненных заявок за этап: ________ - Третий уровень технической поддержки (далее – 3-й уровень) Группа ответственных сотрудников Исполнителя, отвечающая за устранение сбоев и аварий, проведение информационно-консультационной поддержки пользователей Системы, проведение адаптации и конфигурирования Системы в объемах действующих контрактов на оказание технической поддержки - 3.3 Перечень и описание статусов обращений (заявок) В Таблице 3 приведен перечень статусов обращений (заявок), действующий в СРО, и их описание. Таблица 3 - Перечень статусов обращений (заявок) и их описание Статус Описание Зарегистрирован Обращение (заявка) принято и зарегистрировано Направлен в группу Присваивается при назначении ответственными сотрудниками 1-го уровня группе ответственных сотрудников 2-го уровня по тематике обращения (заявки) после заполнения всей необходимой информации и полей обращения (заявки), а также при его передаче между группами 2-го уровня Передан в группу Присваивается при передаче обращения (заявки) ответственными сотрудниками 2-го уровня на группу ответственных сотрудников 3-го уровня Назначен Присваивается при назначении обращения (заявки) на ответственного сотрудника для его решения в рамках компетенции В работе Присваивается при приеме обращения (заявки) в работу ответственным сотрудником для его решения Решен Присваивается ответственным сотрудником, выполнившим работы по обращению (заявке) Закрыт Присваивается автоматически при решении запроса по обращению (заявке), а также отсутствии дополнительных запросов пользователя в соответствии с действующим SLA, или при подтверждении решения обращения (заявки) со стороны пользователя Запрос доп. информации Присваивается при необходимости запроса дополнительной информации и/или уточнения предмета обращения по обращению (заявке) у пользователя Ответ предоставлен Присваивается после ответа пользователем на запрос дополнительной информации Отклонен Присваивается, если обращение (заявка) не актуальна (по информации от пользователя), отсутствует техническая возможность решения обращения (заявки), предмет обращения не входит в компетенции технической поддержки, или существует влияние доработки на другие компоненты, что нарушает общий порядок работы Системы - Согласование Присваивается при необходимости согласования направления обращения (заявки) ответственным сотрудником Заказчика на 3-й уровень Анализ Присваивается при проведении анализа на предмет возможности внесения изменений, связанных с развитием/улучшением/оптимизацией Системы и выводом новой функциональности и оценке ресурсоемкости Тестирование Присваивается Исполнителем при завершении разработки и проведенном предварительном тестировании для последующего осуществления приемочного тестирования Специалистом 2-го уровня Релиз Присваивается ответственным сотрудником Заказчика при принятии решения о возможности вывода доработки в продуктивную среду Утверждение заказчиком Присваивается при согласовании группой профильных специалистов на 2-м уровне поддержки с пользователем технического задания для внесения изменений, связанных с развитием/улучшением/оптимизацией Системы и выводом новой функциональности Доработка Присваивается в случае несогласования Заказчиком работ, проведенных Исполнителем в рамках контрактных обязательств, по внесению изменений, связанных с развитием/улучшением/оптимизацией Системы и выводом новой функциональности в штатном режиме, и необходимости последующего направления Исполнителю для ее доработки Отложен Присваивается в случае невозможности выполнения запроса, изложенного в обращении (заявке), в связи с необходимостью запроса дополнительной информации у третьих сторон

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

ОПРЕДЕЛЕНИЯ, ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ - Автоматизированная система (АС) Система, состоящая из комплекса средств автоматизации, реализующего информационную технологию выполнения установленных функций, и персонала, обеспечивающего его функционирование (ГОСТ Р 59853-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения») АРМ Автоматизированное рабочее место АСУ ТК, Система Информационно-аналитическая система регулирования на транспорте АТС Автоматическая телефонная станция БД База данных ГИС Государственная информационная система ГОСТ Государственный стандарт ГЦОД СИЦ Минтранса России, ГЦОД Головной центр обработки данных ФГБУ «СИЦ Минтранса России» Дашборд Интерактивная аналитическая панель, графический интерфейс. ЕИС Единая информационная система в сфере закупок ЕСИА Единая система идентификации и аутентификации Заказчик Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» КИИ Критическая информационная инфраструктура Кластер Кла?стер (англ. cluster) – объединение нескольких однородных элементов, которое может рассматриваться как самостоятельная единица, обладающая определёнными свойствами Компонент Часть АС, выделенная по определенному признаку или совокупности признаков и рассматриваемая как единое целое (ГОСТ Р 59853-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения») Контракт Контракт на выполнение работ по развитию и оказанию услуг по технической поддержке Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК в 2026 году, заключаемый по результатам проведения конкурентной процедуры закупки в соответствии с требованиями Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» - - Значение характеристики не может изменяться участником закупки

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

ФГБУ «СИЦ Минтранса России» Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации», Заказчик Федеральный закон № 44-ФЗ Федеральный закон от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» ФЗ Функциональная задача ФЗ «Реестр объектов» Функциональная задача «Формирование и ведение единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации» ФСБ России Федеральная служба безопасности Российской Федерации ФСТЭК России Федеральная служба по техническому и экспортному контролю ЧС Чрезвычайная ситуация ЭВМ Электронно-вычислительная машина API От англ. Application Programming Interface – интерфейс прикладного программирования – совокупность инструментов и функций в виде интерфейса для взаимодействия с программой CSS От англ. Cascading Style Sheets — каскадные таблицы стилей FPS От англ. frame per second - количество кадров в секунду HTML От англ. HyperText Markup Language - стандартный язык разметки документов, создающий основу и структуру всех веб-страниц JSON От англ. JavaScript Object Notation – текстовый формат обмена данными, основанный на JavaScript WebAssembly (Wasm) Открытый стандарт, представляющий собой низкоуровневый бинарный формат инструкций, который позволяет выполнять код, написанный на языках C++, Rust или Go, в браузерах с производительностью, близкой к нативной

1. ОБЩИЕ СВЕДЕНИЯ - – постановление Правительства Российской Федерации от 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 Федерального закона «Об электронной подписи»; - - Значение характеристики не может изменяться участником закупки

– постановление Правительства Российской Федерации от 08.06.2011 № 451 «Об инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг и исполнения государственных и муниципальных функций в электронной форме»; – постановление Правительства Российской Федерации от 30.01.2013 № 62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин»; – приказ ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации»; – приказ ФСТЭК России от 11.04.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений»; – приказ ФСБ России от 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 «Национальный стандарт Российской Федерации. Интеллектуальная собственность. Патентные исследования. Содержание и порядок проведения»;

1.1. Наименование Системы Полное наименование системы: Информационно-аналитическая система регулирования на транспорте. Условное обозначение системы: АСУ ТК. Полное наименование модуля: Модуль сбора, ведения и анализа информации о нештатных ситуациях на транспорте. Условное обозначение модуля: Модуль СЦ. Модуль СЦ создан в рамках контракта от 05.08.2024 № ОК/24_04 на выполнение работ по развитию АСУ ТК в части создания модуля «Сбора, ведения и анализа информации о нештатных ситуациях на транспорте». Развитие Модуля СЦ осуществлено в рамках контракта от 19.05.2025 № ОК/25_09 на выполнение работ по развитию Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК

– ГОСТ Р 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.7. Сроки начала и окончания работ Начало работ: с даты заключения Контракта. Окончание работ: не позднее 15.12.2026. Работы выполняются в соответствии с этапами. Сроки выполнения этапов работ по развитию и технической поддержке Модуля СЦ определяются Календарным планом. Календарный план, приведен в разделе 5 настоящего ТЗ

1.2. Шифр темы или номер контракта Присваивается Заказчиком по результатам организации закупочных процедур. 1.2.1. Предмет контракта Выполнение работ по развитию Модуля СЦ. Код по ОКПД2: 62.01.11.000 – услуги по проектированию и разработке информационных технологий для прикладных задач и тестированию программного обеспечения. Оказание услуг по технической поддержке Модуля СЦ. Код по ОКПД2: 62.02.30.000 – услуги по технической поддержке информационных технологий. Выполнение работ по развитию Модуля СЦ предусмотрено с учетом ключевых результатов (ОКР) Ведомственной программы цифровой трансформации Минтранса России на 2026-2028 (далее - ВПЦТ Минтранса России) в составе мероприятия № 103.002 «АСУ ТК» ИТ расхода 103.26.000005 «Развитие Информационно-аналитической системы регулирования на транспорте (АСУ ТК)»: · «Обеспечено информационное взаимодействие с Минобороны о происшествиях на транспортных объектах»; · «Обеспечена автоматизация формирования отчетов о нештатных ситуациях на транспорте, в том числе по данным внешних систем». Выполнение работ по технической поддержке АСУ ТК предусмотрено ВПЦТ Минтранса России в составе мероприятия № 103.002 «АСУ ТК» ИТ расхода 103.26.000021 «Эксплуатация Информационно-аналитической системы регулирования на транспорте (АСУ ТК)»

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

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

1.5. Основания для выполнения работ Работы осуществляются на основании следующих документов: – постановление Правительства Российской Федерации от 30.12.2003 № 794 «О единой государственной системе предупреждения и ликвидации чрезвычайных ситуаций»; – постановление Правительства Российской Федерации от 08.11.2013 № 1007 «О силах и средствах единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций»; – распоряжение Правительства Российской Федерации от 27.11.2021 № 3363-р «О Транспортной стратегии Российской Федерации до 2030 года с прогнозом на период до 2035 года»; – Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 26.08.2025 №ЕФ-3; – Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 27.11.2025 №ЕФ-23;

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

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

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

– Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 19.02.2026 №ЕФ-1; – План мероприятий по профилактике случаев непроизводственного травматизма граждан на железнодорожном транспорте, являющийся приложением к постановлению коллегии Министерства транспорта Российской Федерации от 11.03.2026 № 2

1.6. Перечень документов, требования которых должны быть учтены при выполнении работ – Федеральный закон Российской Федерации от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации»; – Федеральный закон Российской Федерации от 27.07.2006 № 152-ФЗ «О персональных данных»; – Федеральный закон Российской Федерации от 06.04.2011 № 63-ФЗ «Об электронной подписи»; – Федеральный закон Российской Федерации от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации»; – Указ Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации»; – Указ Президента Российской Федерации от 01.05.2022 № 250 «О дополнительных мерах по обеспечению информационной безопасности Российской Федерации»; – Указ Президента Российской Федерации от 31.03.2010 № 403 «О создании комплексной системы обеспечения безопасности населения на транспорте»; – постановление Правительства Российской Федерации от 30.07.2004 № 395 «Об утверждении Положения о Министерстве транспорта Российской Федерации»; – постановление Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации»; – постановление Правительства Российской Федерации от 16.11.2015 № 1236 «Об установлении запрета на допуск программного обеспечения, происходящего из иностранных государств, для целей осуществления закупок для обеспечения государственных и муниципальных нужд»; – постановление Правительства Российской Федерации от 23.12.2024 № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц»;

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

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

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

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

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

8 Подсистема проектного архива АСУ ТК Подсистема проектного архива АСУ ТК предназначена для автоматизации деловых процессов должностных лиц Министерства транспорта Российской Федерации, подведомственных агентств и службы, в том числе, и процессов информационного взаимодействия внутреннего и внешнего характера 9 ФЗ «Реестр объектов» Функциональная задача предназначена для формирования и ведения единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации 10 ФЗ «СТП» Функциональная задача предназначена для организации информационно-аналитической поддержки процессов территориального планирования Российской Федерации в области федерального транспорта 11 ФЗ «МРТБ ПП» Функциональная задача предназначена для формирования и ведения межрегионального транспортного баланса пассажирских перевозок в дальнем (межрегиональном) сообщении 12 ФЗ «МДД» Функциональная задача предназначена для осуществления мониторинга дорожного движения 13 ФЗ «ТПР» Функциональная задача предназначена для формирования и ведения транспортного паспорта региона 14 ФЗ «Данные по грузообороту» Функциональная задача предназначена для обеспечения подсистем и пользователей АСУ ТК данными по грузообороту между Российской Федерацией и зарубежными странами 15 ФЗ «МЖТ» Функциональная задача предназначена для осуществления мониторинга железнодорожного транспорта 16 ФЗ «МГМП» Функциональная задача предназначена для осуществления мониторинга грузопотоков в морских портах с целью формирования единой цифровой среды мониторинга и планирования перевозок в/из портов Дальнего Востока

17 Модуль ГЭТ Модуль предназначен для получения, хранения данных инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по отдельно взятому предприятию-перевозчику. Формирования отчетов об инвентаризации с детальными данными по каждому разделу инвентаризации с маршрутизацией в муниципалитет / регион / Минтранс. Содержит агрегированные данные инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по всем перевозчикам, относящихся к данному муниципалитету. Формирует сводный отчет по муниципалитету по каждому разделу инвентаризации с маршрутизацией в регион / Минтранс. Формирует агрегированные данные инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по всем перевозчикам, относящиеся к данному региону и по всем муниципалитетам, относящимся к данному региону. Аналитические и статистические данные о состоянии ГЭТ региона. Содержит данные о видах транспорта, цифровых транспортных сервисах и платежных инструментах Региона. Формирует сводный отчет по каждому разделу инвентаризации с маршрутизацией в Минтранс. Формирует агрегированную статистику и аналитику по всем регионам страны в разрезе транспортных средств, маршрутов, пассажиропотоков, инфраструктуры ГЭТ. Данные о рейтинге регионов и перевозчиков на основании выбранных параметров, документооборот с участниками Системы: получение подписанных печатных форм, их утверждение, возврат на доработку. 18 Модуль iМинтранс Модуль создан для отчета по ключевым показателям транспортного комплекса России (Отраслевые и статистические показатели, исполнение бюджета, исполнение поручений, аналитика СМИ, происшествия по видам транспорта). 19 Модуль СЦ Модуль СЦ предназначен для оперативного мониторинга нештатных ситуаций транспортной отрасли, оповещения заинтересованных лиц и структур и предоставления данных о нештатных ситуациях

АСУ ТК осуществляет идентификацию и авторизацию посредством Единой системы идентификации и аутентификации (ЕСИА). Информационный обмен с внешними информационными системами осуществляется посредством СМЭВ 3 и СМЭВ 4. АСУ ТК развернута на вычислительных мощностях ГЦОД СИЦ Минтранса России

3.2. Описание и текущее состояние объекта автоматизации Модуля СЦ Объектом автоматизации является процесс организации мониторинга информации о НС и ЧС на транспорте. Предметом деятельности Учреждения являются следующие функции: – информационное обеспечение в области транспортной безопасности, защиты населения и территорий от чрезвычайных ситуаций природного и техногенного характера в транспортном комплексе; – подготовка справочных материалов при угрозе возникновения и возникновении чрезвычайных ситуаций и иных происшествий в транспортном комплексе; – взаимодействие и обмен оперативной информацией с органами управления Единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций; – организация оперативного мониторинга обстановки на объектах транспорта при угрозе и возникновении чрезвычайных ситуаций и иных происшествий. Перечень компонентов Модуля СЦ и выполняемые ими функции представлены в Таблице 2

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

3 Информирование – ведение справочника способов оповещения (веб-интерфейс, мессенджер); – формирование сценария выполнения оповещения (настройка условий, способа, параметров оповещения); – выполнение оповещений пользователей 4 Отчетность – формирование отчета и справки о событиях; – фильтрация событий для выгрузки в справку о событиях или в отчет о событиях 5 Администрирование – ведение ролей пользователей; – ведение учетных данных пользователей; – ведение справочника организаций; – ведение справочника групп системы мгновенного обмена сообщениями; – выполнение исходящего звонка на контактный телефонный номер организации; – формирование матрицы эскалации событий Архитектура Модуля СЦ представлена на рисунке 1. Рисунок 1. Архитектура Модуля СЦ

3.3. Состав используемого ПО Модуля СЦ Программная архитектура Модуля СЦ разработана как трехуровневая клиент-серверная архитектура. Архитектура включает в себя следующие уровни: • уровень представления – презентационный уровень, обеспечивающий взаимодействие с пользователя с клиентскими приложениями с использованием веб-браузера («тонкий» клиент); • уровень приложений – реализован в виде сервисов, обеспечивает обработку запросов, поступающих от клиентских приложений, формирование ответов на запрос в доступном пользователю виде (формирование пользовательских интерфейсов); • уровень хранения данных – реализуется как сервер БД и обеспечивает хранение и целостность хранимых данных, создание резервных копий, ведение журнала транзакций, восстановление данных после сбоев. Программная архитектура Модуля СЦ включает в себя сервисы и интерфейсы, указанные в Таблице 3. Таблица 3. Программная архитектура Модуля СЦ Программный сервис/интерфейс Технологии реализации Уровень представления Интерфейс пользователя и администратора (front-end) Javascript Уровень приложений Сервис (GateWay) Kotlin Сервис геокодирования (geocoding-service) Kotlin Сервис уведомлений (notifiсation-service) Kotlin Сервис работы с файлами (file-service) Kotlin Сервис отчетности (report-service) Kotlin Сервис управления событиями (event-service) Kotlin Сервис информирования через мессенджер (messenger-notifier) Python Сервис внешних интеграций (integration-service) Сбор информации из внешних систем и сервисов Брокер сообщений Kafka Уровень хранения данных Файловое хранилище MinIO S3 СУБД Postgres Pro Enterprise

3.4. Информационное взаимодействие программных сервисов и интерфейсов Модуля СЦ Объект автоматизации функционирует в распределенной информационной среде. Обмен данными осуществляется по защищенным каналам связи (в том числе ведомственным сетям передачи данных). Источники информации включают: · внешние автоматизированные системы (органов государственной власти); · внутренние базы данных (реестры объектов транспортной инфраструктуры, паспорта регионов и пр.); · оперативная информация от персонала, поступающая через автоматизированные рабочие места (АРМ) и мобильные устройства. 3.4.1. Взаимодействие Модуля СЦ со смежными подсистемами АСУ ТК Модуль СЦ входит в состав АСУ ТК и взаимодействует со следующими ее функциональными задачами и подсистемами: · Функциональной задачей «Формирование и ведение единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации» (ФЗ «Реестр объектов»); · Геоинформационной подсистемой АСУ ТК (П-ГИС); · Подсистемой ведения нормативно-справочной информации и метаданных (П-НСИ); · Подсистемой сбора данных и централизованное хранилище данных (П-СД); · Подсистемой информационного взаимодействия (П-ИВ). 3.4.2. Взаимодействие с внешними информационными системами Список внешних информационных систем, с которыми осуществляется взаимодействие Модуля СЦ: · ЕСИА; · мессенджер; · Яндекс Геокодер; · Информационная система «Централизованная система сбора информации систем-112»; · ПВК «Поиск-Море», АИС РПТ; · облачная АТС

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

3.1. Описание объекта автоматизации АСУ ТК Объектом автоматизации являются процессы основной и обеспечивающей деятельности, направленные на управление транспортным комплексом, в том числе, процессы информационного взаимодействия с другими организациями и субъектами транспортного комплекса. АСУ ТК относится к государственным информационным системам, а также к информационным системам персональных данных и значимым объектам критической информационной инфраструктуры Российской Федерации. АСУ ТК соответствует требованиям, предъявляемым к: – ГИС второго класса защищенности в соответствии с приказом ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах»; – ИС персональных данных при обеспечении третьего уровня защищенности персональных данных в соответствии с требованиями постановления Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»; – значимым объектам КИИ Российской Федерации второй категории значимости с постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении Правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений». Модуль СЦ является подсистемой АСУ ТК. Перечень платформенных решений и функциональных задач АСУ ТК представлен в Таблице 1

4. ТРЕБОВАНИЯ К МОДУЛЮ СЦ - 4.2.4. Создание компонента «Интерактивная карта» (2 очередь) В составе создаваемого компонента должны отображаться данные, доступные в компоненте визуализации. Требования к интерфейсу интерактивной карты: – интерактивная карта должна быть представлена в виде объемной карты с учетом макетов, представленных в Приложении А к ТЗ; – интерфейс должен корректно отображаться на экранах мониторов (разрешение Full HD 1920?1080), телевизоров (разрешение 4К 3840?2160), жидкокристаллических панелей для видеостены, используемой Заказчиком, с параметрами каждой панели: диагональ 55 дюймов, разрешение 1920x1080; – интерфейс должен корректно отображаться на планшетных устройствах с диагональю экрана 10-12 дюймов, конкретные требования должны быть уточнены на этапе технического проектирования; – должна быть обеспечена кластеризация и генерализация отображения объектов на карте при изменении масштаба; – должно быть обеспечено отображение основных характеристик объектов при выборе их на карте; – должно быть обеспечено управление отображением слоев на карте; – должна быть обеспечена настройка цветовой индикации отображаемых объектов транспортной инфраструктуры; – должно быть обеспечено отображение легенды карты, содержащей отображаемые объекты на карте; – должна быть обеспечена возможность одновременного отображения не менее 5 000 ОТИ и ТС на карте. - - Значение характеристики не может изменяться участником закупки

На интерактивной карте должны быть отображены подвижные объекты совместно с объектами транспортной инфраструктуры (ОТИ), включая следующие возможности: § отображение местоположения транспортных средств (воздушный, водный и автомобильный транспорт) на карте в режиме реального времени (с заданным периодом обновления данных); § отображение маршрутов движения всех ТС за выбранный период времени, в том числе с использованием эффектов анимации; § отображение маршрутов движения ТС, связанных с карточкой события: ТС, являющихся участниками события, и ТС, находящиеся в заданном радиусе от события; § управление отображением сущностей и ОТИ на карте, включая настройку состава отображаемых объектов, поиск, фильтрацию, с использованием соответствующей панели управления и наглядным представлением результатов; § автоматическое изменение вида отображения объектов (цветовая индикация) по заданным условиям (например, при достижении критических значений параметров, характеризующих функционирование объекта); Должна обеспечиваться производительность обновления изображения на экране в 30 кадров в секунду на тестовой конфигурации пользовательского устройства (модель Бештау AIO2402/B560, входящая в Реестр российской промышленной продукции под номером 10394100 или аналог) при одновременном отображении не менее 5 000 объектов и 200 уникальных моделей объектов. Макеты интерфейсов Модуля СЦ должны быть предварительно согласованы с Заказчиком и разработаны с учетом требований ГОСТ Р ИСО 9241-161-2016 «Элементы графического пользовательского интерфейса»

Таблица 6. Категории обращений и заявок Категория Примеры Запрос на обслуживание Подготовка SQL запроса к СУБД для решения прикладной задачи и д.р. – запрос на любое действие, не являющееся запросом информации и несовершенный на основе происшествия, прямо или косвенно влияющего на работу Модуля СЦ Консультация «Где взять / куда обратиться...?», «Как сделать / выполнить…», «Как это работает…?» - запрос, имеющий своей целью получение информационной поддержки Инцидент Разбор ошибок/сбоев и подготовка материалов (корректировочных релизов, инструкций) для Заказчика для устранения ошибок/сбоев, которые приводят к частичному и полному нарушению работоспособности всех или отдельных функций ППО. Подготовка изменения и материалов, необходимых для проведения аварийно-восстановительных работ для возобновления работоспособности Модуля СЦ ЗНИ Подготовка изменений, связанных с изменением, улучшением/оптимизацией Модуля СЦ и выводом новой модифицированной функциональности в штатном режиме. Подготовка изменений, связанных с модификацией существующих и/или реализация новых интеграционных механизмов для получения/обработки данных внешних систем. Подготовка изменений графического интерфейса по требованиям Заказчика. Перечень статусов обращений (заявок) приведен в пункте 3.3. Регламента оказания Услуг. Назначение обращению (заявке) статуса «Закрыто» осуществляется Заказчиком только после получения от инициатора обращения (заявки) подтверждения о его исполнении или нахождения обращения (заявки) в статусе «Выполнено» и отсутствия повторных вопросов/запросов по данному обращению (заявки) в течение 5 рабочих дней. Категории и статусы обращений (заявок) могут быть скорректированы в процессе оказания услуг исключительно по согласованию с Заказчиком

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

4.2.4.1. Требования к технической реализации компонента «Интерактивная карта» При реализации компонента «Интерактивная карта» должны учитываться требования, указанные ниже. 4.2.4.1.1. Требования к отображению элементов Повторяющихся элементы карты (ТС, ОТИ, события и пр.) должны отрисовываться с использованием аппаратного создания экземпляров объектов на пользовательском устройстве (WebGL/WebGPU)). Отрисовка каждого объекта отдельным запросом не допускается, должна обеспечиваться возможность одновременного отображения не менее 5 000 объектов без снижения производительности (30 кадров в секунду на тестовой конфигурации). 4.2.4.1.2. Уровни детализации объектов Для управления отображением сложных объектов должно быть создано не менее 3-х уровней детализации, отображаемых при изменении масштаба с возможностью автоматического переключения между уровнями. Все отображаемые объекты должны масштабироваться с учетом разрешения экрана пользователя с сохранением качества детализации. 4.2.4.1.3. Полигональная оптимизация и текстурирование При реализации компонента «Интерактивная карта» должна обеспечиваться технология рельефного тестурирования объектов. Не должны использоваться высокополигональные трехмерные модели. Все повторяющиеся элементы должны генерироваться единоразово и повторно использоваться при последующих отображениях. 4.2.4.1.4. Управление памятью Требуется реализовать потоковую загрузку на устройство пользователя элементов карты и текстур. Загрузка данных целиком при старте приложения не допускается. Необходимо реализовать механизм очистки памяти от элементов, которые находятся вне области видимости камеры в течение заданного времени. 4.2.4.1.5. Требования к взаимодействию пользователя с интерфейсом компонента «Интерактивная карта» Программная реализация механизмов управление камерой (масштабирование и навигация) должна быть выполнена с поддержкой технологии WebAssembly (WASM). Элементы управления должны являться неотъемлемой частью интерактивной карты.

4.2.5. Развитие компонента администрирования (3 очередь) Должна быть выполнена доработка ролевой модели. Ролевая модель должна обеспечивать управление доступом к отдельным объектам Модуля СЦ и их элементам (атрибутам) с разграничением по видам транспорта, регионам и пр., в частности: – определение набора конкретных действий, доступных пользователям (выполняемых над объектом доступа, например, удаление записи, редактирование записи, формирование отчета и др.); – реализация возможности объединения пользователей в группы; – определение прав доступа для групп пользователей; – реализация интерфейса визуальной настройки прав доступа пользователей к объектам Модуля СЦ

4.3.6.2. Требования к услугам информационно-консультационной поддержки работников Заказчика и пользователей Модуля СЦ Услуги информационно-консультационной поддержки сотрудников Заказчика включают: – обработку обращений и заявок, поступивших от сотрудников Заказчика; – консультирование сотрудников Заказчика и пользователей Модуля СЦ; – актуализацию документации, и других материалов по работе с Модулем СЦ при необходимости. – консультирование и разработку рекомендаций по настройке Модуля СЦ (без изменения программного кода), включая изменение настроек функционирования; – консультации по вопросам использования, настройки и возможностям Модуля СЦ; – консультации по проведению превентивных мер для недопущения аварийных ситуаций в Модуле СЦ; – консультации по предварительной диагностике и локализации возникшей неисправности Модуля СЦ; – консультации по вопросам обеспечения информационной безопасности Модуля СЦ и настройки функций, обеспечивающих корректную работу программного обеспечения для совершения юридически значимых действий в Модуле СЦ; – другие вопросы, связанные с работой Модуля СЦ. 4.3.6.2.1. Требования к порядку оказания услуг информационно-консультационной поддержки работников Заказчика и пользователей Модуля СЦ Подрядчик выполняет консультирование сотрудников Заказчика и пользователей Модуля СЦ. Консультация может быть предоставлена по согласованным с представителем Заказчика каналам коммуникации с регистрацией результата консультации в СРО Подрядчиком. Детальный порядок оказания консультационных услуг определен в Регламенте оказания Услуг

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

4.2.6. Взаимосвязи с внешними автоматизированными системами (1 очередь) Способы взаимодействия с внешними информационными системами должны быть определены на этапе технического проектирования. Должны быть выполнены следующие доработки: – интеграции с информационными ресурсами в целях получения данных о движении подвижных ТС (воздушные суда, суда водного транспорта); – интеграция с информационным ресурсом в целях получения данных о событиях на железнодорожном транспорте. Реализация интеграций должна включать проектирование и реализацию интеграционных механизмов обмена данными с учетом доступных вариантов реализации, обеспечение защищенных способов взаимодействия, настройку отображения отдельных данных на карте (настройка слоев). Взаимодействия, имеющие каналы связи, выходящие за пределы контролируемой зоны взаимодействующих систем, считаются защищенными, если для их защиты используются программные и/или программно-аппаратные шифровальные (криптографические) средства, сертифицированные ФСБ России (далее – СКЗИ). Выбор СКЗИ, схемы подключения и требуемого класса криптостойкости должен производиться в соответствии с Техническими условиями на подключение к информационным ресурсам ФГБУ «СИЦ Минтранса России» и инструкциями по подключению пользователей к ресурсам инфраструктуры Головного центра обработки данных, утвержденных приказом директора ФБГУ «СИЦ Минтранса России» от 24.05.2024 № 21-ОД

4.3. Требования к оказанию услуг по технической поддержке Модуля СЦ 4.3.1. Общие требования к оказанию Услуг Техническая поддержка Модуля СЦ должна осуществляться с учетом требований постановления Правительства Российской Федерации от 06.07.2015 N 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации». Подрядчик обязан выполнять требования законодательства в сфере защиты информации, требования по защите информации, информационной безопасности, указанные в локальных нормативных актах ФГБУ «СИЦ Минтранса России», регламентирующих условия информационного взаимодействия, защиты информации и подключения к информационным ресурсам ФГБУ «СИЦ Минтранса России», участвующих в информационном взаимодействии в рамках оказания услуг по технической поддержке АСУ ТК в 2026 году

4.3.1.1. Требования к составу и содержанию услуг третьего уровня технической поддержки Оказание услуг по технической поддержке Системы осуществляется в рамках этапов в соответствии с календарным планом. Подрядчик в течение 5 рабочих дней с даты заключения Контракта должен предоставить со своей стороны, а Заказчик со своей стороны Матрицу ответственных за взаимодействия в соответствии с Приложением 1 к Регламенту оказания услуг по третьему уровню технической поддержки Модуля СЦ (далее – Регламент, Приложение В). Подрядчик в течение 10 рабочих дней с даты заключения Контракта должен провести мероприятия по организации третьего уровня технической поддержки в соответствии с Регламентом. Услуги по третьему уровню технической поддержки Модуля СЦ должны включать: – организацию Подрядчиком третьего уровня технической поддержки; – информационно-консультационную поддержку работников Заказчика; – решение инцидентов, связанных с работой ППО; – адаптационное, конфигурационное и коррекционное сопровождение Модуля СЦ (в рамках действующих программных модулей и функциональности); – устранение уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности

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

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

4.4.7.1.5. Требования к используемым зависимостям (библиотекам) Все внешние зависимости проекта должны быть зафиксированы с указанием точных версий. Для контроля версий зависимостей в репозиторий обязательно должны быть включены следующие файлы: · Для JavaScript: package-lock.json или yarn.lock; · Для Python: requirements.txt (с зафиксированными версиями) или Pipfile.lock; · Для Go: go.mod и go.sum; Загрузка всех зависимостей должна производиться исключительно через внутренний прокси-репозиторий Заказчика, настроенный в соответствующем системе менеджере пакетов. Запрещается: · Использование плавающих версий (например, ^1.2.3, ~4.5.0, latest); · Использование библиотек, содержащих критические уязвимости, в том числе зарегистрированные в реестре CVE (Common Vulnerabilities and Exposures). 4.4.7.1.6. Требования к процессу непрерывной интеграции (CI) Сборка программного обеспечения, включая этапы компиляции, тестирования и анализа кода, должна выполняться исключительно в инфраструктуре непрерывной интеграции Заказчика. 4.4.7.1.7. Требования к хранению артефактов сборки Все артефакты сборки (результирующие пакеты, Docker-образы и т.д.) подлежат обязательному хранению в предназначенной для этого инфраструктуре Заказчика (артефакторий). Запрещается размещение финальных артефактов сборки на сторонних ресурсах

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

4.5. Общие технические требования 4.5.1. Требования к численности и квалификации персонала и пользователей Модуля СЦ Программное обеспечение Модуля СЦ не должно требовать изменения штатной численности персонала Заказчика. Программное обеспечение Модуля СЦ не должно требовать наличия у пользователей дополнительной квалификации в сфере информационных технологий, кроме базовых знаний в обращении с персональным компьютером, базовых навыков работы в интернет-обозревателях и знаний о Модуле СЦ в объеме документов Руководство пользователя, Руководство администратора

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

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

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

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

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

4.3.6.4. Требования к услугам адаптационного, конфигурационного и коррекционного сопровождения и доработки Модуля СЦ (в рамках действующих программных модулей и функциональностей) Услуги адаптационного, конфигурационного и коррекционного сопровождения и доработки Модуля СЦ включают: – управление изменениями и адаптация функций Модуля СЦ; – изменение настроек функционирования Модуля СЦ; – внесение изменений и/или модификаций Модуля СЦ (в рамках действующих программных модулей и функциональностей), направленных на улучшение их работоспособности и функциональных возможностей; – подготовка и передача Заказчику SQL запросов в СУБД для получения агрегированной информации из Модуля СЦ, которую невозможно получить с использованием графического пользовательского интерфейса; – адаптация модулей интеграций со смежными информационными системами

4.3.6.4.1. Требования к проведению изменений Основанием для внесения изменений является запрос от Заказчика. Все активности по внесению изменений должны быть согласованы с Заказчиком, а действия Подрядчика при оказании данной услуги должны быть зафиксированы. В рамках данного Технического задания изменениями считаются локальные доработки функционала Модуля СЦ, которые не должны приводить к необходимости выполнения дополнительных аттестационных испытаний или переаттестации АСУ ТК в соответствии с п. 33 приказа от 29.04.2021 № 77 «Об утверждении Порядка организации и проведения работ по аттестации объектов информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну». При необходимости внесения изменений в Модуль СЦ, не связанных с критичным инцидентом, существенно нарушающим работоспособность Модуля СЦ, Заказчик направляет Подрядчику обращение (заявку), в котором излагает суть изменения, которое требуется внести в Модуль СЦ. Исполнитель, в течение 3 (трех) рабочих дней с момента поступления соответствующего обращения (заявки), оценивает техническую возможность реализации запрашиваемого изменения и варианты реализации. По итогу проведения оценки Подрядчик направляет Заказчику заключение о возможности реализации данного изменения с описанием возможных вариантов реализации и согласует с Заказчиком проведение данного изменения

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

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

В аварийном режиме осуществляется поиск неисправностей и проведение работ по их устранению. Перевод в аварийный режим должен осуществляться при возникновении сбоев, аварий и прочих незапланированных воздействий, сразу после наступления одной или нескольких аварийных ситуаций, с последующим возвратом в штатный режим функционирования сразу после окончания восстановительных работ. ПО Модуля СЦ должно обладать надежностью, обеспечивающей работу пользователей в произвольном режиме и оперативное восстановление работоспособности при сбоях. В целях обеспечения надежного функционирования ПО должно предусматривать: – сохранение целостности данных при нештатном завершении работы компонентов Модуля СЦ; – сохранение работоспособности программного обеспечения при некорректных действиях пользователя; – резервное копирование базы данных Модуля СЦ. – время восстановления работоспособности Модуля СЦ после отказа не более 4 часов. – отказоустойчивость на уровне 99% при единовременной количестве не менее 200 пользовательских сессий в Модуле СЦ. Указанные характеристики приведены без учета характеристик надежности инфраструктуры и времени передачи информации по каналам связи. При возникновении сбоев в аппаратном обеспечении, включая аварийное отключение электропитания, Модуль СЦ должен автоматически восстанавливать свою работоспособность (не требовать перенастройки) после устранения сбоев и корректного перезапуска аппаратного обеспечения

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

4.5.8. Требования к защите от влияния внешних воздействий Требования к защите от влияния внешних воздействий не предъявляются

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

4.3.6.4.2. Требования к изменению настроек функционирования Изменение настроек функционирования может проводиться в рамках допустимых пределов изменения функционирования, заложенных в архитектуру Модуля СЦ. Изменение настроек функционирования включает в себя изменение данных и справочников, изменение форм документов, формируемых Модулем СЦ, изменение и настройку форматов и версий передачи данных в смежные системы. Доработка программного кода Модуля СЦ может допускаться (в случае необходимости) при выполнении работ по адаптации функций Модуля СЦ в части изменения формата передачи данных в смежные информационные системы при условии соблюдения требований пункта 29.3 приказа ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации»

4.3.6.5. Требования к услугам по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности По запросу Заказчика Подрядчик должен провести работу по приведению ППО в соответствие с требованиями по обеспечению информационной безопасности. Критичность уязвимости оценивается в соответствии в соответствии с Методическим документом ФСТЭК России «Методика оценки уровня критичности уязвимостей программных, программно-аппаратных средств» (утвержден ФСТЭК России 30.06.2025), а также с учетом ГОСТ 56545-2015 и международными стандартами (CVSS 3.0 и выше), и задает необходимый срок устранения. В процессе проведения Заказчиком обследования Модуля СЦ и выявления уязвимостей в ППО, связанных с исходным кодом Модуля СЦ и/или используемыми компонентами (библиотеками), Заказчик направляет Подрядчику обращение (заявку) на устранение, с указанием критичности и срочности принятия мер по устранению в СРО.

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

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

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

4.5.3. Требования по диагностированию Модуля СЦ Диагностирование Модуля СЦ должно осуществляться путем анализа записей в системных журналах СУБД, операционных систем серверов, а также с помощью встроенных средств диагностирования общего программного обеспечения Модуля СЦ. Диагностированию подлежат: – сбои и нарушения функционирования технического обеспечения (серверов) Модуля СЦ; – сбои и нарушения функционирования системного программного обеспечения серверов, используемых для работы Модуля СЦ; – сбои и нарушения функционирования прикладного программного обеспечения серверов, используемых для работы Модуля СЦ; – случаи недоступности (отсутствия ответа) или некорректные ответы внешних систем; – сбои и нарушения функционирования СУБД; – сбои при выполнении регламентных операций резервного копирования. При возникновении аварийных ситуаций либо ошибок в программном обеспечении диагностические инструменты должны позволять сохранять набор информации, необходимой для идентификации и устранения проблемы. Модуль СЦ и ее компоненты должны обеспечивать возможность диагностики своей работоспособности с возможностью интеграции с модулем мониторинга АСУ ТК. Набор передаваемых журналов и метрик должен быть определен на этапе технического проектирования

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

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

Лицензионное (сублицензионное) соглашение (договор) не может возлагать на Заказчика какие-либо обязанности (в т.ч. в части конфиденциальности, предоставления отчетности), не предусмотренные Контрактом. 4.5.9.7. Передача Заказчику исключительных прав, или простых (неисключительных) прав не может повлечь увеличение стоимости Контракта и/или изменение иных существенных условий Контракта. 4.5.9.8. Функциональность Модуля СЦ передается в объеме и в сроки, установленные Техническим заданием. 4.5.9.9. Нарушение условий настоящего раздела Технического задания, в т.ч. отсутствие соответствующего лицензионного (сублицензионного) соглашения (или договора), либо предоставление лицензионного (сублицензионного) соглашения (или договора), не соответствующего требованиям действующего законодательства Российской Федерации или требованиям Контракта, является нарушением существенных условий Контракта. 4.5.9.10. В случае, если в соответствии с пунктом 4.5.9.6 Заказчику передается исключительное право, такая передача осуществляется в порядке, установленном Гражданским кодексом Российской Федерации. 4.5.9.11. В случае, если при выполнении Работ положения пунктов 4.5.9.5-4.5.9.6 не применялись, Подрядчик в составе отчетной документации предоставляет об этом декларацию в свободной форме. Декларация должна содержать сведения о полном соответствии результата Работ требованиям Контракта, а также о неприменении при выполнении работ готового программного обеспечения (платформ, подсистем, СУБД и т.д.), которое стало частью (компонентом) Системы

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

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

4.3.1.2. Требования к общему порядку оказания услуг Техническая поддержка Модуля СЦ должна быть организована на трех уровнях: – первый и второй уровни технической поддержки организуется Заказчиком; – третий уровень технической поддержки организуется Подрядчиком. Перечень действий на каждом уровне технической поддержки указан в Таблице 5: Таблица 5 – Перечень действий на каждом уровне технической поддержки Уровень технической поддержки Доступные действия Условия передачи задачи на следующий уровень Первый уровень технической поддержки (далее – 1-й уровень) – принимает обращения (заявки) пользователей Модуля СЦ и работников Заказчика; – регистрирует обращения в Модуле СЦ регистрации обращений; – присваивает уникальный идентификационный номер, классифицирует обращения; – самостоятельно решает обращения, которые связаны с недостаточной квалификацией пользователей или настройками в рамках своей компетенции; – взаимодействует с пользователями Модуля СЦ при решении проблемы Передает обращение на второй уровень поддержки в случае невозможности решения на своем уровне Второй уровень технической поддержки (далее – 2-й уровень) – принимает обращения от 1-го уровня; – уточняет классификацию обращения в результате дополнительного анализа; – самостоятельно решает обращения в рамках своей компетенции; – осуществляет техническую и консультационную поддержку Модуля СЦ; – взаимодействует с сотрудниками 1-го и 3-го уровня и пользователями Модуля СЦ; – формирует заявки для 3-го уровня и контролирует исполнение Передает обращение на третий уровень поддержки в случае невозможности решения на своем уровне Третий уровень технической поддержки (далее – 3-й уровень) – принимает обращения от 2-го уровня; – обеспечивает выполнение требований, предъявляемых Контрактом и настоящим Техническим заданием к Услугам, оказываемым Подрядчиком Все поступающие обращения должны быть исполнены Подрядчиком

Для обеспечения взаимодействия с Заказчиком Подрядчик со своей стороны определяет ответственных лиц, уполномоченных в структуре Подрядчика за своевременное и качественное оказание Услуг в рамках настоящего ТЗ, а также контактную информацию ответственных лиц (телефон, электронную почту). Подрядчик должен предоставить Заказчику единый адрес электронной почты для приема обращений (заявок) в течение 3 (трех) рабочих дней после заключения Контракта. Указанный в настоящем пункте адрес электронной почты (способ направления обращений (заявок) применяется в случае сбоя в работе СРО Заказчика. Со своей стороны, Заказчик предоставляет Подрядчику перечень и контактную информацию (телефон, электронную почту) уполномоченных лиц для осуществления взаимодействия с указанием зон ответственности. О любых изменениях в контактной информации ответственных лиц Стороны должны уведомить друг друга в течение 1 (одного) рабочего дня с момента возникновения таких изменений посредством уведомления на электронную почту ответственных лиц и/или в письменной форме. В результате оказания услуг по настоящему ТЗ не должны быть изменены исходные коды, дистрибутивы и иные компоненты Модуля СЦ вне согласованных с Заказчиком изменений. Любые изменения исходных кодов, дистрибутивов и иных компонентов Модуля СЦ должны производиться только после согласования с Заказчиком уполномоченными лицами по электронной почте или иным заранее согласованным способом. Не должна быть ухудшена надежность и производительность Модуля СЦ. Оказание услуг по Контракту не должно нарушать требования к информационной безопасности, описанной в документации на Модуль СЦ

4.1. Требования к структуре Модуля СЦ В процессе работ по развитию Системы должны сохраниться основные требования к построению архитектуры Системы в соответствии с принципами трехуровневой архитектуры: 1. уровень хранения данных или уровень базы данных (сервер СУБД); 2. уровень сервера приложений (сервер аналитической обработки); 3. презентационный уровень, обеспечивающий взаимодействие с клиентскими приложениями. В состав Системы должны входить следующие основные компоненты: 4. сервер баз данных; 5. сервер приложений; 6. веб-сервер. Сервер баз данных должен обеспечивать хранение и целостность хранимых данных, создание резервных копий, ведение журнала транзакций, восстановление данных после сбоев. Сервер приложений должен обеспечивать обработку запросов, поступающих от клиентских приложений (через веб-сервер), формирование ответов на запрос в доступном пользователю виде (формирование пользовательских интерфейсов). Веб-сервер должен обеспечивать взаимодействие с оператором и внешними системами по HTTP / HTTPS протоколу в режиме «запрос-ответ» (получения запросов от пользователя и передачи ответа в виде соответствующей информации, обработанной серверами приложений). Взаимодействие Системы с пользователем должно отвечать требованиям модели «тонкого клиента» (т.е. представлять на стороне клиента (пользователя) лишь графический пользовательский интерфейс). Все составляющие Системы должны использовать единую методологию и отвечать единым принципам взаимодействия, надежности и управления. Перечень компонентов Модуля СЦ представлен в Таблице 4. Таблица 4. Перечень компонентов Модуля СЦ, в отношении которых выполняются работы по развитию № п.п. Наименование компонента Модуля СЦ Раздел ТЗ 1 Компонент регистрации событий 4.2.1. 2 Компонент отчетности 4.2.2 3 Компонент визуализации 4.2.3 4 «Интерактивная карта» (компонент создается) 4.2.4 5 Компонент администрирования 4.2.5

4.2. Требования к дорабатываемым функциям модуля СЦ 4.2.1. Развитие компонента регистрации событий (1 очередь) Должны быть выполнены следующие доработки: – обеспечение логирования действий пользователя, связанных с карточкой события; – доработка объектной модели в части создания новых типов сущностей (карточек) с учетом реализуемых интеграций с информационными ресурсами (силы и средства предупреждения и ликвидации ЧС и нештатных ситуаций на транспорте, ТС, ограничения воздушного пространства, неблагоприятные и опасные природные явления); – реализация механизма установления связи между сущностями в Модуле СЦ автоматизированным и ручным способами (события, природные явления, силы и средства предупреждения и ликвидации ЧС и нештатных ситуаций на транспорте, ограничения воздушного пространства, ОТИ, ТС и др.); – отображение в карточке установленных связей между сущностями.

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

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

4.2.2. Развитие компонента отчетности (3 очередь) Должна быть обеспечена автоматизация процессов формирования отчетов о ЧС и нештатных ситуациях на транспорте, в т.ч. на основе данных из внешних систем. Включает следующие доработки: – разработка шаблонов отчетов в различных форматах (табличный, текстовый); – реализация выбора фотоматериалов для включения в справку; – форматирование содержимого справок с учетом правил русского языка в отношении окончаний слов (в зависимости от падежа, склонения, числа и рода); – автоматизированное формирование выводов к содержимому справки на основе настраиваемых критериев; – создание интерфейса выбора параметров (фильтрации) для формирования отчетов: o состав полей для включения в отчёт; o настройка диапазонов значений характеристик и дат; o порядок отображения полей; o настройка заголовка. – реализация способа подготовки отчётов в асинхронном режиме (очереди); – реализация интерфейса компонента формирования отчетности для отображения очереди формирования отчетов и статусов их подготовки; – экспорт отчётов в форматы xlsx, csv и справок в форматы pdf, docx. Необходимо разработать не менее 10 шаблонов отчетов и/или справок. Перечень, структура и содержание шаблонов должны быть согласованы с Заказчиком на этапе технического проектирования.

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

– отображение на карте связанных сущностей и ОТИ; – реализация функции выбора темного и светлого стилей отображения элементов интерфейса, карточек сущностей, картографической основы и объектов, отображаемых на карте; – реализация механизма для выбора картографической основы в одном из распространенных форматов WMTS, TMS, MVT и др. Должна быть предусмотрена возможность настройки перечня картографических основ и параметров доступа к ним; – настройка базового набора дашбордов, содержащих преднастроенные виджеты о количестве событий в разрезе видов транспорта с возможностью перехода к исходным данным (карточкам событий, ОТИ и т.д.), с фильтрацией по параметрам. Параметры фильтрации должны быть определены на этапе технического проектирования. Должно быть обеспечено автоматическое и принудительное обновление данных, отображаемых на дашбордах

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

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

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

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

4.4. Требования к видам обеспечения 4.4.1. Требования к лингвистическому обеспечению Документация на Модуль СЦ должна разрабатываться на русском языке. Взаимодействие пользователей с Модулем СЦ посредством графического интерфейса должно происходить на русском языке за исключением сообщений, зависящих от настроек системного программного обеспечения, установленного на рабочих местах пользователей. При разработке программных решений Модуля СЦ должно быть предусмотрено использование языков программирования высокого уровня, приведенных в Таблице 7. Таблица 7. Языки и средства разработки, специального программного обеспечения Модуля СЦ Категория Наименование Назначение Языки программирования Kotlin Разработка серверной логики и сервисов (backend) JavaScript / TypeScript Разработка клиентской части (frontend) Python Разработка скриптов интеграции, обработки данных и автоматизации Фреймворки и библиотеки Vue.JS Разработка пользовательских интерфейсов (веб-интерфейсы компонентов визуализации и отчетности) React Разработка пользовательских интерфейсов (при необходимости создания сложных интерактивных компонентов) Решения по лингвистическому обеспечению, включая перечень используемых языков программирования, должны быть согласованы с Заказчиком на этапе технического проектирования

4.4.2. Требования к математическому обеспечению Требования к математическому обеспечению не предъявляются. 4.4.3. Требования к метрологическому обеспечению Требования к метрологическому обеспечению не предъявляются. 4.4.4. Требования к организационному обеспечению Требования к организационному обеспечению не предъявляются. 4.4.5. Требования к методическому обеспечению Задачи методического обеспечения Модуля СЦ должны быть обеспечены за счет использования технологических и методических документов касающихся вопросов функционирования транспортного комплекса и разработки и эксплуатации ПО. 4.4.6. Требования к информационному обеспечению Состав, структура и способы организации информационного обеспечения в Модуле СЦ должны быть определены на этапе технического проектирования. Факты информационного обмена с внешними системами должны фиксироваться в соответствующем журнале

4.5.5. Требования к информационной безопасности Работы по защите информации/информационной безопасности, не включенные в состав настоящего раздела, требуемые в соответствии с требованиями постановления Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации», а также нормативно правовых актов в области защиты персональных данных и обеспечения безопасности объектов критической информационной инфраструктуры, будут проведены в рамках исполнения отдельного контракта, заключенного по результатам отдельной закупочной процедуры (не является частью данного ТЗ), включающего: – определение актуальных угроз безопасности информации и актуализация модели угроз безопасности информации (при необходимости); – выполнение требований о согласовании технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России в установленном порядке; – выполнение требований по устранению Подрядчиком замечаний и недостатков, в случае их выявления при согласовании Заказчиком технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России; – выполнение требований к классу защищенности ГИС, уровню защищенности персональных данных и категории значимости объекта КИИ РФ, установленных для Головного центра обработки данных ФГБУ «СИЦ Минтранса России» (далее – ГЦОД);

– определение перечня объектов защиты информационной системы; – описание (актуализированных) требований к системе защиты информации, а также к мерам защиты информации информационной системы в зависимости от установленных классов защищенности, уровня защищенности персональных данных и категории значимости объектов КИИ РФ (приказы ФСТЭК России № 21, 117, 239); – выполнение требований к мерам по защите ГИС от атак, направленных на отказ в обслуживании, в соответствии с пунктами 30, 34, 59, 63 Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений, утвержденных приказом ФСТЭК России от 11.04.2025 № 117; – описание (актуализированных) требований по защите информации, подлежащих реализации в информационно телекоммуникационной инфраструктуре ГЦОД; – выполнение требований о применении сертифицированных средств защиты информации, включая их классы защиты и уровни доверия; – выполнение требований о запрете использования с 01.01.2025 органами (организациями) средств защиты информации странами происхождения, которых являются иностранные государства в соответствии с пунктом 6 Указа Президента Российской Федерации от 01.05.2022 № 250; – выполнение требований по обеспечению непрерывного взаимодействия с ГосСОПКА в установленном порядке;

4.5.11. Требования к показателям назначения 4.5.11.1. Требования к показателям назначения мероприятий по развитию Модуля СЦ В рамках выполнения работ по развитию Модуля СЦ, предусмотренных ТЗ, показатель назначения «Количество пользователей» должен соответствовать значениям, приведенным в данном разделе. Пояснения по показателям, связанным с количеством пользователей, приведены в Таблице 8. Таблица 8. Определения показателей, связанных с количеством пользователей в Модуле СЦ № Показатель Определение Расчетное количество пользователей Количество пользователей, работу которых должен обеспечить Модуль СЦ к моменту сдачи работ по Контракту с учетом достижения всех показателей назначения Расчетное количество одновременно работающих пользователей Количество одновременно работающих пользователей, работу которых должен обеспечивать Модуль СЦ к моменту сдачи работ по Контракту с учетом достижения всех показателей назначения Значения показателей количества пользователей, достижение которых необходимо обеспечить, представлено в Таблице 9

Таблица 9. Значения показателей количества пользователей № Показатель Значение 1. Расчетное количество пользователей 1 000 2. Расчетное среднее количество одновременно работающих пользователей 200 Развитие Модуля СЦ должно быть направлено на достижение следующего эффекта (показателя), подставленного в мероприятии 103.002 «Информационно-аналитическая система регулирования на транспорте (АСУ ТК)» ВПЦТ Минтранса России: Выполнение работ по развитию Модуля СЦ предусмотрено мероприятием по развитию АСУ ТК, приведенном в ВПЦТ Минтранса России на 2026-2028 гг: № 103.002 «АСУ ТК» в составе ИТ расхода 103.26.000005 «Развитие предусматривает реализацию ОКР и эффектов, приведенных в Таблице 10. Таблица 10. ОКР и эффекты, приведенные в ВПЦТ Минтранса России на 2026 г. № ОКР Дата ОКР Эффекты 1 Обеспечено информационное взаимодействие с Минобороны России о происшествиях на транспортных объектах 25.12.2026 Сокращено время сбора и передачи сведений для Минобороны России о ЧС и НС на транспорте с 120 до 10 минут 2 Обеспечена автоматизация формирования отчетов о нештатных ситуациях на транспорте, в том числе по данным внешних систем 25.12.2026 Сокращено время на подготовку отчетов о нештатных ситуациях на транспорте с 20 до 5 минут Реализация остальных ОКР не является предметом данного ТЗ и проводится в рамках отдельного технического задания.

4.5.11.2. Требования к показателям назначения мероприятий по эксплуатации Модуля СЦ. Работы по эксплуатации Модуля СЦ не должны обеспечивать режимы функционирования Модуля СЦ, приведенные в разделе 4.5.2 данного ТЗ

4.3.4. Требования к документированию результатов оказываемых услуг Для обеспечения контроля оказываемых услуг по поддержке Модуля СЦ со стороны Заказчика, по окончании каждого отчетного периода по контракту в соответствии с календарным планом, Подрядчик обязан предоставить Заказчику Отчет об оказанных услугах. Отчет должен содержать детальную информацию об оказанных услугах с указанием даты выполненных мероприятий и приложением обосновывающих документов (заявок, запросов, требований) или ссылкой на такие документы, если они содержатся в Модуле СЦ. Информация о выполненных мероприятиях по заявкам должна быть сформирована на основании соответствующих записей СРО по каждому этапу исполнения Контракта. В случае оказания услуги адаптационного, конфигурационного и коррекционного сопровождения Модуля СЦ, должны быть предоставлены документы, подтверждающие выполнение требований п. 29.3 приказа ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации». Фактическое время реагирования и время решения по всем обращениям, поступившим в СРО, формируется в СРО по итогам отчетного периода в разделе «Отчеты». Фактическое время реагирования и время решения по обращениям учитывает суммарное время, затраченное на реагирование и, соответственно, на работу по обращению с момента назначения обращения специалисту Подрядчика или группе исполнителей, ответственным за оказание услуг технической поддержки 3 уровня от начала до завершения работ Подрядчиком. При этом принимается суммарное время нахождения заявки в соответствующих статусах заявки СРО на стороне Подрядчика

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

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

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

4.4.7.1. Требования к инструментам разработки и процессу контроля версий программного обеспечения 4.4.7.1.1. Система контроля версий Для управления исходным кодом должна использоваться система контроля версий кода, развернутая в инфраструктуре Заказчика. 4.4.7.1.2. Правила именования веток Имя ветки должно соответствовать следующему формату: / / Категории веток: ? feature/ — разработка новой функциональности, а также рефакторинг или удаление существующей; ? fix/ — исправление ошибок; ? hotfix/ — срочные исправления, применяемые в обход стандартного процесса разработки; ? test/ — для проведения экспериментов, не влияющих на основную разработку. Идентификатор задачи: после категории указывается ссылка на задачу (issue) в системе контроля версий кода. Описание: добавляется краткое описание решаемой задачи в формате kebab-case (слова разделяются дефисами, например, add-user-auth). Примеры именования веток: ? feature/#123/add-payment-integration; ? fix/#45/correct-calculation-logic; ? hotfix/#67/urgent-database-connection-patch. 4.4.7.1.3. Правила именования коммитов Сообщение коммита должно соответствовать соглашению Conventional Commits и состоять из категории и описания: : ? fix — исправление ошибки. Примеры сообщений коммитов: ? feat: добавление формы регистрации пользователя; ? fix: исправление ошибки валидации email-адреса; ? refactor: оптимизация алгоритма сортировки данных; ? chore: обновление версий в файле dependencies. 4.4.7.1.4. Модель ветвления В процессе разработки используются следующие основные ветви: ? main / master — стабильная ветка, содержит только код, прошедший полное тестирование и развернутый в продуктивных контурах; ? dev — ветка для интеграции завершенных задач, предназначенная для сборки и тестирования в тестовых средах. Попадание кода в main осуществляется только через Merge Request (MR) из dev

– выполнение требований по обеспечению в автоматизированном режиме с Национальной системой противодействия DDoS-атакам (НСПА) Центра мониторинга и управления сетью связи общего пользования ФГУП «ГРЧЦ» в рамках реализации мер по защите ГИС от атак, направленных на отказ в обслуживании; – детализированные требования к составу и содержанию работ по аттестации, а также к их результатам в соответствии с пунктами 13, 15 и 16 требований приказа ФСТЭК России от 29.04.2021 № 77 «Об утверждении Порядка организации и проведения работ по аттестации объектов информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну»

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

Подрядчик должен обеспечить реализацию и проведение внутренних проверок мер по разработке безопасного ПО, приведенных в Руководстве. Подрядчик должен провести анализ угроз безопасности информации программного обеспечения в соответствии с ГОСТ 58412-2019 «Защита информации. Разработка безопасного программного обеспечения. Угрозы безопасности информации при разработке программного обеспечения». Подрядчик должен провести испытания по выявлению уязвимостей в программном обеспечении Системы: · проведение статического анализа исходного кода программы; · проведение динамического анализа исходного кода программы; · проведение композитного анализа исходного кода и образов программы; · проведение фаззинг-тестирования программы, направленного на выявление в ней уязвимостей. Испытания по выявлению уязвимостей в программном обеспечении Системы должны быть проведены в рамках: · предварительных испытаний; · опытной эксплуатации; · приемочных испытаний

5. СОСТАВ И СОДЕРЖАНИЕ РАБОТ ПО РАЗВИТИЮ И ТЕХНИЧЕСКОЙ ПОДДЕРЖКЕ МОДУЛЯ СЦ (КАЛЕНДАРНЫЙ ПЛАН) - 5 Разработка программного обеспечения (3 очередь, пп. 4.2.2, 4.2.5 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ; – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 3 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 3 очереди; – Руководство по резервному копированию; – Описание ролевой модели; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 09.10.2026 - - Значение характеристики не может изменяться участником закупки

6 Опытная эксплуатация (1 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акт о завершении опытной эксплуатации 1 очереди; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке 17.09.2026 Окончание: не позднее 26.10.2026

7 Опытная эксплуатация (2 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акт о завершении опытной эксплуатации 2 очереди; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке 26.09.2026 Окончание: не позднее 26.10.2026

8 Опытная эксплуатация (3 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Акт о завершении опытной эксплуатации 3 очереди; – Документ о приемке Начало: с 10.10.2026 Окончание: не позднее 26.10.2026

9 Приемочные испытания Сопроводительным письмом предоставляются Заказчику: – Программа и методика приёмочных испытаний; – Протокол приемочных испытаний; – Исходные коды и дистрибутивы на электронном носителе (при условии внесения изменений, с учетом доработок по результатам опытной эксплуатации и проведенных испытаний); – Комплект рабочей документации на Модуль СЦ (при условии внесения изменений, с учетом доработок по результатам опытной эксплуатации и проведенных испытаний); – Акт приемки Системы в эксплуатацию; – Акт приемки-передачи исключительных прав на объект; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке; – Документы в соответствии с разделом 4.5.9 ТЗ; – Обеспечение гарантийных обязательств Начало: с 27.10.2026 Окончание: не позднее 10.11.2026

10 Услуги по технической поддержке Модуля СЦ (с 11.09.2026 по 15.12.2026) По окончании оказания Услуг сопроводительным письмом предоставляются Заказчику: – Отчет об оказанных Услугах по технической поддержке; – Актуальные на дату окончания оказания Услуг по данному этапу исходные коды прикладного ПО на электронном носителе (в случае внесения изменений); – Инструкция по сборке и развертыванию (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство пользователя (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство администратора (в случае внесения изменений); – Документ о приемке Начало: с 11.09.2026 Окончание: не позднее 15.12.2026

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

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

1 Техническое проектирование Сопроводительным письмом предоставляются Заказчику: · Технический проект, включая следующие документы: – Ведомость технического проекта; – Ведомость машинных носителей информации – Пояснительная записка; – Описание информационного обеспечения системы; – Описание автоматизируемых функций; – Схема функциональной структуры; – Описание организации информационной базы; – Описание программного обеспечения; · Макеты экранных форм компонента «Интерактивная карта»; · Руководство по безопасной разработке программного обеспечения; · Документ о приемке Начало: с даты заключения контракта Окончание: не позднее 31.07.2026

2 Услуги по технической поддержке Модуля СЦ (с даты заключения контракта по 10.09.2026) По окончании оказания Услуг сопроводительным письмом предоставляются Заказчику: – Отчет об оказанных Услугах по технической поддержке; – Актуальные на дату окончания оказания Услуг по данному этапу исходные коды прикладного ПО на электронном носителе (в случае внесения изменений); – Инструкция по сборке и развертыванию (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство пользователя (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство администратора (в случае внесения изменений); – Документ о приемке Начало: с даты заключения контракта Окончание: не позднее 10.09.2026

3 Разработка программного обеспечения (1 очередь, пп. 4.2.1, 4.2.6 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ; – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 1 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 1 очереди; – Руководство по резервному копированию; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 16.09.2026

4 Разработка программного обеспечения (2 очередь, пп. 4.2.3, 4.2.4 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ. – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 2 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 2 очереди; – Руководство по резервному копированию; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 25.09.2026

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

6.1. Сведения о гарантийном обслуживании Модуля СЦ Под гарантией понимается устранение Подрядчиком своими силами и за свой счет допущенных по его вине недостатков, выявленных после приемки выполненных Работ, как в работе самой Модуля СЦ, так и недостатков в отчетной документации. Если в период гарантийного срока обнаружатся недостатки, то Подрядчик обязан устранить их за свой счет, в сроки, установленные Заказчиком. Гарантийный срок в этом случае продлевается на период устранения недостатков. Срок гарантии: 1 год с даты приемки Заказчиком результатов исполнения Этапа № 9 контракта. Подрядчиком должны быть внесены соответствующие исправления в техническую и рабочую документацию (указанную в пунктах 5 и 6 настоящего ТЗ), связанные с устранением замечаний к работе Модуля СЦ или в случае выявления Заказчиком недостатков в такой документации в период гарантийного срока. Внесение изменений в документацию технического и рабочего проектирования осуществляется в соответствии с ГОСТ 2.503-2023 и ГОСТ Р 2.504-2021.

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

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

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

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

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

9. ТРЕБОВАНИЯ К ДОКУМЕНТИРОВАНИЮ - 9.1. Общие требования Документация на Модуль СЦ должна быть разработана в составе, указанном в разделах 5-8 данного ТЗ, и должна удовлетворять требованиям комплекса стандартов и руководящих документов на автоматизированные системы: – ГОСТ Р 2.105-2019 в части оформления текстовых документов; – ГОСТ 34.201-2020 в части наименования и обозначения документов. Документация на Модуль СЦ должны оформляться на листах формата А4. Допускается для размещения рисунков и таблиц использование листов формата А3 с подшивкой по короткой стороне листа. Документы объемом более 25 (двадцати пяти) листов должны содержать информационную часть, состоящую из аннотации и содержания. Исходные коды должны быть представлены в 1 (одном) экземпляре на электронном носителе, отчетные материалы должны быть представлены в 2 (двух) экземплярах на бумажном носителе (по одному экземпляру для Заказчика и Подрядчика) и в 1 (одном) экземпляре на электронном носителе в формате документов DOCX и PDF. При разработке документов на Модуль СЦ допускается отклонение от требований комплекса стандартов, описанных выше. Документам на Модуль СЦ должны в обязательном порядке присваиваться уникальные децимальные номера в соответствии с порядком, установленном в ГОСТ 34.201-2020. Документ «Программа и методика предварительных испытаний» должен включать приложения с формой протокола предварительных испытаний и формой акта приемки в опытную эксплуатацию. Документ «Программа опытной эксплуатации» должен включать приложение с формой журнала опытной эксплуатации. Документ «Программа и методика приемочных испытаний» должен включать приложения с формой протокола приемочных испытаний и формой акта приемки в эксплуатацию - - Значение характеристики не может изменяться участником закупки

10. ИСТОЧНИКИ РАЗРАБОТКИ - 10.1. Список литературы Специальная литература для разработки ТЗ не использовалась. 10.2. Нормативно-методические документы Список используемых нормативно-методических документов представлен в разделе 1.6 технического задания. ? Приложение А Эскизы визуального оформления компонента «Интерактивная карта» - - Значение характеристики не может изменяться участником закупки

Приложение Б Параметры оказания услуг - По устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности 1 Критический не более 30 минут не более 24 часов - критические уязвимости, влияющие на возможную полную недоступность ППО, ключевых функций Системы, ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО без возможности восстановления работоспособности Системы. - Критический уровень CVSS > 8.0 2 Высокий не более 1 часа не более 84 часов - критические уязвимости, влияющие на ошибки и сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО. - Высокий уровень CVSS 5.0 - 8.0 3 Средний не более 4 часов не более 120 часов - уязвимости, влияющие на невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым - Средний уровень CVSS 2.0 - 4.9 4 Низкий не более 8 часов не более 160 часов - уязвимости, влияющие на отклонение в работе ППО, не влияющее на корректную работу функций; - другие сбои и ошибки, затрагивающие основные функции ППО - Низкий уровень CVSS < 2.0 - - Значение характеристики не может изменяться участником закупки

Взаимодействие Заказчика и Подрядчика в части регистрации и контроля времени реагирования и решения обращения (заявки) осуществляется через СРО. Заказчик предоставляет Подрядчику доступ к СРО после заключения Контракта. Поступившие от разных пользователей заявки по поводу однотипных инцидентов или имеющие общую причину должны объединяться в одну заявку. Срок выполнения включает время диагностики инцидента, в ходе которого определяется причина инцидента (проблемы) и способ его устранения. Подрядчик должен обеспечить функционирование Модуля СЦ в соответствии с требованиями и параметрами, указанными в настоящем ТЗ и Регламенте оказании услуг. Основные параметры быстродействия типовых операций в Модуле СЦ указаны в таблице ниже (таблица Б.2.2). Таблица Б.2.2 - Параметры быстродействия Модуля СЦ № п/п Наименование параметра Значение (секунд) 1 Среднее время получения сообщения из очереди сообщений 10 2 Среднее время получения ответа от Системы 5 3 Среднее время открытия карточки реестра 5

Б.1. Базовые параметры оказания Услуг Базовые параметры оказания Услуг приведены ниже: – режимы оказания Услуг (таблица Б.1.1); – сроки предоставления отчетности (таблица Б.1.2). Таблица Б.1.1 - Режимы оказания Услуг № п/п Параметр Значение

1 Режим работы Системы Круглосуточно (24х7) 2 Режим доступности информационно-консультационной поддержки пользователей Системы 2.1 Прием и регистрация обращений (заявок) в СРО Регистрация обращений (заявок) производится круглосуточно в режиме 24х7, без праздников и выходных дней. Обработка заявок первой линией поддержки осуществляется в рабочие дни с 9 до 18 часов 2.2 Консультирование сотрудников Заказчика и пользователей Системы в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 3 Режим доступности по решению инцидентов, связанных с работой ППО: 3.1 - приоритет «Критический» Круглосуточно (24х7) 3.2 - приоритет «Высокий» Круглосуточно (24х7) 3.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 3.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4 Режим доступности услуг по адаптации, конфигурации и коррекционному сопровождению Системы 4.1 - приоритет «Критический» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.2 - приоритет «Высокий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 5 Режим доступности по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности 5.1 - приоритет «Критический» Круглосуточно (24х7) 5.2 - приоритет «Высокий» Круглосуточно (24х7) 5.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 5.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням)

Таблица Б.1.2. Сроки предоставления отчетности, с момента получения запроса № п/п Параметр Значение 1 Предоставление отчета об оказанных услугах за произвольный период 10 рабочих дней 2 Предоставление подробной информации по инциденту с приоритетом «Критический» 16 рабочих часов 3 Предоставление актуализированной документации 10 рабочих дней

Б.2. Приоритеты и регламентные сроки решения обращений (заявок) В зависимости от уровня сбоя в работе Системы обращению (заявке) присваивается один из следующих приоритетов, а также в зависимости от приоритета обращения (заявки) устанавливаются следующие контрольные сроки решения в соответствии с таблицей ниже (Таблица Б.2.1). Таблица Б.2.1 – Приоритеты и регламентные сроки решения обращений (заявок) № п/п Приоритет Максимальное время реагирования Время решения (срок выполнения) Описание приоритета По информационно-консультационной поддержке сотрудников Заказчика и пользователей Системы 1 - не более 1 часа не более 10 часов - По решению инцидентов, связанных с работой ППО: 1 Критический не более 30 минут не более 4 часов - полная недоступность ППО; - недоступность ключевых функций - ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО; - невозможность информационного обмена с ППО для ИС более 4 часов 2 Высокий не более 1 часа не более 8 часов - ошибки/сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; - снижение быстродействия СПО (время отклика ППО на операции превышает 30 секунд); - недоступность управления правами и ролями пользователей 3 Средний не более 4 часов не более 24 часов - невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым -недоступность функции формирования отчетов 4 Низкий не более 8 часов не более 40 часов - отклонение в работе ППО, не влияющее на корректную работу функций; - другие сбои и ошибки, затрагивающие основные функции ППО

По адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) 1 Критический не более 40 минут не более 8 часов - изменения, необходимые при проведении аварийно-восстановительных работ для возобновления работоспособности Системы; - изменения, связанные с критичными ошибками, блокирующими возможность оказания государственных услуг и/или чтение и внесение данных в Систему 2 Высокий не более 1 часа не более 40 часов - изменения, относящиеся к обеспечению работоспособности основной функциональности Системы, устраняют выявленные дефекты в работе Системы, оказывающие существенное влияние на работу пользователей в Системе; - изменения, затрагивающие три и более подсистемы/модуля Системы для адаптации 3 Средний не более 4 часов не более 72 часов - изменения, связанные с развитием/улучшением/оптимизацией Системы и выводом новой функциональности в штатном режиме для одного-двух модулей/подсистем; - изменения, связанные с развитием интеграционных механизмов Системы, например обновление существующих и/или реализация новых видов сведений СМЭВ, обновление существующих и/или реализация новых API, адаптация и/или изменение механизмов импорта и экспорта данных Системы и т.д. 4 Низкий не более 8 часов не более 160 часов - изменения, связанные с ошибками/корректировкой/изменением в отображении информации в пользовательском графическом интерфейсе Системы (графика, текст, органы управления, элементы интерфейса)

Приложение В Регламент оказания услуг - Приложение Д Форма Протокола проверки результатов организационно-штатных и подготовительных мероприятий (шаблон) Протокол проверки результатов организационно-штатных и подготовительных мероприятий Настоящий Протокол содержит результаты проверки организационно-штатных и подготовительных мероприятий, проведенных Исполнителем (Таблица Д.1). Таблица Д.1. Протокол проверки результатов № Мероприятия Подготовительного этапа Результат проверки 1. Определить и направить Заказчику документ «Ответственные за взаимодействия в рамках выполнения работ по техническому сопровождению Системы со стороны Исполнителя». Документ содержит контактную информацию (ФИО, должность, адрес электронной рабочей почты, номер телефона) не менее чем о 2 лицах, ответственных за оказание услуг со стороны Подрядчика Выполнено/Не выполнено 2. Обеспечить подключение специалистов Подрядчика к Системе Выполнено/Не выполнено 3. Обеспечить подключение специалистов Подрядчика к СРО Выполнено/Не выполнено Заказчик Подрядчик /Должность/ /Должность/ ____________________ /Ф.И.О/ ___________________ /Ф.И.О/ М.П. М.П. «_____»_______________________202_г. «_____»_______________________202_г - - Значение характеристики не может изменяться участником закупки

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

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

Уровень технической поддержки Организационно-структурная часть технической поддержки, имеющая определённые организационно-нормативными документами зоны ответственности, обязанности, а также временные нормативы, в течение которых эти обязательства должны выполняться либо эскалироваться на следующий уровень технической поддержки Услуги Услуги по технической поддержке Информационно-аналитической системы регулирования на транспорте АСУ ТК ФИО Фамилия, имя, отчество Эскалация Процедура повышения внимания к обращению (заявке) путем повышения его приоритета и/или передачи на следующий уровень технической поддержки, а также привлечение ролей, которые могут принимать решения без передачи на следующий уровень технической поддержки API Англ. Application Programming Interface — программный интерфейс приложения, интерфейс прикладного программирования — описание способов (набор классов, процедур, функций, структур или констант), которыми одна компьютерная программа может взаимодействовать с другой программой

CVSS Англ. Common Vulnerability Scoring System - открытый стандарт, используемый для расчета количественных оценок уязвимости в безопасности компьютерной системы, обычно с целью понять приоритет ее исправления. В современном инструментарии информационной безопасности используется версия 3.0 и выше с дополнительными метриками к базовым оценкам ID Англ. Identifier – идентификатор, уникальный признак объекта, позволяющий отличать его от других объектов, то есть, идентифицировать SLA Англ. Service Level Agreement - утвержденные условия по обработке обращения (заявки) с установленными метриками времени, которые определяют пороговые значения для эскалации в зависимости от статуса обращения (заявки) (например, время реакции – время от регистрации до осуществления первичной обработки, время решения – время от регистрации обращения (заявки) до его решения и т.д.) SQL Англ. Structured Query Language — «язык структурированных запросов», — декларативный язык программирования, применяемый для создания, модификации и управления данными в реляционной базе данных, управляемой соответствующей СУБД

1 Общие сведения 1.1 Полное наименование Услуг Оказание услуг по технической поддержке Модуля СЦ АСУ ТК в 2026 году. 1.2 Предмет Регламента оказания услуг Требования Технического задания

2 Общие положения 2.1 Цель и задачи оказания услуг Целью технической поддержки Системы является обеспечение ее стабильного и безопасного функционирования и эксплуатации, предупреждение, выявление и устранение сбоев в работе Системы и минимизация их неблагоприятного влияния. Для достижения поставленной цели требуется решение следующих задач: 1. Обеспечение информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы. 2. Поддержание параметров функционирования ППО Системы, удовлетворяющих требованиям производственных процессов, включая их непрерывность. 3. Обеспечение бесперебойного функционирования ППО и своевременное устранение сбоев и аварийных ситуаций в Системе. 4. Своевременное устранение уязвимостей при выявлении таковых, в соответствии с требованиями к обеспечению информационной безопасности. 5. Адаптация, конфигурирование, коррекция программного обеспечения в соответствии с изменениями нормативно-правовой базы и запросами уполномоченных сотрудников органов государственной власти, включая выполнение процедур тестирования и участие в обновлениях ППО на стендах Заказчика. 6. Обеспечение сохранения работоспособности ППО в изменяемой среде эксплуатации. 7. Ведение документации по настоящему контракту и инициирование актуализации документации на Систему по результатам обработки запросов Заказчика и внесения соответствующих изменений в ППО

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

3.4.1 Инцидент На рисунке 2 представлена функциональная схема регистрации и сопровождения обращений (заявок) типа «Инцидент». Рисунок 2 - Функциональная схема регистрации и сопровождения обращений (заявок) типа «Инцидент» 3.4.2 Запрос на обслуживание На рисунке 3 представлена функциональная схема регистрации и сопровождения обращения (заявки) типа «ЗНО». Рисунок 3 - Функциональная схема регистрации и сопровождения обращения (заявки) типа «ЗНО» 3.4.3 Запрос на изменение На рисунке 4 представлена функциональная схема регистрации и сопровождения обращений (заявок) типа «ЗНИ». Рисунок 4 - Функциональная схема регистрации и сопровождения обращений (заявок) типа «ЗНИ»

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

4.3. Форма обращения (заявки) на оказание услуг по адаптационному конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) При подаче обращения (заявки) типа «ЗНИ» в СРО указывается (Таблица 7): Таблица 7 – Описание атрибутов формы обращения (заявки) на оказание услуг по адаптационному, конфигурационному и коррекционному сопровождению Системы Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 10) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 9) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 10) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 10) Категория обращения (заявки): запрос на изменение Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 7) Приоритет изменения Время, очередность решения обращения (заявки), ресурсы, привлекаемые для решения обращения (заявки), порядок/процедура действий при решении обращения (заявки) – поле СРО «Приоритет» (см. рисунок 7) Тип изменения Справочник, классифицирующий типовые запросы характерные для Системы – поле СРО «Предмет обращения» (см. рисунок 7) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 7) Текст запроса на оказание услуги по адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 7)

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

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

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

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

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

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

4 Формы обращений (заявок) на оказание услуг по технической поддержке Системы, заполняемые в СРО 4.1. Форма обращения (заявки) на оказание услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы При подаче обращения (заявки) типа «ЗНО» в СРО указывается (Таблица 5): Таблица 5 – Описание атрибутов формы обращения (заявки) на оказание услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 5) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 5) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 5) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 5) Категория обращения: информационно-консультационная поддержка Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 5) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 5) Текст запроса на оказание услуги по информационно-консультационной поддержке сотрудников Заказчика Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 5)

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

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

На рисунке 8 приведена форма обращения (заявки) типа «Инцидент» в СРО. Рисунок 8 - Форма обращения (заявки) типа «Инцидент» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуги по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности, заполненную в свободной форме

Приложение 1 к Регламенту Матрица ответственных за взаимодействия в рамках выполнения работ по техническому сопровождению Системы Таблица 1 – Ответственные за взаимодействия в рамках выполнения работ по техническому сопровождению Системы со стороны Исполнителя ФИО Должность Адрес электронной почты Телефон — — — Общий контакт

Приложение 2 к Регламенту Приоритеты и регламентные сроки решения обращений (заявок) Приоритеты и регламентные сроки решения обращений (заявок) приведены в таблице 1. Таблица 1 – Приоритеты и регламентные сроки решения обращений (заявок) № п/п Приоритет Максимальное время реагирования Время решения (срок выполнения) Описание приоритета

По информационно-консультационной поддержке сотрудников Заказчика и пользователей Системы 1 – не более 1 часа не более 10 часов –

Таблица 1 - Типы обращений (заявок) Тип обращения (заявки) Описание Запрос на обслуживание Подготовка SQL запроса к СУБД для решения прикладной задачи и д р. – запрос на любое действие, не являющееся запросом информации и несовершенный на основе происшествия, прямо или косвенно влияющего на работу Системы Консультация (входит в тип обращения (заявки) «Запрос на обслуживание») «Где взять / куда обратиться...?», «Как сделать / выполнить…», «Как это работает…?» - запрос, имеющий своей целью получение информационной поддержки Инцидент Разбор ошибок/сбоев и подготовка материалов (корректировочных релизов, инструкций) для Заказчика для устранения ошибок/сбоев, которые приводят к частичному и полному нарушению работоспособности всех или отдельных функций ППО. Подготовка изменения и материалов, необходимых для проведения аварийно-восстановительных работ для возобновления работоспособности Системы. ЗНИ Подготовка изменений, связанных с изменением, улучшением/оптимизацией Системы и выводом новой модифицированной функциональности в штатном режиме. Подготовка изменений, связанных с модификацией существующих и/или реализация новых интеграционных механизмов для получения/обработки данных внешних систем. Подготовка изменений графического интерфейса по требованиям Заказчика

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

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

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

4.2. Форма обращения (заявки) на оказание услуги по решению инцидентов, связанных с работой ППО При подаче обращения (заявки) типа «Инцидент» в СРО указывается (Таблица 6): Таблица 6 – Описание атрибутов формы обращения (заявки) на оказание услуги по решению инцидентов, связанных с работой ППО Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 6) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 6) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 6,) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 6) Категория обращения (заявки): инцидент Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 6) Приоритет изменения Время - одно из значений: Низкий, Средний, Высокий или Критический. Определяет, очередность решения обращения (заявки), ресурсы, привлекаемые для решения обращения (заявки), порядок/процедура действий при решении обращения (заявки) – поле СРО «Приоритет» (см. рисунок 6,)

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

На рисунке 6 приведена форма обращения (заявки) типа «Инцидент» в СРО. Рисунок 6 - Форма обращения (заявки) типа «Инцидент» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуги по решению инцидентов, связанных с работой ППО, заполненную в свободной форме

По решению инцидентов, связанных с работой ППО 1 Критический не более 30 минут не более 4 часов – полная недоступность ППО; – недоступность ключевых функций; – ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО; – невозможность информационного обмена с ППО для ИС более 4 часов 2 Высокий не более 1 часа не более 8 часов – ошибки/сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; – снижение быстродействия СПО (время отклика ППО на операции превышает 30 секунд); – невозможность управления правами и ролями пользователей 3 Средний не более 4 часов не более 24 часов – невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым недоступность функции формирования отчетов 4 Низкий не более 8 часов не более 40 часов – отклонение в работе ППО, не влияющее на корректную работу функций; – другие сбои и ошибки, затрагивающие основные функции ППО

По адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) 1 Критический не более 40 минут не более 8 часов – изменения необходимые при проведении аварийно-восстановительных работ для возобновления работоспособности Системы; – изменения, связанные с критичными ошибками, блокирующими возможность оказания государственных услуг и/или чтение и внесение данных в Систему 2 Высокий не более 1 часа не более 40 часов – изменения относящиеся к обеспечению работоспособности основной функциональности Системы, устраняют выявленные дефекты в работе Системы, оказывающие существенное влияние на процесс оказания государственных услуг и работу пользователей в Системе; – изменения, затрагивающие три и более подсистемы/модуля Системы для адаптации 3 Средний не более 4 часов не более 72 часов – изменения, связанные с развитием/улучшением/оптимизацией Системы и выводом новой функциональности в штатном режиме для одного-двух модулей/подсистем; – изменения, связанные с развитием интеграционных механизмов Системы, например, обновление существующих и/или реализация новых видов сведений СМЭВ, обновление существующих и/или реализация новых API, адаптация и/или изменение механизмов импорта и экспорта данных Системы и т.д. 4 Низкий не более 8 часов не более 160 часов – изменения, связанные с ошибками/ корректировкой/изменение в отображении информации в пользовательском графическом интерфейсе Системы (графика, текст, органы управления, элементы интерфейса)

По устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности 1 Критический не более 30 минут не более 24 часов – критические уязвимости, влияющие на возможную полную недоступность ППО, ключевых функций Системы, ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО без возможности восстановления работоспособности Системы; – Критический уровень CVSS > 8.0 2 Высокий не более 1 часа не более 84 часов – критические уязвимости, влияющие на ошибки и сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; – Высокий уровень CVSS 5.0 - 8.0 3 Средний не более 4 часов не более 120 часов – уязвимости, влияющие на невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым; – Средний уровень CVSS 2.0 - 4.9 4 Низкий не более 8 часов не более 160 часов – уязвимости, влияющие на отклонение в работе ППО, не влияющее на корректную работу функций; – другие сбои и ошибки, затрагивающие основные функции ППО; – Низкий уровень CVSS < 2.0

Приложение Г Форма Отчета об оказанных услугах Отчет об оказанных услугах за этап «наименование этапа» в период с «__» _________ по «__» _________. № п/п Наименование услуги Общее количество Номер ОРС Краткое Описание Время реагирования по ТЗ Время реагирования фактическое Время решения по ТЗ Время решения фактическое Результат соблюдения времени реагирования Результат соблюдения времени решения Примечание 1 Услуги по информационно-консультационной поддержке работников Заказчика 2 546782 Консультация по работе Модуля СЦ 1 2 10 часов 11 часов Нет Нет 567123 Консультация по схеме БД 1 1 10 часов 1 час Да Да 2 … … Заказчик Подрядчик /Должность/ /Должность/ ____________________ /Ф.И.О/ ___________________ /Ф.И.О/ М.П. М.П. «_____»_______________________202_г. «_____»_______________________202_г

Приложение 1 к Отчету об оказанных услугах Журнал обращений (заявок) на оказание услуги по информационно-консультационной поддержке пользователей Системы (шаблон) Наименование Исполнителя в этапе «наименование этапа» в период с ________________ по _______________ оказал(о) Услугу по поддержке пользователей Системы в объеме, указанном в Таблице 1 Таблица 1 - Журнал обращений (заявок) пользователей Системы № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. ИТОГО зарегистрировано: Всего обращений (заявок): ________ ИТОГО решено: Всего обращений (заявок): ________

Приложение 2 к Отчету об оказанных услугах Журнал обращений (заявок) по решению инцидентов, связанных с работой ППО (шаблон) Наименование Исполнителя в этапе «наименование этапа» в период с ________________ по _______________ оказал(о) Услугу по решению инцидентов в объеме, указанном в Таблице 1. Таблица 1 - Журнал по решению инцидентов № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. ИТОГО зарегистрировано: Всего инцидентов: ________ ИТОГО решено: Всего инцидентов: ________

Приложение 3 к Отчету об оказанных услугах Журнал обращений (заявок) выполнения адаптационного, конфигурационного и коррекционного сопровождения Системы (шаблон) Журнал выполнения адаптации, конфигурации и коррекции Системы сформирован за этап «наименование этапа» в период с «__» _________ по «__» ____________ и представлен в таблице ниже (Таблица 1). Таблица 1 - Журнал выполнения адаптации, конфигурации и коррекции сопровождения Системы № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. Количество выполненных заявок за этап: ________

Приложение 4 к Отчету об оказанных услугах Журнал обращений (заявок) по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности (шаблон) Журнал обращений (заявок) по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности сформирован за этап «наименование этапа» в период с «__» _________ по «__» ____________ и представлен в таблице ниже (Таблица 1). Таблица 1 - Журнал выполнения заявок по устранению уязвимостей в ППО № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. Количество выполненных заявок за этап: ________

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

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

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

- 62.01.11.000 - Этап№5: Разработка программного обеспечения (3 очередь, пп. 4.2.2, 4.2.5 ТЗ), Предварительные испытания ОКПД2: 62.01.11.000 ОПРЕДЕЛЕНИЯ, ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ Автоматизированная система (АС) Система, состоящая из комплекса средств автоматизации, реализующего информационную технологию выполнения установленных функций, и персонала, обеспечивающего его функционирование (ГОСТ Р 59853-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения») АРМ Автоматизированное рабочее место АСУ ТК, Система Информационно-аналитическая система регулирования на транспорте АТС Автоматическая телефонная станция БД База данных ГИС Государственная информационная система ГОСТ Государственный стандарт ГЦОД СИЦ Минтранса России, ГЦОД Головной центр обработки данных ФГБУ «СИЦ Минтранса России» Дашборд Интерактивная аналитическая панель, графический интерфейс. ЕИС Единая информационная система в сфере закупок ЕСИА Единая система идентификации и аутентификации Заказчик Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» КИИ Критическая информационная инфраструктура Кластер Кла?стер (англ. cluster) – объединение нескольких однородных элементов, которое может рассматриваться как самостоятельная единица, обладающая определёнными свойствами Компонент Часть АС, выделенная по определенному признаку или совокупности признаков и рассматриваемая как единое целое (ГОСТ Р 59853-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения») Контракт Контракт на выполнение работ по развитию и оказанию услуг по технической поддержке Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК в 2026 году, заключаемый по результатам проведения конкурентной процедуры закупки в соответствии с требованиями Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» ... 1. ОБЩИЕ СВЕДЕНИЯ 1.1. Наименование Системы Полное наименование системы: Информационно-аналитическая система регулирования на транспорте. Условное обозначение системы: АСУ ТК. Полное наименование модуля: Модуль сбора, ведения и анализа информации о нештатных ситуациях на транспорте. Условное обозначение модуля: Модуль СЦ. Модуль СЦ создан в рамках контракта от 05.08.2024 № ОК/24_04 на выполнение работ по развитию АСУ ТК в части создания модуля «Сбора, ведения и анализа информации о нештатных ситуациях на транспорте». Развитие Модуля СЦ осуществлено в рамках контракта от 19.05.2025 № ОК/25_09 на выполнение работ по развитию Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК ... 2. ЦЕЛИ И НАЗНАЧЕНИЕ ВЫПОЛНЕНИЯ РАБОТ 2.2. Назначение и цели развития и технической поддержки Модуля СЦ Назначение Модуля СЦ: – оперативный мониторинг нештатных и чрезвычайных ситуаций на транспорте ; – оповещение заинтересованных лиц и структур о нештатных и чрезвычайных ситуациях; – сбор, обработка и хранение данных о нештатных и чрезвычайных ситуациях. Целями развития Модуля СЦ являются: – расширение состава данных об оперативной обстановке на транспорте; – оптимизация процесса сбора данных об оперативной обстановке на транспорте; – повышение информированности пользователей за счет визуализация данных Модуля СЦ; – автоматизация процесса формирования отчетов о ЧС и нештатной ситуации на транспорте; – обеспечение информационного взаимодействия с заинтересованными организациями по вопросам ведения. ... - Условная единица - 1,00 - 11 878 255,76 - 11 878 255,76

- Наименование характеристики Значение характеристики Единица измерения характеристики Инструкция по заполнению характеристик в заявке ОПРЕДЕЛЕНИЯ, ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ Автоматизированная система (АС) Система, состоящая из комплекса средств автоматизации, реализующего информационную технологию выполнения установленных функций, и персонала, обеспечивающего его функционирование (ГОСТ Р 59853-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения») АРМ Автоматизированное рабочее место АСУ ТК, Система Информационно-аналитическая система регулирования на транспорте АТС Автоматическая телефонная станция БД База данных ГИС Государственная информационная система ГОСТ Государственный стандарт ГЦОД СИЦ Минтранса России, ГЦОД Головной центр обработки данных ФГБУ «СИЦ Минтранса России» Дашборд Интерактивная аналитическая панель, графический интерфейс. ЕИС Единая информационная система в сфере закупок ЕСИА Единая система идентификации и аутентификации Заказчик Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» КИИ Критическая информационная инфраструктура Кластер Кла?стер (англ. cluster) – объединение нескольких однородных элементов, которое может рассматриваться как самостоятельная единица, обладающая определёнными свойствами Компонент Часть АС, выделенная по определенному признаку или совокупности признаков и рассматриваемая как единое целое (ГОСТ Р 59853-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения») Контракт Контракт на выполнение работ по развитию и оказанию услуг по технической поддержке Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК в 2026 году, заключаемый по результатам проведения конкурентной процедуры закупки в соответствии с требованиями Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» Значение характеристики не может изменяться участником закупки Модуль iМинтранс Модуль сбора данных и представления показателей деятельности Министерства транспорта Российской Федерации iМинтранс АСУ ТК Модуль СЦ Модуль сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК НС Нештатная ситуация НСИ Нормативно-справочная информация ОТИ Объект транспортной инфраструктуры П-ГИС Геоинформационная подсистема П-ИВ Подсистема информационного взаимодействия П-НСИ Подсистема ведения нормативно-справочной информации и метаданных ПО Программное обеспечение Подрядчик, Исполнитель Организация, с которой будет заключен контракт на выполнение работ по развитию Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК П-СД Подсистема сбора данных Работы Работы по развитию Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК СЗИ Средство защиты информации СМЭВ Система межведомственного электронного взаимодействия СУБД Система управления базами данных ТЗ Техническое задание (настоящий документ) ТС Транспортное средство ТК Транспортный комплекс Учреждение Учреждения в области информационной безопасности ФГБУ «СИЦ Минтранса России» Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации», Заказчик Федеральный закон № 44-ФЗ Федеральный закон от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» ФЗ Функциональная задача ФЗ «Реестр объектов» Функциональная задача «Формирование и ведение единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации» ФСБ России Федеральная служба безопасности Российской Федерации ФСТЭК России Федеральная служба по техническому и экспортному контролю ЧС Чрезвычайная ситуация ЭВМ Электронно-вычислительная машина API От англ. Application Programming Interface – интерфейс прикладного программирования – совокупность инструментов и функций в виде интерфейса для взаимодействия с программой CSS От англ. Cascading Style Sheets — каскадные таблицы стилей FPS От англ. frame per second - количество кадров в секунду HTML От англ. HyperText Markup Language - стандартный язык разметки документов, создающий основу и структуру всех веб-страниц JSON От англ. JavaScript Object Notation – текстовый формат обмена данными, основанный на JavaScript WebAssembly (Wasm) Открытый стандарт, представляющий собой низкоуровневый бинарный формат инструкций, который позволяет выполнять код, написанный на языках C++, Rust или Go, в браузерах с производительностью, близкой к нативной 1. ОБЩИЕ СВЕДЕНИЯ 1.1. Наименование Системы Полное наименование системы: Информационно-аналитическая система регулирования на транспорте. Условное обозначение системы: АСУ ТК. Полное наименование модуля: Модуль сбора, ведения и анализа информации о нештатных ситуациях на транспорте. Условное обозначение модуля: Модуль СЦ. Модуль СЦ создан в рамках контракта от 05.08.2024 № ОК/24_04 на выполнение работ по развитию АСУ ТК в части создания модуля «Сбора, ведения и анализа информации о нештатных ситуациях на транспорте». Развитие Модуля СЦ осуществлено в рамках контракта от 19.05.2025 № ОК/25_09 на выполнение работ по развитию Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК Значение характеристики не может изменяться участником закупки 1.2. Шифр темы или номер контракта Присваивается Заказчиком по результатам организации закупочных процедур. 1.2.1. Предмет контракта Выполнение работ по развитию Модуля СЦ. Код по ОКПД2: 62.01.11.000 – услуги по проектированию и разработке информационных технологий для прикладных задач и тестированию программного обеспечения. Оказание услуг по технической поддержке Модуля СЦ. Код по ОКПД2: 62.02.30.000 – услуги по технической поддержке информационных технологий. Выполнение работ по развитию Модуля СЦ предусмотрено с учетом ключевых результатов (ОКР) Ведомственной программы цифровой трансформации Минтранса России на 2026-2028 (далее - ВПЦТ Минтранса России) в составе мероприятия № 103.002 «АСУ ТК» ИТ расхода 103.26.000005 «Развитие Информационно-аналитической системы регулирования на транспорте (АСУ ТК)»: · «Обеспечено информационное взаимодействие с Минобороны о происшествиях на транспортных объектах»; · «Обеспечена автоматизация формирования отчетов о нештатных ситуациях на транспорте, в том числе по данным внешних систем». Выполнение работ по технической поддержке АСУ ТК предусмотрено ВПЦТ Минтранса России в составе мероприятия № 103.002 «АСУ ТК» ИТ расхода 103.26.000021 «Эксплуатация Информационно-аналитической системы регулирования на транспорте (АСУ ТК)» 1.3. Заказчик Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» (ФГБУ «СИЦ Минтранса России»). Адрес: 107078, Москва, Садовая-Спасская ул., д.18, стр. 1. Оператором Системы является Заказчик - Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» (ФГБУ «СИЦ Минтранса России) 1.4. Подрядчик Определяется по результатам проведения конкурентной процедуры закупки в соответствии с требованиями Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (далее – Федеральный закон № 44-ФЗ) 1.5. Основания для выполнения работ Работы осуществляются на основании следующих документов: – постановление Правительства Российской Федерации от 30.12.2003 № 794 «О единой государственной системе предупреждения и ликвидации чрезвычайных ситуаций»; – постановление Правительства Российской Федерации от 08.11.2013 № 1007 «О силах и средствах единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций»; – распоряжение Правительства Российской Федерации от 27.11.2021 № 3363-р «О Транспортной стратегии Российской Федерации до 2030 года с прогнозом на период до 2035 года»; – Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 26.08.2025 №ЕФ-3; – Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 27.11.2025 №ЕФ-23; – приказ Минкомсвязи России от 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 «Национальный стандарт Российской Федерации. Интеллектуальная собственность. Патентные исследования. Содержание и порядок проведения»; – Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 19.02.2026 №ЕФ-1; – План мероприятий по профилактике случаев непроизводственного травматизма граждан на железнодорожном транспорте, являющийся приложением к постановлению коллегии Министерства транспорта Российской Федерации от 11.03.2026 № 2 1.6. Перечень документов, требования которых должны быть учтены при выполнении работ – Федеральный закон Российской Федерации от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации»; – Федеральный закон Российской Федерации от 27.07.2006 № 152-ФЗ «О персональных данных»; – Федеральный закон Российской Федерации от 06.04.2011 № 63-ФЗ «Об электронной подписи»; – Федеральный закон Российской Федерации от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации»; – Указ Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации»; – Указ Президента Российской Федерации от 01.05.2022 № 250 «О дополнительных мерах по обеспечению информационной безопасности Российской Федерации»; – Указ Президента Российской Федерации от 31.03.2010 № 403 «О создании комплексной системы обеспечения безопасности населения на транспорте»; – постановление Правительства Российской Федерации от 30.07.2004 № 395 «Об утверждении Положения о Министерстве транспорта Российской Федерации»; – постановление Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации»; – постановление Правительства Российской Федерации от 16.11.2015 № 1236 «Об установлении запрета на допуск программного обеспечения, происходящего из иностранных государств, для целей осуществления закупок для обеспечения государственных и муниципальных нужд»; – постановление Правительства Российской Федерации от 23.12.2024 № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц»; – ГОСТ Р 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.7. Сроки начала и окончания работ Начало работ: с даты заключения Контракта. Окончание работ: не позднее 15.12.2026. Работы выполняются в соответствии с этапами. Сроки выполнения этапов работ по развитию и технической поддержке Модуля СЦ определяются Календарным планом. Календарный план, приведен в разделе 5 настоящего ТЗ – постановление Правительства Российской Федерации от 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 Федерального закона «Об электронной подписи»; – постановление Правительства Российской Федерации от 08.06.2011 № 451 «Об инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг и исполнения государственных и муниципальных функций в электронной форме»; – постановление Правительства Российской Федерации от 30.01.2013 № 62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин»; – приказ ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации»; – приказ ФСТЭК России от 11.04.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений»; – приказ ФСБ России от 18.03.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений, с использованием шифровальных (криптографических) средств»; – приказ ФСБ России от 10.07.2014 № 378 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных с использованием средств криптографической защиты информации, необходимых для выполнения установленных Правительством Российской Федерации требований к защите персональных данных»; 1.8. Общие сведения об источниках и порядке финансирования работ Источником финансирования являются средства субсидии федерального бюджета Российской Федерации, предоставленной в соответствии с абзацем вторым пункта 1 статьи 78.1 Бюджетного кодекса Российской Федерации (код цели 08-01) 1.9. Порядок оформления и предъявления результатов работ Подрядчик должен передать Заказчику результаты работ в порядке, определенном Контрактом в сроки, установленные п. 5 настоящего ТЗ, в соответствии с Календарным планом 1.10. Место выполнения Работ Работы выполняются удаленно на комплексе технических средств Заказчика. Адрес размещения комплекса технических средств Заказчика: Московская обл., Богородский район, пос. Горбуша, Радиоцентр. Техническая возможность удаленного подключения обеспечивается Заказчиком (в части предоставления параметров доступа). Оплата телематических и иных услуг, технических и программных средств, необходимых Подрядчику для удаленного подключения и для выполнения требований по информационной безопасности, осуществляется Подрядчиком самостоятельно за свой счет 2. ЦЕЛИ И НАЗНАЧЕНИЕ ВЫПОЛНЕНИЯ РАБОТ 2.2. Назначение и цели развития и технической поддержки Модуля СЦ Назначение Модуля СЦ: – оперативный мониторинг нештатных и чрезвычайных ситуаций на транспорте ; – оповещение заинтересованных лиц и структур о нештатных и чрезвычайных ситуациях; – сбор, обработка и хранение данных о нештатных и чрезвычайных ситуациях. Целями развития Модуля СЦ являются: – расширение состава данных об оперативной обстановке на транспорте; – оптимизация процесса сбора данных об оперативной обстановке на транспорте; – повышение информированности пользователей за счет визуализация данных Модуля СЦ; – автоматизация процесса формирования отчетов о ЧС и нештатной ситуации на транспорте; – обеспечение информационного взаимодействия с заинтересованными организациями по вопросам ведения. Значение характеристики не может изменяться участником закупки Целями оказания услуг по технической поддержке являются: – обеспечение информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы; – поддержание параметров функционирования ППО Системы, удовлетворяющих требованиям производственных процессов, включая их непрерывность; – обеспечение бесперебойного функционирования ППО и своевременное устранение сбоев и аварийных ситуаций в Системе; – своевременное устранение уязвимостей при выявлении таковых, в соответствии с требованиями к обеспечению информационной безопасности; – адаптация, конфигурирование, коррекция программного обеспечения в соответствии с изменениями нормативно-правовой базы и запросами уполномоченных сотрудников органов государственной власти, включая выполнение процедур тестирования и участие в обновлениях ППО на стендах Заказчика; – обеспечение сохранения работоспособности ППО в изменяемой среде эксплуатации; – ведение документации по настоящему ТЗ, инициирование и актуализация документации на Систему по результатам обработки запросов Заказчика и внесении соответствующих изменений в ППО. Модуль СЦ применяется в деятельности Министерства транспорта Российской Федерации, подведомственных агентств и службы и другими организациями в соответствии с соглашениями об информационном обмене 2.1. Назначение АСУ ТК АСУ ТК предназначена для автоматизации и информационно-аналитического обеспечения процессов управления развитием транспортного комплекса Российской Федерации, обеспечения публичности деятельности органов государственного управления транспортным комплексом. Основными целями АСУ ТК являются: – повышение эффективности процессов управления функционированием и развитием транспортного комплекса на основе создания единой информационной среды и комплекса информационно-аналитических услуг на уровне органов государственного управления ТК; – повышение уровня безопасности ТК на базе получения полной, достоверной и оперативной информации о происходящих изменениях, своевременного выявления негативных тенденций и для принятия соответствующих мер по их устранению и ликвидации последствий Основными задачами АСУ ТК являются: – автоматизация процессов прогнозирования развития транспортного комплекса и поддержки принятия управленческих решений; – автоматизация процессов мониторинга безопасности и устойчивости транспортного комплекса, управления в чрезвычайных и нештатных ситуациях; – автоматизация процессов управления программами и проектами развития и модернизации транспортного комплекса; – автоматизация процессов мониторинга состояния транспортного комплекса, в том числе с использованием набора ключевых показателей эффективности деятельности транспортного комплекса; – информационно-технологическая поддержка взаимодействия субъектов транспортного комплекса Российской Федерации, органов государственного управления и контроля, международных организаций на основе создания единой технологической среды взаимодействия и управления движением данных (и связанных с ними документов) в транспортном комплексе; – использование в процессах управления транспортным комплексом РФ современных технологий электронного документооборота и электронного обмена данными; – организация межведомственного электронного взаимодействия подразделений Министерства транспорта Российской Федерации, подведомственных агентств и службы с другими организациями 3. ХАРАКТЕРИСТИКА ОБЪЕКТА АВТОМАТИЗАЦИИ 3.3. Состав используемого ПО Модуля СЦ Программная архитектура Модуля СЦ разработана как трехуровневая клиент-серверная архитектура. Архитектура включает в себя следующие уровни: • уровень представления – презентационный уровень, обеспечивающий взаимодействие с пользователя с клиентскими приложениями с использованием веб-браузера («тонкий» клиент); • уровень приложений – реализован в виде сервисов, обеспечивает обработку запросов, поступающих от клиентских приложений, формирование ответов на запрос в доступном пользователю виде (формирование пользовательских интерфейсов); • уровень хранения данных – реализуется как сервер БД и обеспечивает хранение и целостность хранимых данных, создание резервных копий, ведение журнала транзакций, восстановление данных после сбоев. Программная архитектура Модуля СЦ включает в себя сервисы и интерфейсы, указанные в Таблице 3. Таблица 3. Программная архитектура Модуля СЦ Программный сервис/интерфейс Технологии реализации Уровень представления Интерфейс пользователя и администратора (front-end) Javascript Уровень приложений Сервис (GateWay) Kotlin Сервис геокодирования (geocoding-service) Kotlin Сервис уведомлений (notifiсation-service) Kotlin Сервис работы с файлами (file-service) Kotlin Сервис отчетности (report-service) Kotlin Сервис управления событиями (event-service) Kotlin Сервис информирования через мессенджер (messenger-notifier) Python Сервис внешних интеграций (integration-service) Сбор информации из внешних систем и сервисов Брокер сообщений Kafka Уровень хранения данных Файловое хранилище MinIO S3 СУБД Postgres Pro Enterprise Значение характеристики не может изменяться участником закупки 3.4. Информационное взаимодействие программных сервисов и интерфейсов Модуля СЦ Объект автоматизации функционирует в распределенной информационной среде. Обмен данными осуществляется по защищенным каналам связи (в том числе ведомственным сетям передачи данных). Источники информации включают: · внешние автоматизированные системы (органов государственной власти); · внутренние базы данных (реестры объектов транспортной инфраструктуры, паспорта регионов и пр.); · оперативная информация от персонала, поступающая через автоматизированные рабочие места (АРМ) и мобильные устройства. 3.4.1. Взаимодействие Модуля СЦ со смежными подсистемами АСУ ТК Модуль СЦ входит в состав АСУ ТК и взаимодействует со следующими ее функциональными задачами и подсистемами: · Функциональной задачей «Формирование и ведение единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации» (ФЗ «Реестр объектов»); · Геоинформационной подсистемой АСУ ТК (П-ГИС); · Подсистемой ведения нормативно-справочной информации и метаданных (П-НСИ); · Подсистемой сбора данных и централизованное хранилище данных (П-СД); · Подсистемой информационного взаимодействия (П-ИВ). 3.4.2. Взаимодействие с внешними информационными системами Список внешних информационных систем, с которыми осуществляется взаимодействие Модуля СЦ: · ЕСИА; · мессенджер; · Яндекс Геокодер; · Информационная система «Централизованная система сбора информации систем-112»; · ПВК «Поиск-Море», АИС РПТ; · облачная АТС 3.5. Требования к эксплуатации Применяемое в Системе программное обеспечение, программно-аппаратные и аппаратные комплексы должны соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации» 3.1. Описание объекта автоматизации АСУ ТК Объектом автоматизации являются процессы основной и обеспечивающей деятельности, направленные на управление транспортным комплексом, в том числе, процессы информационного взаимодействия с другими организациями и субъектами транспортного комплекса. АСУ ТК относится к государственным информационным системам, а также к информационным системам персональных данных и значимым объектам критической информационной инфраструктуры Российской Федерации. АСУ ТК соответствует требованиям, предъявляемым к: – ГИС второго класса защищенности в соответствии с приказом ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах»; – ИС персональных данных при обеспечении третьего уровня защищенности персональных данных в соответствии с требованиями постановления Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»; – значимым объектам КИИ Российской Федерации второй категории значимости с постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении Правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений». Модуль СЦ является подсистемой АСУ ТК. Перечень платформенных решений и функциональных задач АСУ ТК представлен в Таблице 1 Таблица 1 – Перечень платформенных решений и функциональных задач АСУ ТК № Наименование подсистемы/ функциональной задачи/ модуля Назначение 1 Подсистема сбора данных и централизованного хранилища данных Подсистема обеспечивает выполнение сбора данных в АСУ ТК, и в т. ч., в рамках функциональных задач «Формирование и ведение межрегионального транспортного баланса пассажирских перевозок в дальнем (межрегиональном) сообщении» и «Формирование и ведение транспортного паспорта региона» 2 Подсистема информационного взаимодействия Подсистема информационного предназначена для обеспечения информационного взаимодействия подсистем АСУ ТК, а также, взаимодействия АСУ ТК с АС федеральных органов исполнительной власти 3 Подсистема ведения нормативно-справочной информации и метаданных Подсистема предназначена для автоматизации функций формирования и актуализации справочников, классификаторов, реестров и регистров, необходимых для обеспечения информационной поддержки пользователей НСИ и интеграции подсистем АСУ ТК в части применения НСИ 4 Модуль СМЭВ Модуль взаимодействия со СМЭВ представляет собой набор сервисов взаимодействия: сервис синхронного взаимодействия и сервис отправки, осуществляющих дополнительную обработку сообщений, отправляемых в СМЭВ и принимаемых из СМЭВ 5 Геоинформационная подсистема Программное обеспечение геоинформационной подсистемы предназначено для обеспечения смежных подсистем АСУ ТК возможностью работы с картографической информацией, в том числе, отображения на электронных картах объектов транспортной инфраструктуры и получения информации о местоположении, характеристиках контролируемых транспортных объектов 6 Подсистема информационного портала АСУ ТК Подсистема информационного портала предназначена для отображения и входа в функциональные задачи АСУ ТК 7 Подсистема технического портала АСУ ТК Подсистема технического портала АСУ ТК предназначена для управления заявками пользователей и технологического документооборота заявок 8 Подсистема проектного архива АСУ ТК Подсистема проектного архива АСУ ТК предназначена для автоматизации деловых процессов должностных лиц Министерства транспорта Российской Федерации, подведомственных агентств и службы, в том числе, и процессов информационного взаимодействия внутреннего и внешнего характера 9 ФЗ «Реестр объектов» Функциональная задача предназначена для формирования и ведения единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации 10 ФЗ «СТП» Функциональная задача предназначена для организации информационно-аналитической поддержки процессов территориального планирования Российской Федерации в области федерального транспорта 11 ФЗ «МРТБ ПП» Функциональная задача предназначена для формирования и ведения межрегионального транспортного баланса пассажирских перевозок в дальнем (межрегиональном) сообщении 12 ФЗ «МДД» Функциональная задача предназначена для осуществления мониторинга дорожного движения 13 ФЗ «ТПР» Функциональная задача предназначена для формирования и ведения транспортного паспорта региона 14 ФЗ «Данные по грузообороту» Функциональная задача предназначена для обеспечения подсистем и пользователей АСУ ТК данными по грузообороту между Российской Федерацией и зарубежными странами 15 ФЗ «МЖТ» Функциональная задача предназначена для осуществления мониторинга железнодорожного транспорта 16 ФЗ «МГМП» Функциональная задача предназначена для осуществления мониторинга грузопотоков в морских портах с целью формирования единой цифровой среды мониторинга и планирования перевозок в/из портов Дальнего Востока 17 Модуль ГЭТ Модуль предназначен для получения, хранения данных инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по отдельно взятому предприятию-перевозчику. Формирования отчетов об инвентаризации с детальными данными по каждому разделу инвентаризации с маршрутизацией в муниципалитет / регион / Минтранс. Содержит агрегированные данные инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по всем перевозчикам, относящихся к данному муниципалитету. Формирует сводный отчет по муниципалитету по каждому разделу инвентаризации с маршрутизацией в регион / Минтранс. Формирует агрегированные данные инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по всем перевозчикам, относящиеся к данному региону и по всем муниципалитетам, относящимся к данному региону. Аналитические и статистические данные о состоянии ГЭТ региона. Содержит данные о видах транспорта, цифровых транспортных сервисах и платежных инструментах Региона. Формирует сводный отчет по каждому разделу инвентаризации с маршрутизацией в Минтранс. Формирует агрегированную статистику и аналитику по всем регионам страны в разрезе транспортных средств, маршрутов, пассажиропотоков, инфраструктуры ГЭТ. Данные о рейтинге регионов и перевозчиков на основании выбранных параметров, документооборот с участниками Системы: получение подписанных печатных форм, их утверждение, возврат на доработку. 18 Модуль iМинтранс Модуль создан для отчета по ключевым показателям транспортного комплекса России (Отраслевые и статистические показатели, исполнение бюджета, исполнение поручений, аналитика СМИ, происшествия по видам транспорта). 19 Модуль СЦ Модуль СЦ предназначен для оперативного мониторинга нештатных ситуаций транспортной отрасли, оповещения заинтересованных лиц и структур и предоставления данных о нештатных ситуациях АСУ ТК осуществляет идентификацию и авторизацию посредством Единой системы идентификации и аутентификации (ЕСИА). Информационный обмен с внешними информационными системами осуществляется посредством СМЭВ 3 и СМЭВ 4. АСУ ТК развернута на вычислительных мощностях ГЦОД СИЦ Минтранса России 3.2. Описание и текущее состояние объекта автоматизации Модуля СЦ Объектом автоматизации является процесс организации мониторинга информации о НС и ЧС на транспорте. Предметом деятельности Учреждения являются следующие функции: – информационное обеспечение в области транспортной безопасности, защиты населения и территорий от чрезвычайных ситуаций природного и техногенного характера в транспортном комплексе; – подготовка справочных материалов при угрозе возникновения и возникновении чрезвычайных ситуаций и иных происшествий в транспортном комплексе; – взаимодействие и обмен оперативной информацией с органами управления Единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций; – организация оперативного мониторинга обстановки на объектах транспорта при угрозе и возникновении чрезвычайных ситуаций и иных происшествий. Перечень компонентов Модуля СЦ и выполняемые ими функции представлены в Таблице 2 Таблица 2. Перечень компонентов Модуля СЦ и их функции № п/п Компонент Выполняемые функции 1 Регистрация событий – ведение карточки события; – удаление комментария; – динамическое отображение существующих событий в заданном радиусе и за заданный период; – возможность автоматической проверки вводимых данных в части количества пострадавших; – отображение карточки ОТИ, ТС в соответствии с ФЗ Реестр объектов; – сохранение и отображение версии карточки события; – привязка события к координатам по картографической основе; – указание признака выполнения действия по отработке события; – перевод статуса события; – закрытие карточки события; – публикация информации о событии в канале мессенджера; – возможность перехода из карточки события на картографическую основу для просмотра местоположения события 2 Визуализация – отображение событий на картографической основе в виде пиктограмм; – масштабирование карты; – отображение краткой карточки события при выборе события на картографической основе; – отображение списка событий; – отображение карточки события; – отображение журнала действий пользователя; – отображение дополнительной информации (текстовая информация и приложенные файлы); – отображение справки о событиях и отчета о событиях; – отображение фильтров и количества отфильтрованных объектов; – отображение результатов поиска; – отображение статистики по событиям на экране; – возможность создания события с картографической основы; – отображения картографических слоев в зависимости от примененных фильтров; – возможность настройки шага картографической сети; – возможность настройки географической точки центра карты; – отображение количества непрочитанных сообщений; – возможность перехода к детальной карточке события из краткой карточки события при выборе события на картографической основе 3 Информирование – ведение справочника способов оповещения (веб-интерфейс, мессенджер); – формирование сценария выполнения оповещения (настройка условий, способа, параметров оповещения); – выполнение оповещений пользователей 4 Отчетность – формирование отчета и справки о событиях; – фильтрация событий для выгрузки в справку о событиях или в отчет о событиях 5 Администрирование – ведение ролей пользователей; – ведение учетных данных пользователей; – ведение справочника организаций; – ведение справочника групп системы мгновенного обмена сообщениями; – выполнение исходящего звонка на контактный телефонный номер организации; – формирование матрицы эскалации событий Архитектура Модуля СЦ представлена на рисунке 1. Рисунок 1. Архитектура Модуля СЦ 4. ТРЕБОВАНИЯ К МОДУЛЮ СЦ 4.4.7.1. Требования к инструментам разработки и процессу контроля версий программного обеспечения 4.4.7.1.1. Система контроля версий Для управления исходным кодом должна использоваться система контроля версий кода, развернутая в инфраструктуре Заказчика. 4.4.7.1.2. Правила именования веток Имя ветки должно соответствовать следующему формату: / / Категории веток: ? feature/ — разработка новой функциональности, а также рефакторинг или удаление существующей; ? fix/ — исправление ошибок; ? hotfix/ — срочные исправления, применяемые в обход стандартного процесса разработки; ? test/ — для проведения экспериментов, не влияющих на основную разработку. Идентификатор задачи: после категории указывается ссылка на задачу (issue) в системе контроля версий кода. Описание: добавляется краткое описание решаемой задачи в формате kebab-case (слова разделяются дефисами, например, add-user-auth). Примеры именования веток: ? feature/#123/add-payment-integration; ? fix/#45/correct-calculation-logic; ? hotfix/#67/urgent-database-connection-patch. 4.4.7.1.3. Правила именования коммитов Сообщение коммита должно соответствовать соглашению Conventional Commits и состоять из категории и описания: : ? fix — исправление ошибки. Примеры сообщений коммитов: ? feat: добавление формы регистрации пользователя; ? fix: исправление ошибки валидации email-адреса; ? refactor: оптимизация алгоритма сортировки данных; ? chore: обновление версий в файле dependencies. 4.4.7.1.4. Модель ветвления В процессе разработки используются следующие основные ветви: ? main / master — стабильная ветка, содержит только код, прошедший полное тестирование и развернутый в продуктивных контурах; ? dev — ветка для интеграции завершенных задач, предназначенная для сборки и тестирования в тестовых средах. Попадание кода в main осуществляется только через Merge Request (MR) из dev Значение характеристики не может изменяться участником закупки 4.4.7.1.5. Требования к используемым зависимостям (библиотекам) Все внешние зависимости проекта должны быть зафиксированы с указанием точных версий. Для контроля версий зависимостей в репозиторий обязательно должны быть включены следующие файлы: · Для JavaScript: package-lock.json или yarn.lock; · Для Python: requirements.txt (с зафиксированными версиями) или Pipfile.lock; · Для Go: go.mod и go.sum; Загрузка всех зависимостей должна производиться исключительно через внутренний прокси-репозиторий Заказчика, настроенный в соответствующем системе менеджере пакетов. Запрещается: · Использование плавающих версий (например, ^1.2.3, ~4.5.0, latest); · Использование библиотек, содержащих критические уязвимости, в том числе зарегистрированные в реестре CVE (Common Vulnerabilities and Exposures). 4.4.7.1.6. Требования к процессу непрерывной интеграции (CI) Сборка программного обеспечения, включая этапы компиляции, тестирования и анализа кода, должна выполняться исключительно в инфраструктуре непрерывной интеграции Заказчика. 4.4.7.1.7. Требования к хранению артефактов сборки Все артефакты сборки (результирующие пакеты, Docker-образы и т.д.) подлежат обязательному хранению в предназначенной для этого инфраструктуре Заказчика (артефакторий). Запрещается размещение финальных артефактов сборки на сторонних ресурсах 4.5.5.1. Требования к безопасности исходного кода Процесс разработки исходного кода должен соответствовать требованиям законодательства, нормативным правовым актам Российской Федерации, приказу ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по безопасности значимых объектов критической информационной инфраструктуры Российской Федерации», а также учитывать отраслевые практики безопасной разработки. Подрядчик должен предоставить Заказчику Руководство по безопасной разработке программного обеспечения (далее – Руководство), применяемое при разработке исходного кода Модуля СЦ. Руководство должно содержать: · описание процесса безопасной разработки и ролевой модели, отражающей зоны ответственности сотрудников Подрядчика; · описание процессов моделирования, оценки и формирования мер предотвращения угроз, применяемых Подрядчиком; · описание методик, применяемых Подрядчиком при разработке исходного кода (правила написания кода); · описание методик, периодичности проведения и инструментария статического, динамического, композитного и фаззинг тестирования исходного кода, включающего критерии отбора релизных версий ПО, применяемые Подрядчиком в процессе разработки; · описание механизмов безопасности в процессе сборки и доставки (безопасность образов, безопасность секретов, безопасность окружения и сборочной среды), применяемые Подрядчиком; · утвержденные шаблоны отчетной документации (в том числе акты), в соответствии с которыми Заказчик принимает результаты проверок (артефакты сборочного процесса), проведенных Подрядчиком; · описание процедур отслеживания и исправления обнаруженных ошибок и уязвимостей программного обеспечения; · описание способов и сроков доведения Подрядчиком до Заказчика информации об уязвимостях программного обеспечения, о компенсирующих мерах по защите информации или ограничениях по применению программного обеспечения, способов получения пользователями программного обеспечения его обновлений, проверки их целостности и подлинности Подрядчик должен обеспечить реализацию и проведение внутренних проверок мер по разработке безопасного ПО, приведенных в Руководстве. Подрядчик должен провести анализ угроз безопасности информации программного обеспечения в соответствии с ГОСТ 58412-2019 «Защита информации. Разработка безопасного программного обеспечения. Угрозы безопасности информации при разработке программного обеспечения». Подрядчик должен провести испытания по выявлению уязвимостей в программном обеспечении Системы: · проведение статического анализа исходного кода программы; · проведение динамического анализа исходного кода программы; · проведение композитного анализа исходного кода и образов программы; · проведение фаззинг-тестирования программы, направленного на выявление в ней уязвимостей. Испытания по выявлению уязвимостей в программном обеспечении Системы должны быть проведены в рамках: · предварительных испытаний; · опытной эксплуатации; · приемочных испытаний 4.5.11. Требования к показателям назначения 4.5.11.1. Требования к показателям назначения мероприятий по развитию Модуля СЦ В рамках выполнения работ по развитию Модуля СЦ, предусмотренных ТЗ, показатель назначения «Количество пользователей» должен соответствовать значениям, приведенным в данном разделе. Пояснения по показателям, связанным с количеством пользователей, приведены в Таблице 8. Таблица 8. Определения показателей, связанных с количеством пользователей в Модуле СЦ № Показатель Определение Расчетное количество пользователей Количество пользователей, работу которых должен обеспечить Модуль СЦ к моменту сдачи работ по Контракту с учетом достижения всех показателей назначения Расчетное количество одновременно работающих пользователей Количество одновременно работающих пользователей, работу которых должен обеспечивать Модуль СЦ к моменту сдачи работ по Контракту с учетом достижения всех показателей назначения Значения показателей количества пользователей, достижение которых необходимо обеспечить, представлено в Таблице 9 Таблица 9. Значения показателей количества пользователей № Показатель Значение 1. Расчетное количество пользователей 1 000 2. Расчетное среднее количество одновременно работающих пользователей 200 Развитие Модуля СЦ должно быть направлено на достижение следующего эффекта (показателя), подставленного в мероприятии 103.002 «Информационно-аналитическая система регулирования на транспорте (АСУ ТК)» ВПЦТ Минтранса России: Выполнение работ по развитию Модуля СЦ предусмотрено мероприятием по развитию АСУ ТК, приведенном в ВПЦТ Минтранса России на 2026-2028 гг: № 103.002 «АСУ ТК» в составе ИТ расхода 103.26.000005 «Развитие предусматривает реализацию ОКР и эффектов, приведенных в Таблице 10. Таблица 10. ОКР и эффекты, приведенные в ВПЦТ Минтранса России на 2026 г. № ОКР Дата ОКР Эффекты 1 Обеспечено информационное взаимодействие с Минобороны России о происшествиях на транспортных объектах 25.12.2026 Сокращено время сбора и передачи сведений для Минобороны России о ЧС и НС на транспорте с 120 до 10 минут 2 Обеспечена автоматизация формирования отчетов о нештатных ситуациях на транспорте, в том числе по данным внешних систем 25.12.2026 Сокращено время на подготовку отчетов о нештатных ситуациях на транспорте с 20 до 5 минут Реализация остальных ОКР не является предметом данного ТЗ и проводится в рамках отдельного технического задания. 4.5.11.2. Требования к показателям назначения мероприятий по эксплуатации Модуля СЦ. Работы по эксплуатации Модуля СЦ не должны обеспечивать режимы функционирования Модуля СЦ, приведенные в разделе 4.5.2 данного ТЗ 4.1. Требования к структуре Модуля СЦ В процессе работ по развитию Системы должны сохраниться основные требования к построению архитектуры Системы в соответствии с принципами трехуровневой архитектуры: 1. уровень хранения данных или уровень базы данных (сервер СУБД); 2. уровень сервера приложений (сервер аналитической обработки); 3. презентационный уровень, обеспечивающий взаимодействие с клиентскими приложениями. В состав Системы должны входить следующие основные компоненты: 4. сервер баз данных; 5. сервер приложений; 6. веб-сервер. Сервер баз данных должен обеспечивать хранение и целостность хранимых данных, создание резервных копий, ведение журнала транзакций, восстановление данных после сбоев. Сервер приложений должен обеспечивать обработку запросов, поступающих от клиентских приложений (через веб-сервер), формирование ответов на запрос в доступном пользователю виде (формирование пользовательских интерфейсов). Веб-сервер должен обеспечивать взаимодействие с оператором и внешними системами по HTTP / HTTPS протоколу в режиме «запрос-ответ» (получения запросов от пользователя и передачи ответа в виде соответствующей информации, обработанной серверами приложений). Взаимодействие Системы с пользователем должно отвечать требованиям модели «тонкого клиента» (т.е. представлять на стороне клиента (пользователя) лишь графический пользовательский интерфейс). Все составляющие Системы должны использовать единую методологию и отвечать единым принципам взаимодействия, надежности и управления. Перечень компонентов Модуля СЦ представлен в Таблице 4. Таблица 4. Перечень компонентов Модуля СЦ, в отношении которых выполняются работы по развитию № п.п. Наименование компонента Модуля СЦ Раздел ТЗ 1 Компонент регистрации событий 4.2.1. 2 Компонент отчетности 4.2.2 3 Компонент визуализации 4.2.3 4 «Интерактивная карта» (компонент создается) 4.2.4 5 Компонент администрирования 4.2.5 4.2. Требования к дорабатываемым функциям модуля СЦ 4.2.1. Развитие компонента регистрации событий (1 очередь) Должны быть выполнены следующие доработки: – обеспечение логирования действий пользователя, связанных с карточкой события; – доработка объектной модели в части создания новых типов сущностей (карточек) с учетом реализуемых интеграций с информационными ресурсами (силы и средства предупреждения и ликвидации ЧС и нештатных ситуаций на транспорте, ТС, ограничения воздушного пространства, неблагоприятные и опасные природные явления); – реализация механизма установления связи между сущностями в Модуле СЦ автоматизированным и ручным способами (события, природные явления, силы и средства предупреждения и ликвидации ЧС и нештатных ситуаций на транспорте, ограничения воздушного пространства, ОТИ, ТС и др.); – отображение в карточке установленных связей между сущностями. 4.2.2. Развитие компонента отчетности (3 очередь) Должна быть обеспечена автоматизация процессов формирования отчетов о ЧС и нештатных ситуациях на транспорте, в т.ч. на основе данных из внешних систем. Включает следующие доработки: – разработка шаблонов отчетов в различных форматах (табличный, текстовый); – реализация выбора фотоматериалов для включения в справку; – форматирование содержимого справок с учетом правил русского языка в отношении окончаний слов (в зависимости от падежа, склонения, числа и рода); – автоматизированное формирование выводов к содержимому справки на основе настраиваемых критериев; – создание интерфейса выбора параметров (фильтрации) для формирования отчетов: o состав полей для включения в отчёт; o настройка диапазонов значений характеристик и дат; o порядок отображения полей; o настройка заголовка. – реализация способа подготовки отчётов в асинхронном режиме (очереди); – реализация интерфейса компонента формирования отчетности для отображения очереди формирования отчетов и статусов их подготовки; – экспорт отчётов в форматы xlsx, csv и справок в форматы pdf, docx. Необходимо разработать не менее 10 шаблонов отчетов и/или справок. Перечень, структура и содержание шаблонов должны быть согласованы с Заказчиком на этапе технического проектирования. 4.2.3. Развитие компонента визуализации (2 очередь) В рамках развития компонента визуализации должны быть выполнены следующие доработки, обеспечивающие: – вывод перечней (списков) сил и средств предупреждения и ликвидации ЧС и нештатных ситуаций на транспорте с отображением мест их постоянного размещения (дислокации) на карте, включая: o отображение зон ответственности на карте; o возможность их фильтрации (по видам транспорта, регионам и пр.); o реализацию инструмента расчета расстояния (с использованием сети автомобильных и железных дорог) между местом события и местами дислокации сил и средств, а также вывода маршрутов на карте; – отображение зон (полигонов) с установленными ограничениями движения в воздушном пространстве на карте; – отображение термических точек; – реализация возможности отображения данных из паспорта региона, отображаемого в модуле iМинтранс (модуль АСУ ТК); – отображение краткой карточки сущностей и ОТИ (краткой информации и/или динамических характеристик объекта) при выборе объекта на карте с возможностью перехода в полную карточку сущности и ОТИ; – отображение данных от Росгидромета, предусматривающих: o отображение неблагоприятных и опасных природных явлений на карте (с заданным периодом обновления данных); o управление отображением явлений на карте, включая настройку состава отображаемых объектов, поиск, фильтрацию, с использованием соответствующей панели управления; o выведение краткой карточки явления при выборе объекта, с возможностью перехода в полную карточку объекта – отображение на карте связанных сущностей и ОТИ; – реализация функции выбора темного и светлого стилей отображения элементов интерфейса, карточек сущностей, картографической основы и объектов, отображаемых на карте; – реализация механизма для выбора картографической основы в одном из распространенных форматов WMTS, TMS, MVT и др. Должна быть предусмотрена возможность настройки перечня картографических основ и параметров доступа к ним; – настройка базового набора дашбордов, содержащих преднастроенные виджеты о количестве событий в разрезе видов транспорта с возможностью перехода к исходным данным (карточкам событий, ОТИ и т.д.), с фильтрацией по параметрам. Параметры фильтрации должны быть определены на этапе технического проектирования. Должно быть обеспечено автоматическое и принудительное обновление данных, отображаемых на дашбордах Таблица 6. Категории обращений и заявок Категория Примеры Запрос на обслуживание Подготовка SQL запроса к СУБД для решения прикладной задачи и д.р. – запрос на любое действие, не являющееся запросом информации и несовершенный на основе происшествия, прямо или косвенно влияющего на работу Модуля СЦ Консультация «Где взять / куда обратиться...?», «Как сделать / выполнить…», «Как это работает…?» - запрос, имеющий своей целью получение информационной поддержки Инцидент Разбор ошибок/сбоев и подготовка материалов (корректировочных релизов, инструкций) для Заказчика для устранения ошибок/сбоев, которые приводят к частичному и полному нарушению работоспособности всех или отдельных функций ППО. Подготовка изменения и материалов, необходимых для проведения аварийно-восстановительных работ для возобновления работоспособности Модуля СЦ ЗНИ Подготовка изменений, связанных с изменением, улучшением/оптимизацией Модуля СЦ и выводом новой модифицированной функциональности в штатном режиме. Подготовка изменений, связанных с модификацией существующих и/или реализация новых интеграционных механизмов для получения/обработки данных внешних систем. Подготовка изменений графического интерфейса по требованиям Заказчика. Перечень статусов обращений (заявок) приведен в пункте 3.3. Регламента оказания Услуг. Назначение обращению (заявке) статуса «Закрыто» осуществляется Заказчиком только после получения от инициатора обращения (заявки) подтверждения о его исполнении или нахождения обращения (заявки) в статусе «Выполнено» и отсутствия повторных вопросов/запросов по данному обращению (заявки) в течение 5 рабочих дней. Категории и статусы обращений (заявок) могут быть скорректированы в процессе оказания услуг исключительно по согласованию с Заказчиком 4.3.6. Требования к услугам технической поддержки 4.3.6.1. Требования к организации третьего уровня технической поддержки Основными задачами организации третьего уровня технической поддержки в рамках оказания услуг по технической поддержке Модуля СЦ являются организация эксплуатационной службы Подрядчика, проверка готовности технических и программных средств для обеспечения непрерывного функционирования ППО Модуля СЦ. Подрядчиком должны быть проведены организационно-штатные и подготовительные мероприятия (в т. ч. технические) в рамках организации технической поддержки Модуля СЦ. Подрядчик в течение 5 (пяти) рабочих дней с даты заключения Контракта должен: – определить и направить Заказчику документ «Перечень уполномоченных специалистов», содержащий контактную информацию (ФИО, должность, адрес рабочей электронной почты) лиц, ответственных за оказание услуг со стороны Подрядчика; – обеспечить подключение специалистов Подрядчика к Системе регистрации обращений (заявок) (СРО предоставляется Заказчиком) для оказания услуг; – согласовать с Заказчиком способ доступа Подрядчика к Модулю СЦ. Результат выполнения мероприятий фиксируется в Протоколе проверки результатов организационно-штатных и подготовительных мероприятий (см. Приложение Д к настоящему ТЗ) 4.2.4. Создание компонента «Интерактивная карта» (2 очередь) В составе создаваемого компонента должны отображаться данные, доступные в компоненте визуализации. Требования к интерфейсу интерактивной карты: – интерактивная карта должна быть представлена в виде объемной карты с учетом макетов, представленных в Приложении А к ТЗ; – интерфейс должен корректно отображаться на экранах мониторов (разрешение Full HD 1920?1080), телевизоров (разрешение 4К 3840?2160), жидкокристаллических панелей для видеостены, используемой Заказчиком, с параметрами каждой панели: диагональ 55 дюймов, разрешение 1920x1080; – интерфейс должен корректно отображаться на планшетных устройствах с диагональю экрана 10-12 дюймов, конкретные требования должны быть уточнены на этапе технического проектирования; – должна быть обеспечена кластеризация и генерализация отображения объектов на карте при изменении масштаба; – должно быть обеспечено отображение основных характеристик объектов при выборе их на карте; – должно быть обеспечено управление отображением слоев на карте; – должна быть обеспечена настройка цветовой индикации отображаемых объектов транспортной инфраструктуры; – должно быть обеспечено отображение легенды карты, содержащей отображаемые объекты на карте; – должна быть обеспечена возможность одновременного отображения не менее 5 000 ОТИ и ТС на карте. На интерактивной карте должны быть отображены подвижные объекты совместно с объектами транспортной инфраструктуры (ОТИ), включая следующие возможности: § отображение местоположения транспортных средств (воздушный, водный и автомобильный транспорт) на карте в режиме реального времени (с заданным периодом обновления данных); § отображение маршрутов движения всех ТС за выбранный период времени, в том числе с использованием эффектов анимации; § отображение маршрутов движения ТС, связанных с карточкой события: ТС, являющихся участниками события, и ТС, находящиеся в заданном радиусе от события; § управление отображением сущностей и ОТИ на карте, включая настройку состава отображаемых объектов, поиск, фильтрацию, с использованием соответствующей панели управления и наглядным представлением результатов; § автоматическое изменение вида отображения объектов (цветовая индикация) по заданным условиям (например, при достижении критических значений параметров, характеризующих функционирование объекта); Должна обеспечиваться производительность обновления изображения на экране в 30 кадров в секунду на тестовой конфигурации пользовательского устройства (модель Бештау AIO2402/B560, входящая в Реестр российской промышленной продукции под номером 10394100 или аналог) при одновременном отображении не менее 5 000 объектов и 200 уникальных моделей объектов. Макеты интерфейсов Модуля СЦ должны быть предварительно согласованы с Заказчиком и разработаны с учетом требований ГОСТ Р ИСО 9241-161-2016 «Элементы графического пользовательского интерфейса» 4.2.6. Взаимосвязи с внешними автоматизированными системами (1 очередь) Способы взаимодействия с внешними информационными системами должны быть определены на этапе технического проектирования. Должны быть выполнены следующие доработки: – интеграции с информационными ресурсами в целях получения данных о движении подвижных ТС (воздушные суда, суда водного транспорта); – интеграция с информационным ресурсом в целях получения данных о событиях на железнодорожном транспорте. Реализация интеграций должна включать проектирование и реализацию интеграционных механизмов обмена данными с учетом доступных вариантов реализации, обеспечение защищенных способов взаимодействия, настройку отображения отдельных данных на карте (настройка слоев). Взаимодействия, имеющие каналы связи, выходящие за пределы контролируемой зоны взаимодействующих систем, считаются защищенными, если для их защиты используются программные и/или программно-аппаратные шифровальные (криптографические) средства, сертифицированные ФСБ России (далее – СКЗИ). Выбор СКЗИ, схемы подключения и требуемого класса криптостойкости должен производиться в соответствии с Техническими условиями на подключение к информационным ресурсам ФГБУ «СИЦ Минтранса России» и инструкциями по подключению пользователей к ресурсам инфраструктуры Головного центра обработки данных, утвержденных приказом директора ФБГУ «СИЦ Минтранса России» от 24.05.2024 № 21-ОД 4.3. Требования к оказанию услуг по технической поддержке Модуля СЦ 4.3.1. Общие требования к оказанию Услуг Техническая поддержка Модуля СЦ должна осуществляться с учетом требований постановления Правительства Российской Федерации от 06.07.2015 N 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации». Подрядчик обязан выполнять требования законодательства в сфере защиты информации, требования по защите информации, информационной безопасности, указанные в локальных нормативных актах ФГБУ «СИЦ Минтранса России», регламентирующих условия информационного взаимодействия, защиты информации и подключения к информационным ресурсам ФГБУ «СИЦ Минтранса России», участвующих в информационном взаимодействии в рамках оказания услуг по технической поддержке АСУ ТК в 2026 году 4.3.1.1. Требования к составу и содержанию услуг третьего уровня технической поддержки Оказание услуг по технической поддержке Системы осуществляется в рамках этапов в соответствии с календарным планом. Подрядчик в течение 5 рабочих дней с даты заключения Контракта должен предоставить со своей стороны, а Заказчик со своей стороны Матрицу ответственных за взаимодействия в соответствии с Приложением 1 к Регламенту оказания услуг по третьему уровню технической поддержки Модуля СЦ (далее – Регламент, Приложение В). Подрядчик в течение 10 рабочих дней с даты заключения Контракта должен провести мероприятия по организации третьего уровня технической поддержки в соответствии с Регламентом. Услуги по третьему уровню технической поддержки Модуля СЦ должны включать: – организацию Подрядчиком третьего уровня технической поддержки; – информационно-консультационную поддержку работников Заказчика; – решение инцидентов, связанных с работой ППО; – адаптационное, конфигурационное и коррекционное сопровождение Модуля СЦ (в рамках действующих программных модулей и функциональности); – устранение уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности Оказание услуг в рамках данного технического задания осуществляется Подрядчиком по обращению (заявке) Заказчика, направляемой посредством СРО Заказчика. Регистрация обращений, поступивших непосредственно в Модуль СЦ регистрации обращений Заказчика, производится сотрудниками Заказчика, которые обеспечивают первый уровень технической поддержки Модуля СЦ. В случае назначения приоритета «Критический» или «Высокий», информация о назначении также дублируется оповещением ответственных представителей Подрядчика посредством звонка на предоставленные номера телефонов. Обращение (заявка) должна содержать следующую информацию: – контакты пользователя/организации; – приоритет обращения, соответствующий Приложению 2 к Регламенту; – время обнаружения; – наименование компонента АСУ ТК - Модуль СЦ; Информация может быть расширена по согласованию с Заказчиком. Обращения (заявки) сотрудников Заказчика должны приниматься Подрядчиком через веб-интерфейс СРО. В процессе обработки обращений (заявок) Подрядчик должен обеспечить выполнение следующих процедур: – прием обращений(заявок) от сотрудников Заказчика; – оказание информационно-консультационной поддержки в соответствии с требованиями настоящего Технического задания; – информирование сотрудников Заказчика о статусе обработки и результатах обработки обращений(заявок). Подрядчик осуществляет обязательную регистрацию и учет всех обращений и заявок, поступивших к Подрядчику от представителей Заказчика в рамках оказания настоящих услуг Примечание: в случае приостановки работы по обращению или заявке (обращение или заявка находится в статусе «Приостановлено»), указываются причины, по которым работы по обращению или заявке приостановлены с указанием перечня действий/информации, запрошенных у инициатора обращения, а также даты, формы и адресата такого запроса. В случае отклонения обращения или заявки (заполняется в случае, если обращению или заявке присваивается статус «Отклонено»), указываются подробно причины такого отклонения, а также фиксируется дата и время перехода в статус «Отклонено». В случае, если обращение или заявка отклонены (отменены) самим Инициатором, то указывается дата и способ, которым от инициатора получено соответствующее уведомление. В случае невыполнения Подрядчиком регламентного времени реагирования или решения обращения (заявки) Заказчик вправе отозвать обращение и направить его Подрядчику повторно. При этом каждое отозванное обращение учитывается в Отчёте об оказанных услугах, как обращение с превышением времени реагирования или решения, но оплате не подлежит. В случае, если обращение (заявка) связано с некачественным выполнением Подрядчиком другой задачи, такое обращение решается в регламентное время, установленное Техническим заданием, при этом оплате такие обращения не подлежат, о чем указывается в Отчете об оказанных услугах в графе «Примечание» 4.3.6.2. Требования к услугам информационно-консультационной поддержки работников Заказчика и пользователей Модуля СЦ Услуги информационно-консультационной поддержки сотрудников Заказчика включают: – обработку обращений и заявок, поступивших от сотрудников Заказчика; – консультирование сотрудников Заказчика и пользователей Модуля СЦ; – актуализацию документации, и других материалов по работе с Модулем СЦ при необходимости. – консультирование и разработку рекомендаций по настройке Модуля СЦ (без изменения программного кода), включая изменение настроек функционирования; – консультации по вопросам использования, настройки и возможностям Модуля СЦ; – консультации по проведению превентивных мер для недопущения аварийных ситуаций в Модуле СЦ; – консультации по предварительной диагностике и локализации возникшей неисправности Модуля СЦ; – консультации по вопросам обеспечения информационной безопасности Модуля СЦ и настройки функций, обеспечивающих корректную работу программного обеспечения для совершения юридически значимых действий в Модуле СЦ; – другие вопросы, связанные с работой Модуля СЦ. 4.3.6.2.1. Требования к порядку оказания услуг информационно-консультационной поддержки работников Заказчика и пользователей Модуля СЦ Подрядчик выполняет консультирование сотрудников Заказчика и пользователей Модуля СЦ. Консультация может быть предоставлена по согласованным с представителем Заказчика каналам коммуникации с регистрацией результата консультации в СРО Подрядчиком. Детальный порядок оказания консультационных услуг определен в Регламенте оказания Услуг 4.3.6.3. Требования к услугам по решению инцидентов, связанных с работой ППО Подрядчик устраняет неисправности Модуля СЦ, связанные с работой ППО, выявленные в рамках оказания услуг согласно настоящему Техническому заданию, при этом в зону ответственности Подрядчика не входит устранение неисправностей, выявленных на стороне Заказчика и на стороне третьих лиц (провайдера связи, поставщика электропитания и т.д.). Первичная диагностика выявленной неисправности проводится на 1 и 2 уровнях технической поддержки и не входит в зону ответственности Подрядчика. Если при проведении первичной диагностики и попытке устранить неисправности на 1 и 2 уровнях технической поддержки, данную неисправность устранить не удалось и в процессе диагностики было выявлено, что проблема связана с работоспособностью ППО, обращение (заявка) назначается сотруднику Подрядчика, ответственному за оказание услуг технической поддержки 3 уровня. Инцидентами вне зоны ответственности Подрядчика являются: – работоспособность функциональности, выходящая за рамки текущей реализации функций в Модуле СЦ и/или являющаяся расширением требований Заказчика к функциям Модуля СЦ; – проведение профилактических и плановых работ, согласованных с Заказчиком; – нарушение работоспособности функций Модуля СЦ, вызванное проведением работ на стороне Заказчика 4.2.4.1. Требования к технической реализации компонента «Интерактивная карта» При реализации компонента «Интерактивная карта» должны учитываться требования, указанные ниже. 4.2.4.1.1. Требования к отображению элементов Повторяющихся элементы карты (ТС, ОТИ, события и пр.) должны отрисовываться с использованием аппаратного создания экземпляров объектов на пользовательском устройстве (WebGL/WebGPU)). Отрисовка каждого объекта отдельным запросом не допускается, должна обеспечиваться возможность одновременного отображения не менее 5 000 объектов без снижения производительности (30 кадров в секунду на тестовой конфигурации). 4.2.4.1.2. Уровни детализации объектов Для управления отображением сложных объектов должно быть создано не менее 3-х уровней детализации, отображаемых при изменении масштаба с возможностью автоматического переключения между уровнями. Все отображаемые объекты должны масштабироваться с учетом разрешения экрана пользователя с сохранением качества детализации. 4.2.4.1.3. Полигональная оптимизация и текстурирование При реализации компонента «Интерактивная карта» должна обеспечиваться технология рельефного тестурирования объектов. Не должны использоваться высокополигональные трехмерные модели. Все повторяющиеся элементы должны генерироваться единоразово и повторно использоваться при последующих отображениях. 4.2.4.1.4. Управление памятью Требуется реализовать потоковую загрузку на устройство пользователя элементов карты и текстур. Загрузка данных целиком при старте приложения не допускается. Необходимо реализовать механизм очистки памяти от элементов, которые находятся вне области видимости камеры в течение заданного времени. 4.2.4.1.5. Требования к взаимодействию пользователя с интерфейсом компонента «Интерактивная карта» Программная реализация механизмов управление камерой (масштабирование и навигация) должна быть выполнена с поддержкой технологии WebAssembly (WASM). Элементы управления должны являться неотъемлемой частью интерактивной карты. 4.2.5. Развитие компонента администрирования (3 очередь) Должна быть выполнена доработка ролевой модели. Ролевая модель должна обеспечивать управление доступом к отдельным объектам Модуля СЦ и их элементам (атрибутам) с разграничением по видам транспорта, регионам и пр., в частности: – определение набора конкретных действий, доступных пользователям (выполняемых над объектом доступа, например, удаление записи, редактирование записи, формирование отчета и др.); – реализация возможности объединения пользователей в группы; – определение прав доступа для групп пользователей; – реализация интерфейса визуальной настройки прав доступа пользователей к объектам Модуля СЦ 4.3.1.2. Требования к общему порядку оказания услуг Техническая поддержка Модуля СЦ должна быть организована на трех уровнях: – первый и второй уровни технической поддержки организуется Заказчиком; – третий уровень технической поддержки организуется Подрядчиком. Перечень действий на каждом уровне технической поддержки указан в Таблице 5: Таблица 5 – Перечень действий на каждом уровне технической поддержки Уровень технической поддержки Доступные действия Условия передачи задачи на следующий уровень Первый уровень технической поддержки (далее – 1-й уровень) – принимает обращения (заявки) пользователей Модуля СЦ и работников Заказчика; – регистрирует обращения в Модуле СЦ регистрации обращений; – присваивает уникальный идентификационный номер, классифицирует обращения; – самостоятельно решает обращения, которые связаны с недостаточной квалификацией пользователей или настройками в рамках своей компетенции; – взаимодействует с пользователями Модуля СЦ при решении проблемы Передает обращение на второй уровень поддержки в случае невозможности решения на своем уровне Второй уровень технической поддержки (далее – 2-й уровень) – принимает обращения от 1-го уровня; – уточняет классификацию обращения в результате дополнительного анализа; – самостоятельно решает обращения в рамках своей компетенции; – осуществляет техническую и консультационную поддержку Модуля СЦ; – взаимодействует с сотрудниками 1-го и 3-го уровня и пользователями Модуля СЦ; – формирует заявки для 3-го уровня и контролирует исполнение Передает обращение на третий уровень поддержки в случае невозможности решения на своем уровне Третий уровень технической поддержки (далее – 3-й уровень) – принимает обращения от 2-го уровня; – обеспечивает выполнение требований, предъявляемых Контрактом и настоящим Техническим заданием к Услугам, оказываемым Подрядчиком Все поступающие обращения должны быть исполнены Подрядчиком Для обеспечения взаимодействия с Заказчиком Подрядчик со своей стороны определяет ответственных лиц, уполномоченных в структуре Подрядчика за своевременное и качественное оказание Услуг в рамках настоящего ТЗ, а также контактную информацию ответственных лиц (телефон, электронную почту). Подрядчик должен предоставить Заказчику единый адрес электронной почты для приема обращений (заявок) в течение 3 (трех) рабочих дней после заключения Контракта. Указанный в настоящем пункте адрес электронной почты (способ направления обращений (заявок) применяется в случае сбоя в работе СРО Заказчика. Со своей стороны, Заказчик предоставляет Подрядчику перечень и контактную информацию (телефон, электронную почту) уполномоченных лиц для осуществления взаимодействия с указанием зон ответственности. О любых изменениях в контактной информации ответственных лиц Стороны должны уведомить друг друга в течение 1 (одного) рабочего дня с момента возникновения таких изменений посредством уведомления на электронную почту ответственных лиц и/или в письменной форме. В результате оказания услуг по настоящему ТЗ не должны быть изменены исходные коды, дистрибутивы и иные компоненты Модуля СЦ вне согласованных с Заказчиком изменений. Любые изменения исходных кодов, дистрибутивов и иных компонентов Модуля СЦ должны производиться только после согласования с Заказчиком уполномоченными лицами по электронной почте или иным заранее согласованным способом. Не должна быть ухудшена надежность и производительность Модуля СЦ. Оказание услуг по Контракту не должно нарушать требования к информационной безопасности, описанной в документации на Модуль СЦ 4.3.1.3. Требования к регламенту оказания услуг Подрядчик должен руководствоваться Регламентом оказания услуг по технической поддержке Модуля СЦ. Регламент оказания услуг содержит следующую информацию: – порядок оказания услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Модуля СЦ; – порядок оказания услуги по решению инцидентов, связанных с работой ППО; – порядок оказания услуги адаптационного, конфигурационного и коррекционного сопровождения Модуля СЦ (в рамках действующих программных модулей и функциональностей); – порядок оказания услуги по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности. – Регламент содержит следующие формы заявок на оказание услуг: – форма заявки на оказание услуги по информационно-консультационной поддержке сотрудников Заказчика; – форма заявки на оказание услуги по решению инцидентов, связанных с работой ППО; – форма заявки на оказание услуг адаптационного, конфигурационного и коррекционного сопровождения Модуля СЦ (в рамках действующих программных модулей и функциональностей) (приоритет заявки определяется Заказчиком); – форма заявки на оказание услуги по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности 4.3.2. Требования к режиму обеспечения функционирования Модуля СЦ Режим оказания услуг определен в Приложении Б к настоящему ТЗ. По согласованию с Заказчиком, в целях недопущения остановки функционирования Модуля СЦ в период интенсивной работы пользователей в Модуле СЦ, отдельные услуги могут оказываться по специальному графику (в нерабочее время Подрядчика) в соответствии с заявками Заказчика 4.3.3. Требования к качеству оказываемых услуг Качество оказываемых услуг поддерживается Подрядчиком в соответствии с определяемыми данным ТЗ условиями и правилами и контролируется Заказчиком на постоянной основе, в том числе по соблюдению сроков исполнения и подтверждениям исполнения от инициаторов обращений и другим параметрам. По результатам выполнения работ по устранению инцидента должна быть устранена корневая причина инцидента с окончательным решением, устраняющим причину возникновения проблемы и исключающим вероятность повторного возникновения проблемы (инцидента). Время устранения корневых причин проблемы (инцидента) не должно составлять более 40 рабочих часов Работы по устранению неисправности приостанавливаются (по согласованию с Заказчиком) в следующих случаях: – если Подрядчиком в результате диагностики выявлено, что неисправность находится в зоне ответственности Заказчика. Подрядчик информирует Заказчика о выявленной неисправности в зоне его ответственности по согласованным каналам связи; – требуется действие со стороны Заказчика – до момента выполнения данного действия Заказчика. Заказчик информируется о необходимых действиях по согласованным каналам связи; – отсутствие возможности связаться со специалистами Заказчика, участие которых необходимо для устранения неисправности; – требуется доставить оборудование на объект – до момента доставки и установки оборудования. В случаях, представленных выше, время приостановки работ не входит в учет продолжительности устранения неисправности. Учет времени устранения неисправности Подрядчиком считается с момента назначения Инцидента специалисту Подрядчика, ответственному за оказание услуг технической поддержки 3 уровня. Подтверждение необходимости приостановления работ находится в зоне ответственности Подрядчика. Приостановление сроков выполнения задач в соответствии с настоящим пунктом подтверждается Заказчиком по мотивированному обращению Подрядчика в СРО, основанному на данных диагностики или на иных фактических обстоятельствах В случае непринятия Подрядчиком необходимых мер по информированию Заказчика (отсутствие надлежащего обращения от Подрядчика или отсутствие уведомления о необходимости осуществления каких-либо действий Заказчиком) не может являться основанием для приостановления работ по устранению неисправности. В отдельных случаях Подрядчику может потребоваться выполнение технологических работ для устранения причин неисправности или недопущения повторения их в будущем. Для обеспечения устранения неисправности Модуля СЦ Заказчиком проводится классификация в соответствии с приоритетами по степени срочности их устранения. Продолжительность устранения неисправности, а также периодичность информирования Подрядчиком Заказчика о ходе устранения неисправности, определены в Регламенте оказания услуг. При подаче обращения (заявки) наивысшего приоритета через СРО Заказчик должен дополнительно проинформировать службу поддержки Подрядчика о созданном обращении (заявки) по телефону уполномоченного сотрудника Подрядчика. При этом временем подачи обращения (заявки) считается время подачи обращения (заявки) через СРО 4.3.6.4.1. Требования к проведению изменений Основанием для внесения изменений является запрос от Заказчика. Все активности по внесению изменений должны быть согласованы с Заказчиком, а действия Подрядчика при оказании данной услуги должны быть зафиксированы. В рамках данного Технического задания изменениями считаются локальные доработки функционала Модуля СЦ, которые не должны приводить к необходимости выполнения дополнительных аттестационных испытаний или переаттестации АСУ ТК в соответствии с п. 33 приказа от 29.04.2021 № 77 «Об утверждении Порядка организации и проведения работ по аттестации объектов информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну». При необходимости внесения изменений в Модуль СЦ, не связанных с критичным инцидентом, существенно нарушающим работоспособность Модуля СЦ, Заказчик направляет Подрядчику обращение (заявку), в котором излагает суть изменения, которое требуется внести в Модуль СЦ. Исполнитель, в течение 3 (трех) рабочих дней с момента поступления соответствующего обращения (заявки), оценивает техническую возможность реализации запрашиваемого изменения и варианты реализации. По итогу проведения оценки Подрядчик направляет Заказчику заключение о возможности реализации данного изменения с описанием возможных вариантов реализации и согласует с Заказчиком проведение данного изменения При проведении работ по изменению и адаптации Подрядчик должен: – обеспечить выполнение требований безопасной разработки программного обеспечения; – обеспечить предварительное проектирование технических решений и согласование с Заказчиком проекта реализации изменения; – использовать семантическое версионирование (SemVer) в работе, передать Заказчику все артефакты разработки (исходный код и сторонние библиотеки, конфигурации, сборочные и собранные образы и др.); – подготовить полноценное описание функционала, включенного в релиз, с необходимыми схемами и пояснениями к обновлению на стендах Заказчика; – обеспечить тестирование разработанного функционала на стендах Заказчика силами Подрядчика; – решение о переносе измененного ППО на продуктивный стенд принимается Заказчиком по итогу результатов проведенного тестирования; – обеспечить техническое сопровождение процедуры тестирования ППО и переноса измененного ППО на продуктивный стенд Заказчика; – обеспечить экстренное внесение соответствующих изменений в случае выявления некорректной работы продуктивного стенда Заказчика после проведения обновления по итогам разработанного изменения в кратчайшие сроки; – актуализировать при необходимости комплект эксплуатационной документации: o руководство пользователя; o руководство администратора; o иные документы (при необходимости). Результат выполнения изменений должен быть отражен в Отчете по оказанию услуг. Типы и приоритеты изменений могут быть скорректированы в процессе оказания услуг исключительно по согласованию с Заказчиком 4.3.4. Требования к документированию результатов оказываемых услуг Для обеспечения контроля оказываемых услуг по поддержке Модуля СЦ со стороны Заказчика, по окончании каждого отчетного периода по контракту в соответствии с календарным планом, Подрядчик обязан предоставить Заказчику Отчет об оказанных услугах. Отчет должен содержать детальную информацию об оказанных услугах с указанием даты выполненных мероприятий и приложением обосновывающих документов (заявок, запросов, требований) или ссылкой на такие документы, если они содержатся в Модуле СЦ. Информация о выполненных мероприятиях по заявкам должна быть сформирована на основании соответствующих записей СРО по каждому этапу исполнения Контракта. В случае оказания услуги адаптационного, конфигурационного и коррекционного сопровождения Модуля СЦ, должны быть предоставлены документы, подтверждающие выполнение требований п. 29.3 приказа ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации». Фактическое время реагирования и время решения по всем обращениям, поступившим в СРО, формируется в СРО по итогам отчетного периода в разделе «Отчеты». Фактическое время реагирования и время решения по обращениям учитывает суммарное время, затраченное на реагирование и, соответственно, на работу по обращению с момента назначения обращения специалисту Подрядчика или группе исполнителей, ответственным за оказание услуг технической поддержки 3 уровня от начала до завершения работ Подрядчиком. При этом принимается суммарное время нахождения заявки в соответствующих статусах заявки СРО на стороне Подрядчика 4.3.5. Требования к классификации обращений и заявок Обращения и заявки Заказчика классифицируются в соответствии с приоритетами и регламентными сроками, указанными в Приложении 2 к Регламенту. Регистрация обращений и заявок предусматривает создание новой записи в СРО с присвоением поступившему обращению или заявке (новой записи) уникального идентификатора. Запись в СРО должна содержать вопрос или проблему, которую требуется решить или оказать консультацию. Состав обязательной информации, которую должно содержать обращение или заявка, зафиксирован в Регламенте оказания Услуг. Если обращение или заявка автоматически зарегистрированы в СРО при отправке представителем Заказчика, Подрядчик проверяет корректность классификации обращения или заявки и может обратиться к Заказчику с просьбой корректировки, предоставив обоснования в соответствии с настоящей классификацией (Таблица 6) 4.3.6.3.1. Требования к порядку оказания услуги по решению инцидентов, связанных с работой ППО При поступлении от Заказчика обращения (заявки), являющегося неисправностью в работе Модуля СЦ (инцидентом), Исполнитель реагирует на инцидент в СРО в срок не более 30 минут с момента поступления. В случае необходимости, для решения инцидента ответственный специалист должен связаться с инициатором обращения (заявки) для уточнения условий воспроизведения проблемы или для получения дополнительных сведений. После получения необходимых сведений от инициатора обращения (заявки) ответственный специалист производит диагностику с целью выявления причины инцидента и возможных путей устранения. В случае, если инцидент невозможно решить без получения дополнительных сведений от инициатора, и не удается связаться с инициатором в течение пяти рабочих дней, обращение (заявка) отклоняется в связи с недостатком данных для его решения, Заказчику направляется уведомление об отклонении обращения (заявки). Время, в течение которого невозможно связаться с инициатором, вычитается из общего времени обработки обращения (заявки). Все попытки связаться с инициатором должны фиксироваться с указанием даты и времени попытки, используемого способа связи (номер телефона, адрес электронной почты) и результата попытки (не удалось дозвониться, абонент недоступен, и т.д.) Факт и время решения инцидента должны быть зафиксированы и отражены в СРО. В случае, если причиной сбоя в работе Модуля СЦ является выход из строя аппаратного обеспечения или неработоспособность смежной информационной системы, время работы над инцидентом приостанавливается до момента устранения неисправности. В ходе решения инцидентов могут быть выявлены дефекты ППО Модуля СЦ. В случае обнаружения дефектов ППО, Подрядчик информирует об этом Заказчика. Исполнитель может быть привлечен к проверке результата устранения дефекта по инициативе Заказчика. Приоритеты инцидентов приведены в Приложении Б к ТЗ. Детальный порядок оказания услуги по решению инцидентов, связанных с работой ППО Модуля СЦ определен в Регламенте оказания Услуг 4.3.6.4. Требования к услугам адаптационного, конфигурационного и коррекционного сопровождения и доработки Модуля СЦ (в рамках действующих программных модулей и функциональностей) Услуги адаптационного, конфигурационного и коррекционного сопровождения и доработки Модуля СЦ включают: – управление изменениями и адаптация функций Модуля СЦ; – изменение настроек функционирования Модуля СЦ; – внесение изменений и/или модификаций Модуля СЦ (в рамках действующих программных модулей и функциональностей), направленных на улучшение их работоспособности и функциональных возможностей; – подготовка и передача Заказчику SQL запросов в СУБД для получения агрегированной информации из Модуля СЦ, которую невозможно получить с использованием графического пользовательского интерфейса; – адаптация модулей интеграций со смежными информационными системами 4.3.6.4.2. Требования к изменению настроек функционирования Изменение настроек функционирования может проводиться в рамках допустимых пределов изменения функционирования, заложенных в архитектуру Модуля СЦ. Изменение настроек функционирования включает в себя изменение данных и справочников, изменение форм документов, формируемых Модулем СЦ, изменение и настройку форматов и версий передачи данных в смежные системы. Доработка программного кода Модуля СЦ может допускаться (в случае необходимости) при выполнении работ по адаптации функций Модуля СЦ в части изменения формата передачи данных в смежные информационные системы при условии соблюдения требований пункта 29.3 приказа ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации» 4.3.6.5. Требования к услугам по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности По запросу Заказчика Подрядчик должен провести работу по приведению ППО в соответствие с требованиями по обеспечению информационной безопасности. Критичность уязвимости оценивается в соответствии в соответствии с Методическим документом ФСТЭК России «Методика оценки уровня критичности уязвимостей программных, программно-аппаратных средств» (утвержден ФСТЭК России 30.06.2025), а также с учетом ГОСТ 56545-2015 и международными стандартами (CVSS 3.0 и выше), и задает необходимый срок устранения. В процессе проведения Заказчиком обследования Модуля СЦ и выявления уязвимостей в ППО, связанных с исходным кодом Модуля СЦ и/или используемыми компонентами (библиотеками), Заказчик направляет Подрядчику обращение (заявку) на устранение, с указанием критичности и срочности принятия мер по устранению в СРО. Подрядчик при оказании услуг по обновлению или устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности должен: – провести анализ уязвимостей и связанных с ними исходным кодом и/или используемыми компонентами (библиотеками); – выработать варианты устранения указанных уязвимостей и согласовать с Заказчиком их реализацию; – своевременно внести изменения в исходный код Модуля СЦ и/или используемые компоненты (библиотеки) и подготовить соответствующее обновление; – провести обновление Модуля СЦ в тестовом контуре Заказчика и проинформировать Заказчика о готовности проведения тестирования; – протестировать успешность обновления или устранения уязвимостей в ППО и корректность функционирования Модуля СЦ на тестовом контуре, совместно с Заказчиком; – при невозможности незамедлительного устранения уязвимости приоритетов «Критический» и «Высокий» Подрядчик обязан предоставить исчерпывающий список причин и согласовать план достаточных компенсирующих мер с ответственными сотрудниками Заказчика. Результат внесения изменений отображается в соответствующей записи в СРО и в составе Отчета об оказанных услугах 4.3.6.5.1. Требования к порядку оказания услуг по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности Подрядчик в соответствии с приоритетами обращений и контрольными сроками исполнения (см. Приложение Б к ТЗ) оценивает техническую возможность и сроки устранения уязвимостей, и реализацию обновления Модуля СЦ. По итогу проведения оценки Подрядчик направляет в заявке СРО Заказчику заключение о возможности устранения уязвимостей и/или обновления в ППО и согласует с Заказчиком проведение данных работ 4.4.8. Требования к техническому обеспечению Количество серверов, подключаемых и настраиваемых сервисов, их параметров, схемы соединений и настройки межсетевого взаимодействия должны быть согласованы с Заказчиком на этапе № 1 Техническое проектирование. Доступ к комплексу технических средств предоставляется Заказчиком по письменному запросу Подрядчика. Применяемые в Системе программно-аппаратные и аппаратные комплексы должны соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации», требованиям Постановления Правительства Российской Федерации от 23 декабря 2024 г. № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц». Модуль СЦ, работающий в составе АСУ ТК, развернут на вычислительных мощностях ГЦОД СИЦ Минтранса России 4.5. Общие технические требования 4.5.1. Требования к численности и квалификации персонала и пользователей Модуля СЦ Программное обеспечение Модуля СЦ не должно требовать изменения штатной численности персонала Заказчика. Программное обеспечение Модуля СЦ не должно требовать наличия у пользователей дополнительной квалификации в сфере информационных технологий, кроме базовых знаний в обращении с персональным компьютером, базовых навыков работы в интернет-обозревателях и знаний о Модуле СЦ в объеме документов Руководство пользователя, Руководство администратора 4.5.2. Требования к режимам функционирования Модуля СЦ Модуль СЦ должен предусматривать наличие следующих режимов работы: – штатный; – регламентный (профилактический); – аварийный. Основным режимом функционирования является штатный. В штатном режиме все компоненты корректно и полностью выполняют свои функции. Перерывов в работе как Модуля СЦ в целом, так и одного, либо нескольких компонентов не предусмотрено. Режим регламентного (профилактического) обслуживания предназначен для проведения работ по обновлению и техническому обслуживанию компонентов Модуля СЦ, а также резервному копированию данных. При работе в данном режиме допускаются перерывы в работе Модуля СЦ с предварительным информированием пользователей. Состав процедур по регламентному обслуживанию Модуля СЦ и их периодичность определяются Подрядчиком в процессе выполнения работ по созданию Модуля СЦ. В режиме регламентного (профилактического) обслуживания Модуль СЦ может функционировать с частичным ограничением своих функциональных возможностей, либо без ограничения, но со снижением показателей надежности и производительности. Перевод в данный режим работы должен осуществляться сразу после начала выполнения любой операции, отнесенной к этому режиму, с последующим возвратом в штатный режим функционирования сразу после ее завершения. Перевод в указанный режим должен осуществляться при возникновении необходимости проведения работ по обновлению и техническому обслуживанию компонентов Модуля СЦ, а также резервному копированию данных с условием предварительного оповещения пользователей. Аварийный режим функционирования характеризуется отказом одной или нескольких подсистем, вызванных выходом из строя аппаратного и/или программного обеспечения, а также в случае временной неработоспособности каналов связи между серверами. По результатам анализа угроз безопасности информации программного обеспечения и испытаний по выявлению уязвимостей в программном обеспечении Системы должна быть предоставлена отчетная документация по формам, утвержденным в Руководстве, и артефакты сборочной среды, подтверждающие проведение испытаний по выявлению уязвимостей в программном обеспечении Систем. Уязвимости подлежат устранению в сроки, обозначенные Заказчиком. В случае обнаружения уязвимого компонента Подрядчик должен заменить/обновить библиотеки. В случае, если уязвимость не подлежит исправлению на программном уровне, Подрядчик должен разработать меры предотвращения угроз безопасности, в том числе правила безопасности для наложенных средств защиты, рекомендации по безопасной настройке конфигурации для устранения потенциальных уязвимостей и снижения рисков информационной безопасности. Уязвимости, найденные ФСБ России, ФСТЭК России, Минцифры России, Роскомнадзором в ходе исполнения Контракта, а также в течение гарантийного периода, должны быть устранены Подрядчиком за свой счет в сроки, согласованные с Заказчиком 4.5.6. Требования к эргономике и технической эстетике Взаимодействие пользователей с Модулем СЦ должно осуществляться посредством визуального графического интерфейса. Ввод-вывод данных, прием управляющих команд и отображение результатов их исполнения должны выполняться в интерактивном режиме. Интерфейс должен быть рассчитан на преимущественное использование манипулятора типа «мышь», то есть управление Модулем СЦ должно осуществляться с помощью набора экранных меню, кнопок, значков и т. п. элементов. Клавиатурный режим ввода должен использоваться главным образом при заполнении и/или редактировании текстовых и числовых полей экранных форм. Все надписи экранных форм, а также сообщения, выдаваемые пользователю (кроме системных сообщений), должны быть на русском языке. Модуль СЦ должен обеспечивать проверку вводимых пользователем данных и предупреждать о некорректно введённых значениях Экранные формы должны проектироваться с учетом требований унификации: – все экранные формы пользовательского интерфейса должны быть выполнены в едином графическом дизайне, с одинаковым расположением основных элементов управления и навигации; – для обозначения сходных операций должны использоваться сходные графические элементы, кнопки и другие управляющие (навигационные) элементы. Термины, используемые для обозначения типовых операций, а также последовательности действий пользователя при их выполнении должны быть унифицированы; – внешнее поведение сходных элементов интерфейса (реакция на наведение указателя «мыши», переключение фокуса, нажатие кнопки) должно реализовываться одинаково. Структура размещения информации и представление этой структуры в Модуле СЦ должны соответствовать следующим требованиям: – пункты меню в пользовательском веб-интерфейсе должны быть сгруппированы в соответствии с тематикой информации, функциональными задачами и технологией работы; – каждому пункту меню должна соответствовать только одна выполняемая функция; – при совершении пользователями ошибочных действий должны выдаваться сообщения об ошибках. Эскизы визуального оформления компонента «Интерактивная карта» представлены в Приложении А. При проведении работ по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности необходимо выполнить следующее: – Заказчику сформировать заявку на устранение (обновление) в СРО с полным списком обнаруженных уязвимостей и планируемыми работами; – согласовать в рабочем порядке время начала и завершения работ, перечень работ, выполняемых в рамках обновления или устранения уязвимостей в ППО с Заказчиком; – оповестить Заказчика о начале проведения работ на тестовом контуре; – провести работы по обновлению или устранению уязвимостей в ППО на тестовом контуре Модуля СЦ в установленные сроки; – протестировать выполнение работ в тестовом контуре и проинформировать Заказчика о готовности переноса ППО на продуктивный контур; – силами Заказчика обновить продуктивный контур Модуля СЦ, в соответствии с планом устранения и выполненными работами; – совместно с Заказчиком проверить корректность функционирования Модуля СЦ и устранения уязвимостей в продуктивном контуре Модуля СЦ по результатам обновления; – при необходимости актуализировать документацию (описание архитектуры, анкеты постановки на мониторинг и иные документы). Любые изменения в части обновления или устранения уязвимостей в ППО на промышленном контуре Модуля СЦ должны применяться только в случае успешного проведения аналогичных работ на тестовом контуре. Детальный порядок оказания услуги по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности определен в Регламенте оказания Услуг 4.4. Требования к видам обеспечения 4.4.1. Требования к лингвистическому обеспечению Документация на Модуль СЦ должна разрабатываться на русском языке. Взаимодействие пользователей с Модулем СЦ посредством графического интерфейса должно происходить на русском языке за исключением сообщений, зависящих от настроек системного программного обеспечения, установленного на рабочих местах пользователей. При разработке программных решений Модуля СЦ должно быть предусмотрено использование языков программирования высокого уровня, приведенных в Таблице 7. Таблица 7. Языки и средства разработки, специального программного обеспечения Модуля СЦ Категория Наименование Назначение Языки программирования Kotlin Разработка серверной логики и сервисов (backend) JavaScript / TypeScript Разработка клиентской части (frontend) Python Разработка скриптов интеграции, обработки данных и автоматизации Фреймворки и библиотеки Vue.JS Разработка пользовательских интерфейсов (веб-интерфейсы компонентов визуализации и отчетности) React Разработка пользовательских интерфейсов (при необходимости создания сложных интерактивных компонентов) Решения по лингвистическому обеспечению, включая перечень используемых языков программирования, должны быть согласованы с Заказчиком на этапе технического проектирования В аварийном режиме осуществляется поиск неисправностей и проведение работ по их устранению. Перевод в аварийный режим должен осуществляться при возникновении сбоев, аварий и прочих незапланированных воздействий, сразу после наступления одной или нескольких аварийных ситуаций, с последующим возвратом в штатный режим функционирования сразу после окончания восстановительных работ. ПО Модуля СЦ должно обладать надежностью, обеспечивающей работу пользователей в произвольном режиме и оперативное восстановление работоспособности при сбоях. В целях обеспечения надежного функционирования ПО должно предусматривать: – сохранение целостности данных при нештатном завершении работы компонентов Модуля СЦ; – сохранение работоспособности программного обеспечения при некорректных действиях пользователя; – резервное копирование базы данных Модуля СЦ. – время восстановления работоспособности Модуля СЦ после отказа не более 4 часов. – отказоустойчивость на уровне 99% при единовременной количестве не менее 200 пользовательских сессий в Модуле СЦ. Указанные характеристики приведены без учета характеристик надежности инфраструктуры и времени передачи информации по каналам связи. При возникновении сбоев в аппаратном обеспечении, включая аварийное отключение электропитания, Модуль СЦ должен автоматически восстанавливать свою работоспособность (не требовать перенастройки) после устранения сбоев и корректного перезапуска аппаратного обеспечения Технические меры по обеспечению надежности должны предусматривать: – резервирование критически важных компонентов и данных Системы и отсутствие единой точки отказа; – использование программного резервирования (программной избыточности); – изменение конфигурации используемых средств и применение специализированного ПО, обеспечивающего высокую надёжность. Организационные меры по обеспечению надежности должны быть направлены на минимизацию ошибок пользователей (а также обслуживающего персонала при эксплуатации и проведении работ по обслуживанию), минимизацию времени ремонта или замены вышедших из строя компонентов за счёт: – обеспечения для обслуживающего персонала требуемого уровня квалификации; – регламентации и нормативного обеспечения выполнения работ обслуживающим персоналом; – своевременной диагностики неисправностей. Расчетное значение коэффициента доступности Модуля СЦ должно составлять не менее 0,95. 4.5.3. Требования по диагностированию Модуля СЦ Диагностирование Модуля СЦ должно осуществляться путем анализа записей в системных журналах СУБД, операционных систем серверов, а также с помощью встроенных средств диагностирования общего программного обеспечения Модуля СЦ. Диагностированию подлежат: – сбои и нарушения функционирования технического обеспечения (серверов) Модуля СЦ; – сбои и нарушения функционирования системного программного обеспечения серверов, используемых для работы Модуля СЦ; – сбои и нарушения функционирования прикладного программного обеспечения серверов, используемых для работы Модуля СЦ; – случаи недоступности (отсутствия ответа) или некорректные ответы внешних систем; – сбои и нарушения функционирования СУБД; – сбои при выполнении регламентных операций резервного копирования. При возникновении аварийных ситуаций либо ошибок в программном обеспечении диагностические инструменты должны позволять сохранять набор информации, необходимой для идентификации и устранения проблемы. Модуль СЦ и ее компоненты должны обеспечивать возможность диагностики своей работоспособности с возможностью интеграции с модулем мониторинга АСУ ТК. Набор передаваемых журналов и метрик должен быть определен на этапе технического проектирования 4.5.7. Требования по сохранности информации при авариях В случае возникновения аварии или сбоя в процессе выполнения пользовательских задач должно быть обеспечено восстановление баз данных до состояния на момент последней завершенной Модулем СЦ транзакции, и структуры файлового хранилища. Все аварийные ситуации должны обрабатываться программно с выдачей соответствующих сообщений, с корректной обработкой ситуации (завершение транзакций, закрытие файлов и т.п.), без потери обрабатываемой информации. В Модуле СЦ должны быть предусмотрены меры, обеспечивающие целостность данных в случае отказа программного обеспечения или аппаратных средств, исключая случаи физического уничтожения носителя или нарушения функциональности носителя, операционной системы или СУБД по вине их производителя либо обслуживающего персонала. Используемые аппаратные и системные платформы должны обеспечивать сохранность и целостность информации в Модуле СЦ при полном или частичном отключении электропитания, аварии сетей телекоммуникации, полном или частичном отказе технических средств Модуля СЦ. Технические решения должны обеспечивать сохранность информации в случае возникновения следующих событий (аварий, отказов и т.п.): – отказ аппаратного обеспечения на сервере; – отключение питания на сервере; – отказ аппаратного обеспечения на рабочей станции; – отключение питания на рабочей станции администратора; – отказ линий связи, в том числе при осуществлении обмена данными 4.5.8. Требования к защите от влияния внешних воздействий Требования к защите от влияния внешних воздействий не предъявляются 4.5.9. Требования к патентной чистоте и патентоспособности 4.5.9.1. Исключительные права на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, базы данных, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, принадлежат Российской Федерации в лице Заказчика. Право собственности на результаты работ, отчетные документы и материалы, полученные в ходе выполнения работ по Контракту, принадлежат Российской Федерации в лице Заказчика и считаются переданными с момента подписания Сторонами Акта сдачи-приемки выполненных работ. Разработанное программное обеспечение поставляется вместе с исходными кодами. 4.5.9.2. Все проектные и технические решения должны отвечать требованиям четвертой части Гражданского кодекса Российской Федерации. Результаты Работ должны быть свободными от возможности предъявления любых прав и притязаний третьих лиц, основанных на промышленной, интеллектуальной или другой собственности. 4.5.9.3 Результаты выполненных Работ не должны повлечь необходимость осуществления Заказчиком закупок программного обеспечения (как исключительных, так и неисключительных прав) для обеспечения функциональности Системы в соответствии с Техническим заданием. При выполнении работ Подрядчик должен использовать только объекты интеллектуальной собственности, права на которые приобретены (получены) и используются без нарушений прав на интеллектуальную собственность третьих лиц или предоставлены Заказчиком 4.4.2. Требования к математическому обеспечению Требования к математическому обеспечению не предъявляются. 4.4.3. Требования к метрологическому обеспечению Требования к метрологическому обеспечению не предъявляются. 4.4.4. Требования к организационному обеспечению Требования к организационному обеспечению не предъявляются. 4.4.5. Требования к методическому обеспечению Задачи методического обеспечения Модуля СЦ должны быть обеспечены за счет использования технологических и методических документов касающихся вопросов функционирования транспортного комплекса и разработки и эксплуатации ПО. 4.4.6. Требования к информационному обеспечению Состав, структура и способы организации информационного обеспечения в Модуле СЦ должны быть определены на этапе технического проектирования. Факты информационного обмена с внешними системами должны фиксироваться в соответствующем журнале 4.4.7. Требования к программному обеспечению Общесистемное ПО, используемое в составе Модуля СЦ, должно быть зарегистрировано в Едином реестре российских программ для электронных вычислительных машин и баз данных и соответствовать рекомендованным показателям эффективности и соответствующим им значениям индикаторов эффективности перехода подведомственных организаций на использование российского ПО, заданных Приказом Минцифры России от 18.01.2023 № 21 «Об утверждении методических рекомендаций по переходу на использование российского программного обеспечения, в том числе на значимых объектах критической информационной инфраструктуры Российской Федерации, и о реализации мер, направленных на ускоренный переход органов государственной власти и организаций на использование российского программного обеспечения в Российской Федерации». Применяемое в системе программное обеспечение должно соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации, постановления Правительства Российской Федерации от 23 декабря 2024 г. № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц» Прикладное программное обеспечение должно отвечать следующим требованиям: – совместимость программных продуктов в части используемых технических средств, системного программного обеспечения и общесистемной инфраструктуры в пределах требований к техническому обеспечению, а также их информационная совместимость в пределах требований к информационному обмену; – обеспечение трехуровневой архитектуры с разделением на уровень хранения данных (сервер БД), уровень бизнес-логики (сервер приложений) и уровень представления ( 4.5.4. Требования к надежности Должно быть предусмотрено сохранение работоспособности Модуля СЦ при некорректных действиях пользователя и сохранение целостности данных при нештатном завершении работы Модуля СЦ (отказ рабочей станции, потеря сетевого доступа и т.п.). Модуль СЦ должен предоставлять механизмы обеспечения сохранности данных через применение процедур резервного копирования и восстановления, описанных в документации на Систему. Ключевые показатели надежности информационной системы — допустимое время на восстановление работоспособности Модуля СЦ (RTO - recovery time objective) и/или допустимый интервал времени потери изменений в данных при сбоях/отказах (RPO – recovery point objective) должны быть определены Подрядчиком и согласованы с Заказчиком на этапе технического проектирования 4.5.5. Требования к информационной безопасности Работы по защите информации/информационной безопасности, не включенные в состав настоящего раздела, требуемые в соответствии с требованиями постановления Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации», а также нормативно правовых актов в области защиты персональных данных и обеспечения безопасности объектов критической информационной инфраструктуры, будут проведены в рамках исполнения отдельного контракта, заключенного по результатам отдельной закупочной процедуры (не является частью данного ТЗ), включающего: – определение актуальных угроз безопасности информации и актуализация модели угроз безопасности информации (при необходимости); – выполнение требований о согласовании технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России в установленном порядке; – выполнение требований по устранению Подрядчиком замечаний и недостатков, в случае их выявления при согласовании Заказчиком технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России; – выполнение требований к классу защищенности ГИС, уровню защищенности персональных данных и категории значимости объекта КИИ РФ, установленных для Головного центра обработки данных ФГБУ «СИЦ Минтранса России» (далее – ГЦОД); 4.5.9.4. Подрядчик подтверждает, что обладает всеми правами на передачу Заказчику исключительных прав в соответствии с требованиями настоящего раздела Технического задания. В случае, если к Заказчику по вине Подрядчика будут предъявлены претензии в этой части, иски третьих лиц, связанные с нарушением их прав, Подрядчик принимает на себя такие претензии и иски и возмещает Заказчику все расходы и весь ущерб, понесенный в связи с ними. 4.5.9.5. Подрядчик обязан согласовать с Заказчиком необходимость использования при выполнении работ охраняемых результатов интеллектуальной деятельности, права на которые принадлежат Подрядчику или третьим лицам. 4.5.9.6. В случае, если при выполнении Работ используется готовое программное обеспечение (платформа, подсистема, СУБД и т.д.), которое становится частью (компонентом) Системы, Заказчику передаются полные исключительные права, или неисключительные права (путем заключения лицензионного/сублицензионного договора/соглашения) на такое программное обеспечение со следующими возможностями: – права передаются бессрочно (на весь срок действия исключительных прав); – территория действия Российская Федерация; – должно быть обеспечено право Российской Федерации (в лице Заказчика) передавать, дорабатывать, распространять, развивать результаты работ, созданные в процессе исполнения Контракта, а также перерабатывать такое программное обеспечение. Лицензионное (сублицензионное) соглашение (договор), Акт передачи прав, подписанные Подрядчиком, согласие правообладателя, оформленное в соответствии с положениями Гражданского кодекса Российской Федерации (в случае, если Подрядчик не является правообладателем такого программного обеспечения), инструкция по инсталляции, руководство администратора, руководство пользователя передаются Заказчику в сроки, установленные Техническим заданием для соответствующего функционала Системы Лицензионное (сублицензионное) соглашение (договор) не может возлагать на Заказчика какие-либо обязанности (в т.ч. в части конфиденциальности, предоставления отчетности), не предусмотренные Контрактом. 4.5.9.7. Передача Заказчику исключительных прав, или простых (неисключительных) прав не может повлечь увеличение стоимости Контракта и/или изменение иных существенных условий Контракта. 4.5.9.8. Функциональность Модуля СЦ передается в объеме и в сроки, установленные Техническим заданием. 4.5.9.9. Нарушение условий настоящего раздела Технического задания, в т.ч. отсутствие соответствующего лицензионного (сублицензионного) соглашения (или договора), либо предоставление лицензионного (сублицензионного) соглашения (или договора), не соответствующего требованиям действующего законодательства Российской Федерации или требованиям Контракта, является нарушением существенных условий Контракта. 4.5.9.10. В случае, если в соответствии с пунктом 4.5.9.6 Заказчику передается исключительное право, такая передача осуществляется в порядке, установленном Гражданским кодексом Российской Федерации. 4.5.9.11. В случае, если при выполнении Работ положения пунктов 4.5.9.5-4.5.9.6 не применялись, Подрядчик в составе отчетной документации предоставляет об этом декларацию в свободной форме. Декларация должна содержать сведения о полном соответствии результата Работ требованиям Контракта, а также о неприменении при выполнении работ готового программного обеспечения (платформ, подсистем, СУБД и т.д.), которое стало частью (компонентом) Системы – определение перечня объектов защиты информационной системы; – описание (актуализированных) требований к системе защиты информации, а также к мерам защиты информации информационной системы в зависимости от установленных классов защищенности, уровня защищенности персональных данных и категории значимости объектов КИИ РФ (приказы ФСТЭК России № 21, 117, 239); – выполнение требований к мерам по защите ГИС от атак, направленных на отказ в обслуживании, в соответствии с пунктами 30, 34, 59, 63 Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений, утвержденных приказом ФСТЭК России от 11.04.2025 № 117; – описание (актуализированных) требований по защите информации, подлежащих реализации в информационно телекоммуникационной инфраструктуре ГЦОД; – выполнение требований о применении сертифицированных средств защиты информации, включая их классы защиты и уровни доверия; – выполнение требований о запрете использования с 01.01.2025 органами (организациями) средств защиты информации странами происхождения, которых являются иностранные государства в соответствии с пунктом 6 Указа Президента Российской Федерации от 01.05.2022 № 250; – выполнение требований по обеспечению непрерывного взаимодействия с ГосСОПКА в установленном порядке; – выполнение требований по обеспечению в автоматизированном режиме с Национальной системой противодействия DDoS-атакам (НСПА) Центра мониторинга и управления сетью связи общего пользования ФГУП «ГРЧЦ» в рамках реализации мер по защите ГИС от атак, направленных на отказ в обслуживании; – детализированные требования к составу и содержанию работ по аттестации, а также к их результатам в соответствии с пунктами 13, 15 и 16 требований приказа ФСТЭК России от 29.04.2021 № 77 «Об утверждении Порядка организации и проведения работ по аттестации объектов информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну» 4.5.9.12. Передача Заказчику комплекта документов, материалов и сведений, предусмотренных нормативными правовыми актами Российской Федерации в сфере информационных технологий, защиты информации, правовой защиты интересов государства в области интеллектуальной собственности, включая документы, подтверждающие отказ авторов (разработчиков) от исключительных прав на передаваемые объекты интеллектуальной собственности в пользу Подрядчика, с проектами заявок на государственную регистрацию в установленном порядке прав Заказчика на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, базы данных, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, осуществляется Подрядчиком в составе отчетной документации, предусмотренной условиями Контракта. 4.5.9.13. По результатам выполнения работ по развитию системы должны быть подготовлены материалы для регистрации доработанной версии Системы (объекта учета) в НФАП в соответствии с требованиями постановления Правительства Российской Федерации от 30 января 2013?г. №?62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин» (с изменениями и дополнениями) в части обязательности размещения результатов работ в национальном фонде алгоритмов и программ для электронных вычислительных машин 4.5.10. Требования по стандартизации и унификации К Модулю СЦ предъявляются следующие требования в части стандартизации и унификации: – работы по развитию Модуля СЦ должны производиться в соответствии с действующими стандартами и нормами Российской Федерации; – при создании и модернизации элементов Модуля СЦ следует руководствоваться действующими в Российской Федерации национальными стандартами и другими нормативно-техническими документами; – используемые оборудование и материалы, подлежащие обязательной сертификации, должны иметь соответствующие сертификаты; – ПО Модуля СЦ должно проектироваться и разрабатываться с учётом обеспечения требований унификации; – применяемые при создании Модуля СЦ технические (форматы данных, протоколы передачи и прочие) и организационные (регламенты, требования, инструкции) решения должны быть доступны и документированы в виде, достаточном для независимой (без обращения к Подрядчику) реализации третьими сторонами; – термины, обозначения и наименования, используемые в ПО, должны быть стандартизованы и унифицированы, выполнены на русском языке; – взаимодействие элементов и их внешнее поведение должно быть реализовано одинаково и производиться по единым правилам 5. СОСТАВ И СОДЕРЖАНИЕ РАБОТ ПО РАЗВИТИЮ И ТЕХНИЧЕСКОЙ ПОДДЕРЖКЕ МОДУЛЯ СЦ (КАЛЕНДАРНЫЙ ПЛАН) Сдача-приемка результатов выполненных работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная техническая документация, а также результаты работ предоставляются Заказчику в порядке, предусмотренном Контрактом и ТЗ, до размещения Подрядчиком в ЕИС документа о приемке. Документ о приемке размещается в ЕИС по каждому этапу в соответствии с условиями Контракта. Этапы выполнения работ по развитию Модуля СЦ приведены в Таблице 11. Таблица 11. Этапы выполнения работ по развитию Модуля СЦ. № этапа Наименование этапа Результат (отчетная документация) Срок исполнения этапа Значение характеристики не может изменяться участником закупки Работы по развитию Системы (за исключением этапов проведения опытной эксплуатации и услуг по технической поддержке) могут быть выполнены досрочно. При досрочном выполнении работ (этапов работ) Подрядчик в письменной форме уведомляет Заказчика о готовности представить для приемки результаты проведения работ в соответствии с требованиями Контракта. Подрядчик также вправе досрочно приступать к работам в рамках очередного этапа при наличии технической, организационной готовности - при условии получения соответствующего согласования Заказчиком. Сдача-приемка результатов выполненных работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная, техническая документация, а также результаты Работ по каждому этапу предоставляется Заказчику в порядке, предусмотренном Контрактом и настоящим Техническим заданием, до размещения Подрядчиком в Единой информационной системе в сфере закупок документа о приемке. Документ о приемке размещается в ЕИС по каждому этапу в соответствии с условиями Контракта. Согласование документов осуществляется в электронном виде посредством переписки с адресов электронной почты Заказчика и Подрядчика, указанных в контракте. 1 Техническое проектирование Сопроводительным письмом предоставляются Заказчику: · Технический проект, включая следующие документы: – Ведомость технического проекта; – Ведомость машинных носителей информации – Пояснительная записка; – Описание информационного обеспечения системы; – Описание автоматизируемых функций; – Схема функциональной структуры; – Описание организации информационной базы; – Описание программного обеспечения; · Макеты экранных форм компонента «Интерактивная карта»; · Руководство по безопасной разработке программного обеспечения; · Документ о приемке Начало: с даты заключения контракта Окончание: не позднее 31.07.2026 2 Услуги по технической поддержке Модуля СЦ (с даты заключения контракта по 10.09.2026) По окончании оказания Услуг сопроводительным письмом предоставляются Заказчику: – Отчет об оказанных Услугах по технической поддержке; – Актуальные на дату окончания оказания Услуг по данному этапу исходные коды прикладного ПО на электронном носителе (в случае внесения изменений); – Инструкция по сборке и развертыванию (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство пользователя (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство администратора (в случае внесения изменений); – Документ о приемке Начало: с даты заключения контракта Окончание: не позднее 10.09.2026 3 Разработка программного обеспечения (1 очередь, пп. 4.2.1, 4.2.6 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ; – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 1 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 1 очереди; – Руководство по резервному копированию; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 16.09.2026 4 Разработка программного обеспечения (2 очередь, пп. 4.2.3, 4.2.4 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ. – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 2 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 2 очереди; – Руководство по резервному копированию; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 25.09.2026 5 Разработка программного обеспечения (3 очередь, пп. 4.2.2, 4.2.5 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ; – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 3 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 3 очереди; – Руководство по резервному копированию; – Описание ролевой модели; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 09.10.2026 6 Опытная эксплуатация (1 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акт о завершении опытной эксплуатации 1 очереди; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке 17.09.2026 Окончание: не позднее 26.10.2026 7 Опытная эксплуатация (2 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акт о завершении опытной эксплуатации 2 очереди; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке 26.09.2026 Окончание: не позднее 26.10.2026 8 Опытная эксплуатация (3 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Акт о завершении опытной эксплуатации 3 очереди; – Документ о приемке Начало: с 10.10.2026 Окончание: не позднее 26.10.2026 9 Приемочные испытания Сопроводительным письмом предоставляются Заказчику: – Программа и методика приёмочных испытаний; – Протокол приемочных испытаний; – Исходные коды и дистрибутивы на электронном носителе (при условии внесения изменений, с учетом доработок по результатам опытной эксплуатации и проведенных испытаний); – Комплект рабочей документации на Модуль СЦ (при условии внесения изменений, с учетом доработок по результатам опытной эксплуатации и проведенных испытаний); – Акт приемки Системы в эксплуатацию; – Акт приемки-передачи исключительных прав на объект; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке; – Документы в соответствии с разделом 4.5.9 ТЗ; – Обеспечение гарантийных обязательств Начало: с 27.10.2026 Окончание: не позднее 10.11.2026 10 Услуги по технической поддержке Модуля СЦ (с 11.09.2026 по 15.12.2026) По окончании оказания Услуг сопроводительным письмом предоставляются Заказчику: – Отчет об оказанных Услугах по технической поддержке; – Актуальные на дату окончания оказания Услуг по данному этапу исходные коды прикладного ПО на электронном носителе (в случае внесения изменений); – Инструкция по сборке и развертыванию (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство пользователя (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство администратора (в случае внесения изменений); – Документ о приемке Начало: с 11.09.2026 Окончание: не позднее 15.12.2026 6. ПОРЯДОК РАЗРАБОТКИ МОДУЛЯ СЦ Проектирование Модуля СЦ должно включать разработку следующих документов: – Ведомость технического проекта; – Ведомость машинных носителей информации – Пояснительная записка; – Описание информационного обеспечения системы; – Описание автоматизируемых функций; – Схема функциональной структуры; – Описание организации информационной базы; – Руководство по безопасной разработке программного обеспечения; – Описание программного обеспечения; – Макеты экранных форм компонента «Интерактивная карта». Структура документов должна соответствовать ГОСТ Р 59795-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов». Разработка Модуля СЦ должна включать в себя: – разработку программного обеспечения в части новых функций Модуля СЦ; – сборка исходного кода, развертывание и настройку доработанного программного обеспечения Модуля СЦ на вычислительных мощностях Заказчика (тестовый контур); – Комплект рабочей документации на Модуль СЦ; – разработку документа «Программа и методика предварительных испытаний»; – разработку документа «Программа и методика приемочных испытаний»; – разработку документа «Программа опытной эксплуатации». Структура документов должна соответствовать ГОСТ Р 59795-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов». В ходе выполнения работ формируется правоустанавливающая, отчетная, рабочая и техническая документация в соответствии с Контрактом и Календарным планом, приведенном в разделе 5. Значение характеристики не может изменяться участником закупки 6.1. Сведения о гарантийном обслуживании Модуля СЦ Под гарантией понимается устранение Подрядчиком своими силами и за свой счет допущенных по его вине недостатков, выявленных после приемки выполненных Работ, как в работе самой Модуля СЦ, так и недостатков в отчетной документации. Если в период гарантийного срока обнаружатся недостатки, то Подрядчик обязан устранить их за свой счет, в сроки, установленные Заказчиком. Гарантийный срок в этом случае продлевается на период устранения недостатков. Срок гарантии: 1 год с даты приемки Заказчиком результатов исполнения Этапа № 9 контракта. Подрядчиком должны быть внесены соответствующие исправления в техническую и рабочую документацию (указанную в пунктах 5 и 6 настоящего ТЗ), связанные с устранением замечаний к работе Модуля СЦ или в случае выявления Заказчиком недостатков в такой документации в период гарантийного срока. Внесение изменений в документацию технического и рабочего проектирования осуществляется в соответствии с ГОСТ 2.503-2023 и ГОСТ Р 2.504-2021. 7. ПОРЯДОК КОНТРОЛЯ И ПРИЕМКИ РЕЗУЛЬТАТОВ ВЫПОЛНЕНИЯ РАБОТ ПО РАЗВИТИЮ МОДУЛЯ СЦ Испытания должны быть организованы и проведены в соответствии с ГОСТ Р 59792-2021 «Информационная технология. Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем». Должны быть проведены следующие виды испытаний: – предварительные испытания; – опытная эксплуатация; – приемочные испытания. Указанные виды испытаний проводятся в отношении не функциональных требований и функциональных возможностей, разрабатываемых в соответствии с настоящим ТЗ. Отдельные виды испытаний проводятся поэтапно в сроки, установленные Календарным планом. Предварительные испытания, опытная эксплуатация, приемочные испытания проводятся комиссией, создаваемой организационно-распорядительным документом Заказчика, который должен определять состав комиссии, порядок ее работы. Методы предварительных испытаний и порядок их проведения должны быть определены в документе «Программа и методика предварительных испытаний», который должен быть утвержден Заказчиком до начала предварительных испытаний. По результатам предварительных испытаний оформляется Протокол предварительных испытания и Акт о приемке в опытную эксплуатацию. Порядок проведения и методы испытаний во время опытной эксплуатации должны быть определены в документе «Программа опытной эксплуатации», который должен быть утвержден Заказчиком до начала опытной эксплуатации. Ход и результаты опытной эксплуатации отражаются в документе «Журнал опытной эксплуатации», и учитываются в ходе приемочных испытаний. По результатам опытной эксплуатации подписывается Акт о завершении опытной эксплуатации Значение характеристики не может изменяться участником закупки До момента подключения внешних ИС, Подрядчиком могут быть использованы эмуляторы ИС для прохождения предварительных испытаний, опытной эксплуатации и приемочных испытаний. В рамках опытной эксплуатации должны быть проведены мероприятия по нагрузочному тестированию Модуля СЦ. Документ «Программа и методика приемочных испытаний» должен быть разработан с учетом недостатков, выявленных в ходе опытной эксплуатации, утвержден Заказчиком до начала приемочных испытаний, при этом проверки Модуля СЦ в части не устраненных недостатков, выявленных в процессе опытной эксплуатации, должны быть вынесены в отдельный раздел «Программы и методики приемочных испытаний». В процессе приемочных испытаний должно быть проверено устранение недостатков, полученных в ходе опытной эксплуатации. После завершения устранения всех замечаний, препятствующих приемке Системы в эксплуатацию, перечисленных в Протоколе приемочных испытаний, Подрядчик должен письменно уведомить Заказчика о том, что все замечания устранены, после чего приемочные испытания по решению Заказчика могут быть проведены повторно. Процедура приемочных испытаний проводится до подписания Протокола приемочных испытаний, не содержащего замечаний, препятствующих приемке Системы в эксплуатацию. Приемочные испытания Системы считаются завершенными успешно, если Протокол приемочных испытаний не содержит замечаний, препятствующих приемке Системы в эксплуатацию 8. ТРЕБОВАНИЯ К СОСТАВУ И СОДЕРЖАНИЮ РАБОТ ПО ПОДГОТОВКЕ МОДУЛЯ СЦ К ВВОДУ В ЭКСПЛУАТАЦИЮ По результатам проведения приемочных испытаний оформляется Протокол приемочных испытаний и Акт приемки в эксплуатацию. В случае, если взаимодействие с внешними системами не может быть проверено на средах постоянной эксплуатации взаимодействующих систем (по причине неготовности со стороны внешней системы или иным причинам), функции взаимодействия, разработанные в соответствии с требованиями ТЗ, должны быть проверены на тестовых данных с использованием программ-имитаторов взаимодействия. По результатам выполнения этапа приемочных испытаний должны быть подготовлены материалы для регистрации доработанной версии Модуля СЦ (объекта учета) в НФАП в соответствии с требованиями постановления Правительства Российской Федерации от 30 января 2013?г. №?62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин» (с изменениями и дополнениями) в части обязательности размещения результатов работ в национальном фонде алгоритмов и программ для электронных вычислительных машин. Сдача-приемка результатов выполнения Работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная, техническая документация, а также программное обеспечение предоставляется Заказчику в порядке, предусмотренном Контрактом и ТЗ до размещения Подрядчиком в Единой информационной системе в сфере закупок документа о приемке. Результаты проведения опытной эксплуатации, предварительных и приемочных испытаний должны быть зафиксированы в соответствующих протоколах и актах. Выявленные отклонения от настоящего ТЗ, оформляются как недостатки Модуля СЦ Значение характеристики не может изменяться участником закупки Протоколы предварительных и приемочных испытаний должны содержать вывод о соответствии Модуля СЦ предъявляемым требованиям, а также сроки устранения замечаний и реализации рекомендаций, сформулированных комиссией в ходе предварительных и приемочных испытаний. Условием для передачи Модуля СЦ в промышленную эксплуатацию является устранение всех замечаний. Документация на Модуль СЦ и ее части (техническая и рабочая) должна содержать исчерпывающее описание принятых проектных решений в объеме, достаточном для ее дальнейшего развития и эксплуатации. Техническая и рабочая документация должна содержать описание разработанных результатов работ, в том числе программ для ЭВМ, прикладных программных интерфейсов, алгоритмов и протоколов информационного взаимодействия, технических требований, спецификаций и форматов обмена данными для взаимодействия с другими информационными системами, в объеме, достаточном для их установки, настройки, эксплуатации и развития в дальнейшем без привлечения Подрядчика. Исходные коды передаются в виде и составе, позволяющем провести: – сборку (компиляцию) Модуля СЦ в контролируемой Заказчиком среде; – установку полученной Модуля СЦ на специально подготовленную контролируемую Заказчиком инфраструктуру; – проверку функциональных возможностей Модуля СЦ; – оформление Модуля СЦ в качестве объекта национального фонда алгоритмов и программ для электронных вычислительных машин 8.1. Требования, предъявляемые в соответствии с Приказом Минцифры России от 17.12.2020 № 715 «Об утверждении типовых условий контрактов на выполнение работ по созданию и (или) развитию (модернизации) государственных (муниципальных) и (или) иных информационных систем» Передача исходных кодов, разработанных в ходе выполнения работ, программ для электронных вычислительных машин (далее – программа для ЭВМ) должна сопровождаться передачей всех необходимых для сборки и запуска программы для ЭВМ библиотек зависимостей, программных сценариев (скриптов) для проведения установки (развертывания) программы для ЭВМ. Подрядчик в процессе сдачи-приемки работ по Контракту должен провести демонстрацию процесса и установки (развертывания) разработанных программ для ЭВМ. Документация на Модуль СЦ должна содержать описание принятых проектных решений в объеме, достаточном для ее дальнейшего развития и эксплуатации 9. ТРЕБОВАНИЯ К ДОКУМЕНТИРОВАНИЮ 9.1. Общие требования Документация на Модуль СЦ должна быть разработана в составе, указанном в разделах 5-8 данного ТЗ, и должна удовлетворять требованиям комплекса стандартов и руководящих документов на автоматизированные системы: – ГОСТ Р 2.105-2019 в части оформления текстовых документов; – ГОСТ 34.201-2020 в части наименования и обозначения документов. Документация на Модуль СЦ должны оформляться на листах формата А4. Допускается для размещения рисунков и таблиц использование листов формата А3 с подшивкой по короткой стороне листа. Документы объемом более 25 (двадцати пяти) листов должны содержать информационную часть, состоящую из аннотации и содержания. Исходные коды должны быть представлены в 1 (одном) экземпляре на электронном носителе, отчетные материалы должны быть представлены в 2 (двух) экземплярах на бумажном носителе (по одному экземпляру для Заказчика и Подрядчика) и в 1 (одном) экземпляре на электронном носителе в формате документов DOCX и PDF. При разработке документов на Модуль СЦ допускается отклонение от требований комплекса стандартов, описанных выше. Документам на Модуль СЦ должны в обязательном порядке присваиваться уникальные децимальные номера в соответствии с порядком, установленном в ГОСТ 34.201-2020. Документ «Программа и методика предварительных испытаний» должен включать приложения с формой протокола предварительных испытаний и формой акта приемки в опытную эксплуатацию. Документ «Программа опытной эксплуатации» должен включать приложение с формой журнала опытной эксплуатации. Документ «Программа и методика приемочных испытаний» должен включать приложения с формой протокола приемочных испытаний и формой акта приемки в эксплуатацию Значение характеристики не может изменяться участником закупки 10. ИСТОЧНИКИ РАЗРАБОТКИ 10.1. Список литературы Специальная литература для разработки ТЗ не использовалась. 10.2. Нормативно-методические документы Список используемых нормативно-методических документов представлен в разделе 1.6 технического задания. ? Приложение А Эскизы визуального оформления компонента «Интерактивная карта» Значение характеристики не может изменяться участником закупки Приложение Б Параметры оказания услуг 1 Режим работы Системы Круглосуточно (24х7) 2 Режим доступности информационно-консультационной поддержки пользователей Системы 2.1 Прием и регистрация обращений (заявок) в СРО Регистрация обращений (заявок) производится круглосуточно в режиме 24х7, без праздников и выходных дней. Обработка заявок первой линией поддержки осуществляется в рабочие дни с 9 до 18 часов 2.2 Консультирование сотрудников Заказчика и пользователей Системы в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 3 Режим доступности по решению инцидентов, связанных с работой ППО: 3.1 - приоритет «Критический» Круглосуточно (24х7) 3.2 - приоритет «Высокий» Круглосуточно (24х7) 3.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 3.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4 Режим доступности услуг по адаптации, конфигурации и коррекционному сопровождению Системы 4.1 - приоритет «Критический» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.2 - приоритет «Высокий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 5 Режим доступности по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности 5.1 - приоритет «Критический» Круглосуточно (24х7) 5.2 - приоритет «Высокий» Круглосуточно (24х7) 5.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 5.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) Значение характеристики не может изменяться участником закупки Таблица Б.1.2. Сроки предоставления отчетности, с момента получения запроса № п/п Параметр Значение 1 Предоставление отчета об оказанных услугах за произвольный период 10 рабочих дней 2 Предоставление подробной информации по инциденту с приоритетом «Критический» 16 рабочих часов 3 Предоставление актуализированной документации 10 рабочих дней Б.2. Приоритеты и регламентные сроки решения обращений (заявок) В зависимости от уровня сбоя в работе Системы обращению (заявке) присваивается один из следующих приоритетов, а также в зависимости от приоритета обращения (заявки) устанавливаются следующие контрольные сроки решения в соответствии с таблицей ниже (Таблица Б.2.1). Таблица Б.2.1 – Приоритеты и регламентные сроки решения обращений (заявок) № п/п Приоритет Максимальное время реагирования Время решения (срок выполнения) Описание приоритета По информационно-консультационной поддержке сотрудников Заказчика и пользователей Системы 1 - не более 1 часа не более 10 часов - По решению инцидентов, связанных с работой ППО: 1 Критический не более 30 минут не более 4 часов - полная недоступность ППО; - недоступность ключевых функций - ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО; - невозможность информационного обмена с ППО для ИС более 4 часов 2 Высокий не более 1 часа не более 8 часов - ошибки/сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; - снижение быстродействия СПО (время отклика ППО на операции превышает 30 секунд); - недоступность управления правами и ролями пользователей 3 Средний не более 4 часов не более 24 часов - невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым -недоступность функции формирования отчетов 4 Низкий не более 8 часов не более 40 часов - отклонение в работе ППО, не влияющее на корректную работу функций; - другие сбои и ошибки, затрагивающие основные функции ППО По адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) 1 Критический не более 40 минут не более 8 часов - изменения, необходимые при проведении аварийно-восстановительных работ для возобновления работоспособности Системы; - изменения, связанные с критичными ошибками, блокирующими возможность оказания государственных услуг и/или чтение и внесение данных в Систему 2 Высокий не более 1 часа не более 40 часов - изменения, относящиеся к обеспечению работоспособности основной функциональности Системы, устраняют выявленные дефекты в работе Системы, оказывающие существенное влияние на работу пользователей в Системе; - изменения, затрагивающие три и более подсистемы/модуля Системы для адаптации 3 Средний не более 4 часов не более 72 часов - изменения, связанные с развитием/улучшением/оптимизацией Системы и выводом новой функциональности в штатном режиме для одного-двух модулей/подсистем; - изменения, связанные с развитием интеграционных механизмов Системы, например обновление существующих и/или реализация новых видов сведений СМЭВ, обновление существующих и/или реализация новых API, адаптация и/или изменение механизмов импорта и экспорта данных Системы и т.д. 4 Низкий не более 8 часов не более 160 часов - изменения, связанные с ошибками/корректировкой/изменением в отображении информации в пользовательском графическом интерфейсе Системы (графика, текст, органы управления, элементы интерфейса) По устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности 1 Критический не более 30 минут не более 24 часов - критические уязвимости, влияющие на возможную полную недоступность ППО, ключевых функций Системы, ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО без возможности восстановления работоспособности Системы. - Критический уровень CVSS > 8.0 2 Высокий не более 1 часа не более 84 часов - критические уязвимости, влияющие на ошибки и сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО. - Высокий уровень CVSS 5.0 - 8.0 3 Средний не более 4 часов не более 120 часов - уязвимости, влияющие на невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым - Средний уровень CVSS 2.0 - 4.9 4 Низкий не более 8 часов не более 160 часов - уязвимости, влияющие на отклонение в работе ППО, не влияющее на корректную работу функций; - другие сбои и ошибки, затрагивающие основные функции ППО - Низкий уровень CVSS < 2.0 Взаимодействие Заказчика и Подрядчика в части регистрации и контроля времени реагирования и решения обращения (заявки) осуществляется через СРО. Заказчик предоставляет Подрядчику доступ к СРО после заключения Контракта. Поступившие от разных пользователей заявки по поводу однотипных инцидентов или имеющие общую причину должны объединяться в одну заявку. Срок выполнения включает время диагностики инцидента, в ходе которого определяется причина инцидента (проблемы) и способ его устранения. Подрядчик должен обеспечить функционирование Модуля СЦ в соответствии с требованиями и параметрами, указанными в настоящем ТЗ и Регламенте оказании услуг. Основные параметры быстродействия типовых операций в Модуле СЦ указаны в таблице ниже (таблица Б.2.2). Таблица Б.2.2 - Параметры быстродействия Модуля СЦ № п/п Наименование параметра Значение (секунд) 1 Среднее время получения сообщения из очереди сообщений 10 2 Среднее время получения ответа от Системы 5 3 Среднее время открытия карточки реестра 5 Б.1. Базовые параметры оказания Услуг Базовые параметры оказания Услуг приведены ниже: – режимы оказания Услуг (таблица Б.1.1); – сроки предоставления отчетности (таблица Б.1.2). Таблица Б.1.1 - Режимы оказания Услуг № п/п Параметр Значение Приложение В Регламент оказания услуг 2.2 Общее описание процесса оказания сопровождения (технической поддержки) Системы Процесс оказания технической поддержки Системы включает: 1. Поступление обращений (заявок) от пользователей и их регистрацию. 2. Сопровождение обращений (заявок) в соответствии с их классификацией и приоритизацией, в том числе, с их последующей эскалацией. 3. Определение ролей и регламент их взаимодействия при осуществлении деятельности по процессу. 4. Решение обращений (заявок) в установленные настоящим Регламентом сроки. 5. Взаимодействие между 1-м, 2-м и 3-м уровнями технической поддержки, в том числе, с формированием заданий для сопровождения Системы. 6. Контроль качества выполняемых Исполнителем работ, состоящий из проверки сценария, приводящего к ошибке, зафиксированной в Инциденте, и/или к ошибке воспроизведения, а также тестирование внесенных изменений в рамках ЗНИ. 7. Обеспечение мониторинга и проведение анализа процесса обработки поступающих в техническую поддержку обращений (заявок). Техническая поддержка реализуется путем проведения ответственными сотрудниками соответствующей информационно-консультационной деятельности в соответствии с определенными ролями, а также выполнения Исполнителем конкретных действий по своевременному выявлению причин сбоев и аварийных ситуаций и их устранению, а также по адаптации, конфигурированию, корректировке Системы, включая выполнение процедур тестирования и участия в обновлениях Системы. Все роли подразделяются на уровни поддержки, взаимодействующие между собой в соответствии с блок-схемой процесса технической поддержки. Общая схема процесса рассмотрения обращений (заявок) в соответствии с видами технической поддержки представлена на рисунке 1. . Рисунок 1 - Общая схема процесса рассмотрения обращений (заявок) в соответствии с видами технической поддержки Значение характеристики не может изменяться участником закупки 2.3 Каналы связи Должна быть предусмотрена омниканальность в части приема обращений (заявок). Получение обращений (заявок) технической поддержкой происходит по следующим каналам связи: – СРО; – электронная почта; – телефонная линия. Исполнитель обеспечивает прием обращений (заявок) от Заказчика и предоставляет информацию в рамках оказания услуг по техническому сопровождению Системы, руководствуясь матрицей взаимодействия, приведенной в Приложении 1 к настоящему Регламенту 3 Порядок оказания Услуг 3.1 Типы обращений (заявок) Обращения и заявки Заказчика классифицируются в соответствии с приоритетами и регламентными сроками, указанными в Приложении 2 к настоящему Регламенту. Регистрация обращений и заявок предусматривает создание новой записи в СРО с присвоением поступившему обращению или заявке (новой записи) уникального идентификатора. Запись в СРО должна содержать вопрос или проблему, которую требуется решить или оказать консультацию. Если обращение или заявка автоматически зарегистрированы в СРО при отправке представителем Заказчика, Исполнитель проверяет корректность указанного типа обращения (заявки) и может обратиться к Заказчику с просьбой корректировки, предоставив обоснования в соответствии с настоящей классификацией (Таблица 1) Таблица 1 - Типы обращений (заявок) Тип обращения (заявки) Описание Запрос на обслуживание Подготовка SQL запроса к СУБД для решения прикладной задачи и д р. – запрос на любое действие, не являющееся запросом информации и несовершенный на основе происшествия, прямо или косвенно влияющего на работу Системы Консультация (входит в тип обращения (заявки) «Запрос на обслуживание») «Где взять / куда обратиться...?», «Как сделать / выполнить…», «Как это работает…?» - запрос, имеющий своей целью получение информационной поддержки Инцидент Разбор ошибок/сбоев и подготовка материалов (корректировочных релизов, инструкций) для Заказчика для устранения ошибок/сбоев, которые приводят к частичному и полному нарушению работоспособности всех или отдельных функций ППО. Подготовка изменения и материалов, необходимых для проведения аварийно-восстановительных работ для возобновления работоспособности Системы. ЗНИ Подготовка изменений, связанных с изменением, улучшением/оптимизацией Системы и выводом новой модифицированной функциональности в штатном режиме. Подготовка изменений, связанных с модификацией существующих и/или реализация новых интеграционных механизмов для получения/обработки данных внешних систем. Подготовка изменений графического интерфейса по требованиям Заказчика 3.2 Участники технической поддержки, осуществляющие сопровождение обращений (заявок) Техническая поддержка Системы должна быть организована на трех уровнях: 1. Первый и второй уровни технической поддержки организуется Заказчиком. 2. Третий уровень технической поддержки организуется Исполнителем. Зона ответственности каждого уровня технической поддержки указана в Таблице 2. Таблица 2 - Зона ответственности каждого уровня технической поддержки Участники технической поддержки Описание Первый уровень технической поддержки (далее – 1-й уровень) Группа ответственных сотрудников 1-го уровня Заказчика, осуществляющая прием и первичную обработку обращений (заявок) (описание предмета обращения, первичная классификация и приоритизация, определение назначения, маршрутизация обращений (заявок) по назначению), руководствуется в своей работе настоящим Регламентом и БЗ, наполняемой 2-м уровнем поддержки, самостоятельно решает часть обращений (заявок), связанных с недостаточной квалификацией пользователей или настройками в рамках своей компетенции. В случае невозможности решения обращений (заявок) на 1-ом уровне ответственный сотрудник передает ее на 2-й уровень Второй уровень технической поддержки (далее – 2-й уровень) Группа ответственных сотрудников 2-го уровня Заказчика по установленным компетенциям (информационная безопасность, сопровождение и эксплуатация информационно-аналитических систем, развитие информационно-аналитических систем, техническая поддержка информационно-аналитических систем) отвечает за поддержание работоспособности Системы, обработку обращений (заявок) и их решение в регламентные сроки в соответствии с установленными приоритетами. Осуществляет информационно-консультационную поддержку пользователей Системы в рамках своей компетенции. Оказывает экспертную помощь ответственным сотрудникам 1-го уровня в части формирования БЗ, содержащей ответы на часто задаваемые вопросы пользователей, с целью передачи знаний, навыков и инструментария на 1-й уровень для ускорения решения обращений (заявок). В случае невозможности решения обращения (заявки) на 2-ом уровне ответственный сотрудник передает его на 3-й уровень. При выявлении необходимости изменений в ППО Системы инициирует формирование обращения (заявки) и направляет его на группу ответственных сотрудников 3-го уровня по соответствующему классификатору (ЗНО, ЗНИ, и т.д.) 4.3. Форма обращения (заявки) на оказание услуг по адаптационному конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) При подаче обращения (заявки) типа «ЗНИ» в СРО указывается (Таблица 7): Таблица 7 – Описание атрибутов формы обращения (заявки) на оказание услуг по адаптационному, конфигурационному и коррекционному сопровождению Системы Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 10) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 9) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 10) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 10) Категория обращения (заявки): запрос на изменение Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 7) Приоритет изменения Время, очередность решения обращения (заявки), ресурсы, привлекаемые для решения обращения (заявки), порядок/процедура действий при решении обращения (заявки) – поле СРО «Приоритет» (см. рисунок 7) Тип изменения Справочник, классифицирующий типовые запросы характерные для Системы – поле СРО «Предмет обращения» (см. рисунок 7) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 7) Текст запроса на оказание услуги по адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 7) На рисунке 7 приведена форма обращения (заявки) типа «ЗНИ» в СРО. Рисунок 7 - Форма обращения (заявки) типа «ЗНИ» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуг по адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей), заполненную в свободной форме 4.4. Форма обращения (заявки) на оказание услуги по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности При подаче обращения (заявки) типа «Инцидент» в СРО указывается (Таблица 8): Таблица 8 – Описание атрибутов формы обращения (заявки) на оказание услуг по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности Третий уровень технической поддержки (далее – 3-й уровень) Группа ответственных сотрудников Исполнителя, отвечающая за устранение сбоев и аварий, проведение информационно-консультационной поддержки пользователей Системы, проведение адаптации и конфигурирования Системы в объемах действующих контрактов на оказание технической поддержки 3.3 Перечень и описание статусов обращений (заявок) В Таблице 3 приведен перечень статусов обращений (заявок), действующий в СРО, и их описание. Таблица 3 - Перечень статусов обращений (заявок) и их описание Статус Описание Зарегистрирован Обращение (заявка) принято и зарегистрировано Направлен в группу Присваивается при назначении ответственными сотрудниками 1-го уровня группе ответственных сотрудников 2-го уровня по тематике обращения (заявки) после заполнения всей необходимой информации и полей обращения (заявки), а также при его передаче между группами 2-го уровня Передан в группу Присваивается при передаче обращения (заявки) ответственными сотрудниками 2-го уровня на группу ответственных сотрудников 3-го уровня Назначен Присваивается при назначении обращения (заявки) на ответственного сотрудника для его решения в рамках компетенции В работе Присваивается при приеме обращения (заявки) в работу ответственным сотрудником для его решения Решен Присваивается ответственным сотрудником, выполнившим работы по обращению (заявке) Закрыт Присваивается автоматически при решении запроса по обращению (заявке), а также отсутствии дополнительных запросов пользователя в соответствии с действующим SLA, или при подтверждении решения обращения (заявки) со стороны пользователя Запрос доп. информации Присваивается при необходимости запроса дополнительной информации и/или уточнения предмета обращения по обращению (заявке) у пользователя Ответ предоставлен Присваивается после ответа пользователем на запрос дополнительной информации Отклонен Присваивается, если обращение (заявка) не актуальна (по информации от пользователя), отсутствует техническая возможность решения обращения (заявки), предмет обращения не входит в компетенции технической поддержки, или существует влияние доработки на другие компоненты, что нарушает общий порядок работы Системы Согласование Присваивается при необходимости согласования направления обращения (заявки) ответственным сотрудником Заказчика на 3-й уровень Анализ Присваивается при проведении анализа на предмет возможности внесения изменений, связанных с развитием/улучшением/оптимизацией Системы и выводом новой функциональности и оценке ресурсоемкости Тестирование Присваивается Исполнителем при завершении разработки и проведенном предварительном тестировании для последующего осуществления приемочного тестирования Специалистом 2-го уровня Релиз Присваивается ответственным сотрудником Заказчика при принятии решения о возможности вывода доработки в продуктивную среду Утверждение заказчиком Присваивается при согласовании группой профильных специалистов на 2-м уровне поддержки с пользователем технического задания для внесения изменений, связанных с развитием/улучшением/оптимизацией Системы и выводом новой функциональности Доработка Присваивается в случае несогласования Заказчиком работ, проведенных Исполнителем в рамках контрактных обязательств, по внесению изменений, связанных с развитием/улучшением/оптимизацией Системы и выводом новой функциональности в штатном режиме, и необходимости последующего направления Исполнителю для ее доработки Отложен Присваивается в случае невозможности выполнения запроса, изложенного в обращении (заявке), в связи с необходимостью запроса дополнительной информации у третьих сторон Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 8) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 8) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 8) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 8) Категория обращения (заявки): инцидент Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 8) Приоритет Время, очередность решения обращения (заявки), ресурсы, привлекаемые для решения обращения (заявки), порядок/процедура действий при решении обращения (заявки) – поле СРО «Приоритет» (см. рисунок 8) Тип изменения Справочник, классифицирующий типовые запросы характерные для Системы – поле СРО «Предмет обращения» (см. рисунок 8) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 8) Текст запроса на оказание услуги по обновлению или удалению уязвимых компонентов (библиотек) ППО в соответствии с требованиями к обеспечению информационной безопасности Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 8) На рисунке 8 приведена форма обращения (заявки) типа «Инцидент» в СРО. Рисунок 8 - Форма обращения (заявки) типа «Инцидент» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуги по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности, заполненную в свободной форме Приложение 1 к Регламенту Матрица ответственных за взаимодействия в рамках выполнения работ по техническому сопровождению Системы Таблица 1 – Ответственные за взаимодействия в рамках выполнения работ по техническому сопровождению Системы со стороны Исполнителя ФИО Должность Адрес электронной почты Телефон — — — Общий контакт Приложение 2 к Регламенту Приоритеты и регламентные сроки решения обращений (заявок) Приоритеты и регламентные сроки решения обращений (заявок) приведены в таблице 1. Таблица 1 – Приоритеты и регламентные сроки решения обращений (заявок) № п/п Приоритет Максимальное время реагирования Время решения (срок выполнения) Описание приоритета По информационно-консультационной поддержке сотрудников Заказчика и пользователей Системы 1 – не более 1 часа не более 10 часов – Термины и сокращения В настоящем регламенте используются следующие термины и сокращения на русском и английском языках: Термины/сокращения Полное наименование/описание БЗ (База знаний) База данных Системы регистрации обращений (заявок), созданная для сбора, хранения и поиска способов решения известных проблем в рамках Системы Жизненный цикл обращения (заявки) Совокупность статусов, по которым проходит обращение (заявка), и правила перехода обращения (заявки) из одного статуса в другой Заказчик ФГБУ «СИЦ Минтранса России» – Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» ЗНИ Запрос на изменение – тип заявки, предполагающий внесение изменений в прикладное программное обеспечение Системы ЗНО Запрос на обслуживание – тип заявки, предполагающий работы по предоставлению консультации, предоставление доступа к Системе или стандартизированные типовые изменения конфигураций Системы Инцидент Тип заявки, классифицируемый как нештатное событие в работе компонентов функциональных задач Системы, которое привело или может привести к нарушению или снижению качества функционирования Системы ИС Информационная система Исполнитель Организация, которая определяется по результатам конкурсных процедур Классификация Анализ и заполнение классификационных полей справочными значениями, определяющими последовательность действий и этапов жизненного цикла заявки, а также порядок рассмотрения заявок Консультация Разъяснения по алгоритму работы, требуемых настроек прикладного программного обеспечения и технологии обработки данных при работе с Системой, предоставление информации Маршрутизация Определение процесса движения обращения (заявки) в Системе управления заявками между уровнями технической поддержки и организационными структурами на уровнях поддержки путем назначения обращения (заявки) в соответствии с его классификацией и выставленным приоритетом Обращение (заявка) Устное или письменное обращение пользователя АСУ ТК с вопросом, касающимся работоспособности АСУ ТК, по одному из определённых каналов связи: электронная почта, Система регистрации обращений (заявок) Пользователь Инициатор обращения (заявки) или пользователь Системы ППО Прикладное программное обеспечение Предмет обращения Справочник, классифицирующий типовые запросы в Системе регистрации обращений (заявок), характерные для Системы, выбранное значение определяет маршрутизацию обращения (заявки) (группу ответственных сотрудников) Приоритизация Значение, определяющее время, очередность решения обращений (заявок), ресурсы, привлекаемые для решения обращений (заявок), . Приоритет устанавливается в соответствии с масштабом выявленной проблемы, которая привела или может привести к нарушению или снижению качества функционирования Системы Релиз Выпуск версии прикладного программного обеспечения Системы, от разработки до тестирования и планового обновления Системы на продуктивной среде для установки изменений, связанных с развитием/улучшением/оптимизацией Системы Система, АСУ ТК, Информационно-аналитическая система регулирования на транспорте Информационно-аналитическая система, предназначенная для автоматизации и информационно-аналитического обеспечения процессов управления развитием транспортного комплекса Российской Федерации, обеспечения публичности деятельности органов государственного управления транспортным комплексом, а также обеспечения процессов оказания государственных услуг в электронном виде в сфере транспорта СМЭВ Система межведомственного электронного взаимодействия СПО Системное программное обеспечение СРО Система регистрации обращений (заявок) Статус обращения (заявки) Текущее состояние обращения (заявки) в жизненном цикле процесса оказания технической поддержки Системы СУБД Система управления базами данных 3.4 Порядок регистрации и сопровождения Заявок Порядок регистрации и сопровождения обращений (заявок) в рамках оказываемых услуг по технической поддержке Системы зависит от типа обращения (заявки): 1. Услуга по решению инцидентов, связанных с работой ППО – тип обращения (заявки) «Инцидент». 2. Услуга по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности – тип обращения (заявки) «Инцидент». 3. Услуга информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы – тип обращения (заявки) «Запрос на обслуживание» (в том числе, консультационный запрос). 4. Услуга адаптационного, конфигурационного и коррекционного сопровождения Системы (в рамках действующих программных модулей и функциональностей) – тип обращения (заявки) «Запрос на изменение». В случае недоступности СРО взаимодействие и информирование Исполнителем о ходе оказания услуги по обращению (заявке), изменению статусов обращений (заявок) осуществляется по согласованию с Заказчиком в соответствии с матрицей взаимодействия, представленной в Приложении 1 к настоящему Регламенту. 3.4.1 Инцидент На рисунке 2 представлена функциональная схема регистрации и сопровождения обращений (заявок) типа «Инцидент». Рисунок 2 - Функциональная схема регистрации и сопровождения обращений (заявок) типа «Инцидент» 3.4.2 Запрос на обслуживание На рисунке 3 представлена функциональная схема регистрации и сопровождения обращения (заявки) типа «ЗНО». Рисунок 3 - Функциональная схема регистрации и сопровождения обращения (заявки) типа «ЗНО» 3.4.3 Запрос на изменение На рисунке 4 представлена функциональная схема регистрации и сопровождения обращений (заявок) типа «ЗНИ». Рисунок 4 - Функциональная схема регистрации и сопровождения обращений (заявок) типа «ЗНИ» 3.5 Порядок классификации и приоритизации обращений (заявок) Классификация является начальной стадией процесса оказания технической поддержки, необходимой для идентификации обращения (заявки) и определения соответствующих действий для его обработки. Для проведения первичной классификации необходимо получить от пользователя и зафиксировать в описании обращения (заявки) подробные сведения о сути запроса, в том числе, для Инцидентов зафиксировать сценарий воспроизведения обнаруженной ошибки. Для проведения вторичной классификации необходимо провести анализ и диагностику для определения корневой причины и затронутой Инцидентом функциональной области (инфраструктура, сеть, ППО). В процессе классификации осуществляется первичная диагностика и оценка проблемы, описанной пользователем Системы в обращении (заявке), в части функционирования и/или удобства использования Системы. Корректная классификация позволяет увеличить скорость обработки обращения (заявки) и решения описанной в обращении (заявке) проблемы при минимальном привлечении ресурсов, в частности, за счет использования известных решений для типовых обращений (заявок), которые должны описываться в БЗ СРО. Классификация позволяет произвести первоначальное назначение обращения (заявки) на ответственного сотрудника и выставить приоритет с учетом приоритизации. Приоритизация применяется для определения критичности описанной в обращении (заявке) проблемы для функционирования ППО Системы. Приоритет рассмотрения обращения (заявки) определяется в процессе ее классификации на основании ряда параметров, вводимых при заполнении обращения (заявки). Приоритизация используется для того, чтобы при одновременном наличии нескольких обращений (заявок) в первую очередь рассматривалась обращения (заявки) с наивысшим приоритетом и не позднее установленных для данного приоритета сроков По решению инцидентов, связанных с работой ППО 1 Критический не более 30 минут не более 4 часов – полная недоступность ППО; – недоступность ключевых функций; – ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО; – невозможность информационного обмена с ППО для ИС более 4 часов 2 Высокий не более 1 часа не более 8 часов – ошибки/сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; – снижение быстродействия СПО (время отклика ППО на операции превышает 30 секунд); – невозможность управления правами и ролями пользователей 3 Средний не более 4 часов не более 24 часов – невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым недоступность функции формирования отчетов 4 Низкий не более 8 часов не более 40 часов – отклонение в работе ППО, не влияющее на корректную работу функций; – другие сбои и ошибки, затрагивающие основные функции ППО По адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) 1 Критический не более 40 минут не более 8 часов – изменения необходимые при проведении аварийно-восстановительных работ для возобновления работоспособности Системы; – изменения, связанные с критичными ошибками, блокирующими возможность оказания государственных услуг и/или чтение и внесение данных в Систему 2 Высокий не более 1 часа не более 40 часов – изменения относящиеся к обеспечению работоспособности основной функциональности Системы, устраняют выявленные дефекты в работе Системы, оказывающие существенное влияние на процесс оказания государственных услуг и работу пользователей в Системе; – изменения, затрагивающие три и более подсистемы/модуля Системы для адаптации 3 Средний не более 4 часов не более 72 часов – изменения, связанные с развитием/улучшением/оптимизацией Системы и выводом новой функциональности в штатном режиме для одного-двух модулей/подсистем; – изменения, связанные с развитием интеграционных механизмов Системы, например, обновление существующих и/или реализация новых видов сведений СМЭВ, обновление существующих и/или реализация новых API, адаптация и/или изменение механизмов импорта и экспорта данных Системы и т.д. 4 Низкий не более 8 часов не более 160 часов – изменения, связанные с ошибками/ корректировкой/изменение в отображении информации в пользовательском графическом интерфейсе Системы (графика, текст, органы управления, элементы интерфейса) По устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности 1 Критический не более 30 минут не более 24 часов – критические уязвимости, влияющие на возможную полную недоступность ППО, ключевых функций Системы, ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО без возможности восстановления работоспособности Системы; – Критический уровень CVSS > 8.0 2 Высокий не более 1 часа не более 84 часов – критические уязвимости, влияющие на ошибки и сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; – Высокий уровень CVSS 5.0 - 8.0 3 Средний не более 4 часов не более 120 часов – уязвимости, влияющие на невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым; – Средний уровень CVSS 2.0 - 4.9 4 Низкий не более 8 часов не более 160 часов – уязвимости, влияющие на отклонение в работе ППО, не влияющее на корректную работу функций; – другие сбои и ошибки, затрагивающие основные функции ППО; – Низкий уровень CVSS < 2.0 Уровень технической поддержки Организационно-структурная часть технической поддержки, имеющая определённые организационно-нормативными документами зоны ответственности, обязанности, а также временные нормативы, в течение которых эти обязательства должны выполняться либо эскалироваться на следующий уровень технической поддержки Услуги Услуги по технической поддержке Информационно-аналитической системы регулирования на транспорте АСУ ТК ФИО Фамилия, имя, отчество Эскалация Процедура повышения внимания к обращению (заявке) путем повышения его приоритета и/или передачи на следующий уровень технической поддержки, а также привлечение ролей, которые могут принимать решения без передачи на следующий уровень технической поддержки API Англ. Application Programming Interface — программный интерфейс приложения, интерфейс прикладного программирования — описание способов (набор классов, процедур, функций, структур или констант), которыми одна компьютерная программа может взаимодействовать с другой программой CVSS Англ. Common Vulnerability Scoring System - открытый стандарт, используемый для расчета количественных оценок уязвимости в безопасности компьютерной системы, обычно с целью понять приоритет ее исправления. В современном инструментарии информационной безопасности используется версия 3.0 и выше с дополнительными метриками к базовым оценкам ID Англ. Identifier – идентификатор, уникальный признак объекта, позволяющий отличать его от других объектов, то есть, идентифицировать SLA Англ. Service Level Agreement - утвержденные условия по обработке обращения (заявки) с установленными метриками времени, которые определяют пороговые значения для эскалации в зависимости от статуса обращения (заявки) (например, время реакции – время от регистрации до осуществления первичной обработки, время решения – время от регистрации обращения (заявки) до его решения и т.д.) SQL Англ. Structured Query Language — «язык структурированных запросов», — декларативный язык программирования, применяемый для создания, модификации и управления данными в реляционной базе данных, управляемой соответствующей СУБД 1 Общие сведения 1.1 Полное наименование Услуг Оказание услуг по технической поддержке Модуля СЦ АСУ ТК в 2026 году. 1.2 Предмет Регламента оказания услуг Требования Технического задания 2 Общие положения 2.1 Цель и задачи оказания услуг Целью технической поддержки Системы является обеспечение ее стабильного и безопасного функционирования и эксплуатации, предупреждение, выявление и устранение сбоев в работе Системы и минимизация их неблагоприятного влияния. Для достижения поставленной цели требуется решение следующих задач: 1. Обеспечение информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы. 2. Поддержание параметров функционирования ППО Системы, удовлетворяющих требованиям производственных процессов, включая их непрерывность. 3. Обеспечение бесперебойного функционирования ППО и своевременное устранение сбоев и аварийных ситуаций в Системе. 4. Своевременное устранение уязвимостей при выявлении таковых, в соответствии с требованиями к обеспечению информационной безопасности. 5. Адаптация, конфигурирование, коррекция программного обеспечения в соответствии с изменениями нормативно-правовой базы и запросами уполномоченных сотрудников органов государственной власти, включая выполнение процедур тестирования и участие в обновлениях ППО на стендах Заказчика. 6. Обеспечение сохранения работоспособности ППО в изменяемой среде эксплуатации. 7. Ведение документации по настоящему контракту и инициирование актуализации документации на Систему по результатам обработки запросов Заказчика и внесения соответствующих изменений в ППО Изменение приоритета уже зарегистрированного обращения (заявки) используется в случае появления новых обстоятельств, которые ведут к изменению влияния и/или срочности существующего обращения (заявки). При регистрации обращения (заявки) необходимо провести его приоритизацию. В процессе управления обращениями (заявками) каждому обращению (заявке) присваивается приоритет, принимающий одно из значений: Низкий, Средний, Высокий или Критический. В соответствии с приоритетом определяется время, очередность устранения, , ресурсы, привлекаемые для работ по обращению (заявке), а также может определяться порядок/процедура действий при работе с обращением (заявкой). Заказчиком в зависимости от уровня сбоя в работе Системы обращению (заявке) присваивается приоритет с указанием максимального времени реакции и решения в соответствии с требованиями, указанными в Приложении 2 к настоящему Регламенту 4 Формы обращений (заявок) на оказание услуг по технической поддержке Системы, заполняемые в СРО 4.1. Форма обращения (заявки) на оказание услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы При подаче обращения (заявки) типа «ЗНО» в СРО указывается (Таблица 5): Таблица 5 – Описание атрибутов формы обращения (заявки) на оказание услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 5) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 5) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 5) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 5) Категория обращения: информационно-консультационная поддержка Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 5) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 5) Текст запроса на оказание услуги по информационно-консультационной поддержке сотрудников Заказчика Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 5) На рисунке 5 приведена форма обращения (заявки) типа «ЗНО» в СРО. Рисунок 5 - Форма обращения (заявки) типа «ЗНО» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы, заполненную в свободной форме. Приложение Г Форма Отчета об оказанных услугах Отчет об оказанных услугах за этап «наименование этапа» в период с «__» _________ по «__» _________. № п/п Наименование услуги Общее количество Номер ОРС Краткое Описание Время реагирования по ТЗ Время реагирования фактическое Время решения по ТЗ Время решения фактическое Результат соблюдения времени реагирования Результат соблюдения времени решения Примечание 1 Услуги по информационно-консультационной поддержке работников Заказчика 2 546782 Консультация по работе Модуля СЦ 1 2 10 часов 11 часов Нет Нет 567123 Консультация по схеме БД 1 1 10 часов 1 час Да Да 2 … … Заказчик Подрядчик /Должность/ /Должность/ ____________________ /Ф.И.О/ ___________________ /Ф.И.О/ М.П. М.П. «_____»_______________________202_г. «_____»_______________________202_г Приложение 1 к Отчету об оказанных услугах Журнал обращений (заявок) на оказание услуги по информационно-консультационной поддержке пользователей Системы (шаблон) Наименование Исполнителя в этапе «наименование этапа» в период с ________________ по _______________ оказал(о) Услугу по поддержке пользователей Системы в объеме, указанном в Таблице 1 Таблица 1 - Журнал обращений (заявок) пользователей Системы № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. ИТОГО зарегистрировано: Всего обращений (заявок): ________ ИТОГО решено: Всего обращений (заявок): ________ Приложение 2 к Отчету об оказанных услугах Журнал обращений (заявок) по решению инцидентов, связанных с работой ППО (шаблон) Наименование Исполнителя в этапе «наименование этапа» в период с ________________ по _______________ оказал(о) Услугу по решению инцидентов в объеме, указанном в Таблице 1. Таблица 1 - Журнал по решению инцидентов № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. ИТОГО зарегистрировано: Всего инцидентов: ________ ИТОГО решено: Всего инцидентов: ________ Приложение 3 к Отчету об оказанных услугах Журнал обращений (заявок) выполнения адаптационного, конфигурационного и коррекционного сопровождения Системы (шаблон) Журнал выполнения адаптации, конфигурации и коррекции Системы сформирован за этап «наименование этапа» в период с «__» _________ по «__» ____________ и представлен в таблице ниже (Таблица 1). Таблица 1 - Журнал выполнения адаптации, конфигурации и коррекции сопровождения Системы № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. Количество выполненных заявок за этап: ________ Приложение 4 к Отчету об оказанных услугах Журнал обращений (заявок) по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности (шаблон) Журнал обращений (заявок) по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности сформирован за этап «наименование этапа» в период с «__» _________ по «__» ____________ и представлен в таблице ниже (Таблица 1). Таблица 1 - Журнал выполнения заявок по устранению уязвимостей в ППО № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. Количество выполненных заявок за этап: ________ 4.2. Форма обращения (заявки) на оказание услуги по решению инцидентов, связанных с работой ППО При подаче обращения (заявки) типа «Инцидент» в СРО указывается (Таблица 6): Таблица 6 – Описание атрибутов формы обращения (заявки) на оказание услуги по решению инцидентов, связанных с работой ППО Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 6) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 6) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 6,) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 6) Категория обращения (заявки): инцидент Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 6) Приоритет изменения Время - одно из значений: Низкий, Средний, Высокий или Критический. Определяет, очередность решения обращения (заявки), ресурсы, привлекаемые для решения обращения (заявки), порядок/процедура действий при решении обращения (заявки) – поле СРО «Приоритет» (см. рисунок 6,) Тип изменения Справочник, классифицирующий типовые запросы характерные для Системы – поле СРО «Предмет обращения» (см. рисунок 6) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 6) Полное описание инцидента, включая скриншоты и описание шагов, приведших к неисправности Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 6) Однократность/неоднократность Круг пользователей или компьютеров, затронутых данным инцидентом Действия, предпринятые для самостоятельного решения инцидента (при наличии) Версии используемого программного обеспечения на клиентской рабочей станции, где воспроизводится ошибка (операционная система, прикладное программное обеспечение) Дополнительная информация На рисунке 6 приведена форма обращения (заявки) типа «Инцидент» в СРО. Рисунок 6 - Форма обращения (заявки) типа «Инцидент» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуги по решению инцидентов, связанных с работой ППО, заполненную в свободной форме Приложение Д Форма Протокола проверки результатов организационно-штатных и подготовительных мероприятий (шаблон) Протокол проверки результатов организационно-штатных и подготовительных мероприятий Настоящий Протокол содержит результаты проверки организационно-штатных и подготовительных мероприятий, проведенных Исполнителем (Таблица Д.1). Таблица Д.1. Протокол проверки результатов № Мероприятия Подготовительного этапа Результат проверки 1. Определить и направить Заказчику документ «Ответственные за взаимодействия в рамках выполнения работ по техническому сопровождению Системы со стороны Исполнителя». Документ содержит контактную информацию (ФИО, должность, адрес электронной рабочей почты, номер телефона) не менее чем о 2 лицах, ответственных за оказание услуг со стороны Подрядчика Выполнено/Не выполнено 2. Обеспечить подключение специалистов Подрядчика к Системе Выполнено/Не выполнено 3. Обеспечить подключение специалистов Подрядчика к СРО Выполнено/Не выполнено Заказчик Подрядчик /Должность/ /Должность/ ____________________ /Ф.И.О/ ___________________ /Ф.И.О/ М.П. М.П. «_____»_______________________202_г. «_____»_______________________202_г - Наименование характеристики - Значение характеристики - Единица измерения характеристики - Инструкция по заполнению характеристик в заявке - ОПРЕДЕЛЕНИЯ, ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ - Автоматизированная система (АС) Система, состоящая из комплекса средств автоматизации, реализующего информационную технологию выполнения установленных функций, и персонала, обеспечивающего его функционирование (ГОСТ Р 59853-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения») АРМ Автоматизированное рабочее место АСУ ТК, Система Информационно-аналитическая система регулирования на транспорте АТС Автоматическая телефонная станция БД База данных ГИС Государственная информационная система ГОСТ Государственный стандарт ГЦОД СИЦ Минтранса России, ГЦОД Головной центр обработки данных ФГБУ «СИЦ Минтранса России» Дашборд Интерактивная аналитическая панель, графический интерфейс. ЕИС Единая информационная система в сфере закупок ЕСИА Единая система идентификации и аутентификации Заказчик Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» КИИ Критическая информационная инфраструктура Кластер Кла?стер (англ. cluster) – объединение нескольких однородных элементов, которое может рассматриваться как самостоятельная единица, обладающая определёнными свойствами Компонент Часть АС, выделенная по определенному признаку или совокупности признаков и рассматриваемая как единое целое (ГОСТ Р 59853-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения») Контракт Контракт на выполнение работ по развитию и оказанию услуг по технической поддержке Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК в 2026 году, заключаемый по результатам проведения конкурентной процедуры закупки в соответствии с требованиями Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» - - Значение характеристики не может изменяться участником закупки - Модуль iМинтранс Модуль сбора данных и представления показателей деятельности Министерства транспорта Российской Федерации iМинтранс АСУ ТК Модуль СЦ Модуль сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК НС Нештатная ситуация НСИ Нормативно-справочная информация ОТИ Объект транспортной инфраструктуры П-ГИС Геоинформационная подсистема П-ИВ Подсистема информационного взаимодействия П-НСИ Подсистема ведения нормативно-справочной информации и метаданных ПО Программное обеспечение Подрядчик, Исполнитель Организация, с которой будет заключен контракт на выполнение работ по развитию Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК П-СД Подсистема сбора данных Работы Работы по развитию Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК СЗИ Средство защиты информации СМЭВ Система межведомственного электронного взаимодействия СУБД Система управления базами данных ТЗ Техническое задание (настоящий документ) ТС Транспортное средство ТК Транспортный комплекс Учреждение Учреждения в области информационной безопасности - ФГБУ «СИЦ Минтранса России» Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации», Заказчик Федеральный закон № 44-ФЗ Федеральный закон от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» ФЗ Функциональная задача ФЗ «Реестр объектов» Функциональная задача «Формирование и ведение единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации» ФСБ России Федеральная служба безопасности Российской Федерации ФСТЭК России Федеральная служба по техническому и экспортному контролю ЧС Чрезвычайная ситуация ЭВМ Электронно-вычислительная машина API От англ. Application Programming Interface – интерфейс прикладного программирования – совокупность инструментов и функций в виде интерфейса для взаимодействия с программой CSS От англ. Cascading Style Sheets — каскадные таблицы стилей FPS От англ. frame per second - количество кадров в секунду HTML От англ. HyperText Markup Language - стандартный язык разметки документов, создающий основу и структуру всех веб-страниц JSON От англ. JavaScript Object Notation – текстовый формат обмена данными, основанный на JavaScript WebAssembly (Wasm) Открытый стандарт, представляющий собой низкоуровневый бинарный формат инструкций, который позволяет выполнять код, написанный на языках C++, Rust или Go, в браузерах с производительностью, близкой к нативной - 1. ОБЩИЕ СВЕДЕНИЯ - 1.1. Наименование Системы Полное наименование системы: Информационно-аналитическая система регулирования на транспорте. Условное обозначение системы: АСУ ТК. Полное наименование модуля: Модуль сбора, ведения и анализа информации о нештатных ситуациях на транспорте. Условное обозначение модуля: Модуль СЦ. Модуль СЦ создан в рамках контракта от 05.08.2024 № ОК/24_04 на выполнение работ по развитию АСУ ТК в части создания модуля «Сбора, ведения и анализа информации о нештатных ситуациях на транспорте». Развитие Модуля СЦ осуществлено в рамках контракта от 19.05.2025 № ОК/25_09 на выполнение работ по развитию Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК - - Значение характеристики не может изменяться участником закупки - 1.2. Шифр темы или номер контракта Присваивается Заказчиком по результатам организации закупочных процедур. 1.2.1. Предмет контракта Выполнение работ по развитию Модуля СЦ. Код по ОКПД2: 62.01.11.000 – услуги по проектированию и разработке информационных технологий для прикладных задач и тестированию программного обеспечения. Оказание услуг по технической поддержке Модуля СЦ. Код по ОКПД2: 62.02.30.000 – услуги по технической поддержке информационных технологий. Выполнение работ по развитию Модуля СЦ предусмотрено с учетом ключевых результатов (ОКР) Ведомственной программы цифровой трансформации Минтранса России на 2026-2028 (далее - ВПЦТ Минтранса России) в составе мероприятия № 103.002 «АСУ ТК» ИТ расхода 103.26.000005 «Развитие Информационно-аналитической системы регулирования на транспорте (АСУ ТК)»: · «Обеспечено информационное взаимодействие с Минобороны о происшествиях на транспортных объектах»; · «Обеспечена автоматизация формирования отчетов о нештатных ситуациях на транспорте, в том числе по данным внешних систем». Выполнение работ по технической поддержке АСУ ТК предусмотрено ВПЦТ Минтранса России в составе мероприятия № 103.002 «АСУ ТК» ИТ расхода 103.26.000021 «Эксплуатация Информационно-аналитической системы регулирования на транспорте (АСУ ТК)» - 1.3. Заказчик Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» (ФГБУ «СИЦ Минтранса России»). Адрес: 107078, Москва, Садовая-Спасская ул., д.18, стр. 1. Оператором Системы является Заказчик - Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» (ФГБУ «СИЦ Минтранса России) - 1.4. Подрядчик Определяется по результатам проведения конкурентной процедуры закупки в соответствии с требованиями Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (далее – Федеральный закон № 44-ФЗ) - 1.5. Основания для выполнения работ Работы осуществляются на основании следующих документов: – постановление Правительства Российской Федерации от 30.12.2003 № 794 «О единой государственной системе предупреждения и ликвидации чрезвычайных ситуаций»; – постановление Правительства Российской Федерации от 08.11.2013 № 1007 «О силах и средствах единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций»; – распоряжение Правительства Российской Федерации от 27.11.2021 № 3363-р «О Транспортной стратегии Российской Федерации до 2030 года с прогнозом на период до 2035 года»; – Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 26.08.2025 №ЕФ-3; – Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 27.11.2025 №ЕФ-23; - – приказ Минкомсвязи России от 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 «Национальный стандарт Российской Федерации. Интеллектуальная собственность. Патентные исследования. Содержание и порядок проведения»; - – Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 19.02.2026 №ЕФ-1; – План мероприятий по профилактике случаев непроизводственного травматизма граждан на железнодорожном транспорте, являющийся приложением к постановлению коллегии Министерства транспорта Российской Федерации от 11.03.2026 № 2 - 1.6. Перечень документов, требования которых должны быть учтены при выполнении работ – Федеральный закон Российской Федерации от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации»; – Федеральный закон Российской Федерации от 27.07.2006 № 152-ФЗ «О персональных данных»; – Федеральный закон Российской Федерации от 06.04.2011 № 63-ФЗ «Об электронной подписи»; – Федеральный закон Российской Федерации от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации»; – Указ Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации»; – Указ Президента Российской Федерации от 01.05.2022 № 250 «О дополнительных мерах по обеспечению информационной безопасности Российской Федерации»; – Указ Президента Российской Федерации от 31.03.2010 № 403 «О создании комплексной системы обеспечения безопасности населения на транспорте»; – постановление Правительства Российской Федерации от 30.07.2004 № 395 «Об утверждении Положения о Министерстве транспорта Российской Федерации»; – постановление Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации»; – постановление Правительства Российской Федерации от 16.11.2015 № 1236 «Об установлении запрета на допуск программного обеспечения, происходящего из иностранных государств, для целей осуществления закупок для обеспечения государственных и муниципальных нужд»; – постановление Правительства Российской Федерации от 23.12.2024 № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц»; - – ГОСТ Р 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.7. Сроки начала и окончания работ Начало работ: с даты заключения Контракта. Окончание работ: не позднее 15.12.2026. Работы выполняются в соответствии с этапами. Сроки выполнения этапов работ по развитию и технической поддержке Модуля СЦ определяются Календарным планом. Календарный план, приведен в разделе 5 настоящего ТЗ - – постановление Правительства Российской Федерации от 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 Федерального закона «Об электронной подписи»; - – постановление Правительства Российской Федерации от 08.06.2011 № 451 «Об инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг и исполнения государственных и муниципальных функций в электронной форме»; – постановление Правительства Российской Федерации от 30.01.2013 № 62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин»; – приказ ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации»; – приказ ФСТЭК России от 11.04.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений»; – приказ ФСБ России от 18.03.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений, с использованием шифровальных (криптографических) средств»; – приказ ФСБ России от 10.07.2014 № 378 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных с использованием средств криптографической защиты информации, необходимых для выполнения установленных Правительством Российской Федерации требований к защите персональных данных»; - 1.8. Общие сведения об источниках и порядке финансирования работ Источником финансирования являются средства субсидии федерального бюджета Российской Федерации, предоставленной в соответствии с абзацем вторым пункта 1 статьи 78.1 Бюджетного кодекса Российской Федерации (код цели 08-01) - 1.9. Порядок оформления и предъявления результатов работ Подрядчик должен передать Заказчику результаты работ в порядке, определенном Контрактом в сроки, установленные п. 5 настоящего ТЗ, в соответствии с Календарным планом - 1.10. Место выполнения Работ Работы выполняются удаленно на комплексе технических средств Заказчика. Адрес размещения комплекса технических средств Заказчика: Московская обл., Богородский район, пос. Горбуша, Радиоцентр. Техническая возможность удаленного подключения обеспечивается Заказчиком (в части предоставления параметров доступа). Оплата телематических и иных услуг, технических и программных средств, необходимых Подрядчику для удаленного подключения и для выполнения требований по информационной безопасности, осуществляется Подрядчиком самостоятельно за свой счет - 2. ЦЕЛИ И НАЗНАЧЕНИЕ ВЫПОЛНЕНИЯ РАБОТ - 2.2. Назначение и цели развития и технической поддержки Модуля СЦ Назначение Модуля СЦ: – оперативный мониторинг нештатных и чрезвычайных ситуаций на транспорте ; – оповещение заинтересованных лиц и структур о нештатных и чрезвычайных ситуациях; – сбор, обработка и хранение данных о нештатных и чрезвычайных ситуациях. Целями развития Модуля СЦ являются: – расширение состава данных об оперативной обстановке на транспорте; – оптимизация процесса сбора данных об оперативной обстановке на транспорте; – повышение информированности пользователей за счет визуализация данных Модуля СЦ; – автоматизация процесса формирования отчетов о ЧС и нештатной ситуации на транспорте; – обеспечение информационного взаимодействия с заинтересованными организациями по вопросам ведения. - - Значение характеристики не может изменяться участником закупки - Целями оказания услуг по технической поддержке являются: – обеспечение информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы; – поддержание параметров функционирования ППО Системы, удовлетворяющих требованиям производственных процессов, включая их непрерывность; – обеспечение бесперебойного функционирования ППО и своевременное устранение сбоев и аварийных ситуаций в Системе; – своевременное устранение уязвимостей при выявлении таковых, в соответствии с требованиями к обеспечению информационной безопасности; – адаптация, конфигурирование, коррекция программного обеспечения в соответствии с изменениями нормативно-правовой базы и запросами уполномоченных сотрудников органов государственной власти, включая выполнение процедур тестирования и участие в обновлениях ППО на стендах Заказчика; – обеспечение сохранения работоспособности ППО в изменяемой среде эксплуатации; – ведение документации по настоящему ТЗ, инициирование и актуализация документации на Систему по результатам обработки запросов Заказчика и внесении соответствующих изменений в ППО. Модуль СЦ применяется в деятельности Министерства транспорта Российской Федерации, подведомственных агентств и службы и другими организациями в соответствии с соглашениями об информационном обмене - 2.1. Назначение АСУ ТК АСУ ТК предназначена для автоматизации и информационно-аналитического обеспечения процессов управления развитием транспортного комплекса Российской Федерации, обеспечения публичности деятельности органов государственного управления транспортным комплексом. Основными целями АСУ ТК являются: – повышение эффективности процессов управления функционированием и развитием транспортного комплекса на основе создания единой информационной среды и комплекса информационно-аналитических услуг на уровне органов государственного управления ТК; – повышение уровня безопасности ТК на базе получения полной, достоверной и оперативной информации о происходящих изменениях, своевременного выявления негативных тенденций и для принятия соответствующих мер по их устранению и ликвидации последствий - Основными задачами АСУ ТК являются: – автоматизация процессов прогнозирования развития транспортного комплекса и поддержки принятия управленческих решений; – автоматизация процессов мониторинга безопасности и устойчивости транспортного комплекса, управления в чрезвычайных и нештатных ситуациях; – автоматизация процессов управления программами и проектами развития и модернизации транспортного комплекса; – автоматизация процессов мониторинга состояния транспортного комплекса, в том числе с использованием набора ключевых показателей эффективности деятельности транспортного комплекса; – информационно-технологическая поддержка взаимодействия субъектов транспортного комплекса Российской Федерации, органов государственного управления и контроля, международных организаций на основе создания единой технологической среды взаимодействия и управления движением данных (и связанных с ними документов) в транспортном комплексе; – использование в процессах управления транспортным комплексом РФ современных технологий электронного документооборота и электронного обмена данными; – организация межведомственного электронного взаимодействия подразделений Министерства транспорта Российской Федерации, подведомственных агентств и службы с другими организациями - 3. ХАРАКТЕРИСТИКА ОБЪЕКТА АВТОМАТИЗАЦИИ - 3.3. Состав используемого ПО Модуля СЦ Программная архитектура Модуля СЦ разработана как трехуровневая клиент-серверная архитектура. Архитектура включает в себя следующие уровни: • уровень представления – презентационный уровень, обеспечивающий взаимодействие с пользователя с клиентскими приложениями с использованием веб-браузера («тонкий» клиент); • уровень приложений – реализован в виде сервисов, обеспечивает обработку запросов, поступающих от клиентских приложений, формирование ответов на запрос в доступном пользователю виде (формирование пользовательских интерфейсов); • уровень хранения данных – реализуется как сервер БД и обеспечивает хранение и целостность хранимых данных, создание резервных копий, ведение журнала транзакций, восстановление данных после сбоев. Программная архитектура Модуля СЦ включает в себя сервисы и интерфейсы, указанные в Таблице 3. Таблица 3. Программная архитектура Модуля СЦ Программный сервис/интерфейс Технологии реализации Уровень представления Интерфейс пользователя и администратора (front-end) Javascript Уровень приложений Сервис (GateWay) Kotlin Сервис геокодирования (geocoding-service) Kotlin Сервис уведомлений (notifiсation-service) Kotlin Сервис работы с файлами (file-service) Kotlin Сервис отчетности (report-service) Kotlin Сервис управления событиями (event-service) Kotlin Сервис информирования через мессенджер (messenger-notifier) Python Сервис внешних интеграций (integration-service) Сбор информации из внешних систем и сервисов Брокер сообщений Kafka Уровень хранения данных Файловое хранилище MinIO S3 СУБД Postgres Pro Enterprise - - Значение характеристики не может изменяться участником закупки - 3.4. Информационное взаимодействие программных сервисов и интерфейсов Модуля СЦ Объект автоматизации функционирует в распределенной информационной среде. Обмен данными осуществляется по защищенным каналам связи (в том числе ведомственным сетям передачи данных). Источники информации включают: · внешние автоматизированные системы (органов государственной власти); · внутренние базы данных (реестры объектов транспортной инфраструктуры, паспорта регионов и пр.); · оперативная информация от персонала, поступающая через автоматизированные рабочие места (АРМ) и мобильные устройства. 3.4.1. Взаимодействие Модуля СЦ со смежными подсистемами АСУ ТК Модуль СЦ входит в состав АСУ ТК и взаимодействует со следующими ее функциональными задачами и подсистемами: · Функциональной задачей «Формирование и ведение единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации» (ФЗ «Реестр объектов»); · Геоинформационной подсистемой АСУ ТК (П-ГИС); · Подсистемой ведения нормативно-справочной информации и метаданных (П-НСИ); · Подсистемой сбора данных и централизованное хранилище данных (П-СД); · Подсистемой информационного взаимодействия (П-ИВ). 3.4.2. Взаимодействие с внешними информационными системами Список внешних информационных систем, с которыми осуществляется взаимодействие Модуля СЦ: · ЕСИА; · мессенджер; · Яндекс Геокодер; · Информационная система «Централизованная система сбора информации систем-112»; · ПВК «Поиск-Море», АИС РПТ; · облачная АТС - 3.5. Требования к эксплуатации Применяемое в Системе программное обеспечение, программно-аппаратные и аппаратные комплексы должны соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации» - 3.1. Описание объекта автоматизации АСУ ТК Объектом автоматизации являются процессы основной и обеспечивающей деятельности, направленные на управление транспортным комплексом, в том числе, процессы информационного взаимодействия с другими организациями и субъектами транспортного комплекса. АСУ ТК относится к государственным информационным системам, а также к информационным системам персональных данных и значимым объектам критической информационной инфраструктуры Российской Федерации. АСУ ТК соответствует требованиям, предъявляемым к: – ГИС второго класса защищенности в соответствии с приказом ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах»; – ИС персональных данных при обеспечении третьего уровня защищенности персональных данных в соответствии с требованиями постановления Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»; – значимым объектам КИИ Российской Федерации второй категории значимости с постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении Правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений». Модуль СЦ является подсистемой АСУ ТК. Перечень платформенных решений и функциональных задач АСУ ТК представлен в Таблице 1 - Таблица 1 – Перечень платформенных решений и функциональных задач АСУ ТК № Наименование подсистемы/ функциональной задачи/ модуля Назначение 1 Подсистема сбора данных и централизованного хранилища данных Подсистема обеспечивает выполнение сбора данных в АСУ ТК, и в т. ч., в рамках функциональных задач «Формирование и ведение межрегионального транспортного баланса пассажирских перевозок в дальнем (межрегиональном) сообщении» и «Формирование и ведение транспортного паспорта региона» 2 Подсистема информационного взаимодействия Подсистема информационного предназначена для обеспечения информационного взаимодействия подсистем АСУ ТК, а также, взаимодействия АСУ ТК с АС федеральных органов исполнительной власти 3 Подсистема ведения нормативно-справочной информации и метаданных Подсистема предназначена для автоматизации функций формирования и актуализации справочников, классификаторов, реестров и регистров, необходимых для обеспечения информационной поддержки пользователей НСИ и интеграции подсистем АСУ ТК в части применения НСИ 4 Модуль СМЭВ Модуль взаимодействия со СМЭВ представляет собой набор сервисов взаимодействия: сервис синхронного взаимодействия и сервис отправки, осуществляющих дополнительную обработку сообщений, отправляемых в СМЭВ и принимаемых из СМЭВ 5 Геоинформационная подсистема Программное обеспечение геоинформационной подсистемы предназначено для обеспечения смежных подсистем АСУ ТК возможностью работы с картографической информацией, в том числе, отображения на электронных картах объектов транспортной инфраструктуры и получения информации о местоположении, характеристиках контролируемых транспортных объектов 6 Подсистема информационного портала АСУ ТК Подсистема информационного портала предназначена для отображения и входа в функциональные задачи АСУ ТК 7 Подсистема технического портала АСУ ТК Подсистема технического портала АСУ ТК предназначена для управления заявками пользователей и технологического документооборота заявок - 8 Подсистема проектного архива АСУ ТК Подсистема проектного архива АСУ ТК предназначена для автоматизации деловых процессов должностных лиц Министерства транспорта Российской Федерации, подведомственных агентств и службы, в том числе, и процессов информационного взаимодействия внутреннего и внешнего характера 9 ФЗ «Реестр объектов» Функциональная задача предназначена для формирования и ведения единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации 10 ФЗ «СТП» Функциональная задача предназначена для организации информационно-аналитической поддержки процессов территориального планирования Российской Федерации в области федерального транспорта 11 ФЗ «МРТБ ПП» Функциональная задача предназначена для формирования и ведения межрегионального транспортного баланса пассажирских перевозок в дальнем (межрегиональном) сообщении 12 ФЗ «МДД» Функциональная задача предназначена для осуществления мониторинга дорожного движения 13 ФЗ «ТПР» Функциональная задача предназначена для формирования и ведения транспортного паспорта региона 14 ФЗ «Данные по грузообороту» Функциональная задача предназначена для обеспечения подсистем и пользователей АСУ ТК данными по грузообороту между Российской Федерацией и зарубежными странами 15 ФЗ «МЖТ» Функциональная задача предназначена для осуществления мониторинга железнодорожного транспорта 16 ФЗ «МГМП» Функциональная задача предназначена для осуществления мониторинга грузопотоков в морских портах с целью формирования единой цифровой среды мониторинга и планирования перевозок в/из портов Дальнего Востока - 17 Модуль ГЭТ Модуль предназначен для получения, хранения данных инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по отдельно взятому предприятию-перевозчику. Формирования отчетов об инвентаризации с детальными данными по каждому разделу инвентаризации с маршрутизацией в муниципалитет / регион / Минтранс. Содержит агрегированные данные инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по всем перевозчикам, относящихся к данному муниципалитету. Формирует сводный отчет по муниципалитету по каждому разделу инвентаризации с маршрутизацией в регион / Минтранс. Формирует агрегированные данные инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по всем перевозчикам, относящиеся к данному региону и по всем муниципалитетам, относящимся к данному региону. Аналитические и статистические данные о состоянии ГЭТ региона. Содержит данные о видах транспорта, цифровых транспортных сервисах и платежных инструментах Региона. Формирует сводный отчет по каждому разделу инвентаризации с маршрутизацией в Минтранс. Формирует агрегированную статистику и аналитику по всем регионам страны в разрезе транспортных средств, маршрутов, пассажиропотоков, инфраструктуры ГЭТ. Данные о рейтинге регионов и перевозчиков на основании выбранных параметров, документооборот с участниками Системы: получение подписанных печатных форм, их утверждение, возврат на доработку. 18 Модуль iМинтранс Модуль создан для отчета по ключевым показателям транспортного комплекса России (Отраслевые и статистические показатели, исполнение бюджета, исполнение поручений, аналитика СМИ, происшествия по видам транспорта). 19 Модуль СЦ Модуль СЦ предназначен для оперативного мониторинга нештатных ситуаций транспортной отрасли, оповещения заинтересованных лиц и структур и предоставления данных о нештатных ситуациях - АСУ ТК осуществляет идентификацию и авторизацию посредством Единой системы идентификации и аутентификации (ЕСИА). Информационный обмен с внешними информационными системами осуществляется посредством СМЭВ 3 и СМЭВ 4. АСУ ТК развернута на вычислительных мощностях ГЦОД СИЦ Минтранса России - 3.2. Описание и текущее состояние объекта автоматизации Модуля СЦ Объектом автоматизации является процесс организации мониторинга информации о НС и ЧС на транспорте. Предметом деятельности Учреждения являются следующие функции: – информационное обеспечение в области транспортной безопасности, защиты населения и территорий от чрезвычайных ситуаций природного и техногенного характера в транспортном комплексе; – подготовка справочных материалов при угрозе возникновения и возникновении чрезвычайных ситуаций и иных происшествий в транспортном комплексе; – взаимодействие и обмен оперативной информацией с органами управления Единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций; – организация оперативного мониторинга обстановки на объектах транспорта при угрозе и возникновении чрезвычайных ситуаций и иных происшествий. Перечень компонентов Модуля СЦ и выполняемые ими функции представлены в Таблице 2 - Таблица 2. Перечень компонентов Модуля СЦ и их функции № п/п Компонент Выполняемые функции 1 Регистрация событий – ведение карточки события; – удаление комментария; – динамическое отображение существующих событий в заданном радиусе и за заданный период; – возможность автоматической проверки вводимых данных в части количества пострадавших; – отображение карточки ОТИ, ТС в соответствии с ФЗ Реестр объектов; – сохранение и отображение версии карточки события; – привязка события к координатам по картографической основе; – указание признака выполнения действия по отработке события; – перевод статуса события; – закрытие карточки события; – публикация информации о событии в канале мессенджера; – возможность перехода из карточки события на картографическую основу для просмотра местоположения события 2 Визуализация – отображение событий на картографической основе в виде пиктограмм; – масштабирование карты; – отображение краткой карточки события при выборе события на картографической основе; – отображение списка событий; – отображение карточки события; – отображение журнала действий пользователя; – отображение дополнительной информации (текстовая информация и приложенные файлы); – отображение справки о событиях и отчета о событиях; – отображение фильтров и количества отфильтрованных объектов; – отображение результатов поиска; – отображение статистики по событиям на экране; – возможность создания события с картографической основы; – отображения картографических слоев в зависимости от примененных фильтров; – возможность настройки шага картографической сети; – возможность настройки географической точки центра карты; – отображение количества непрочитанных сообщений; – возможность перехода к детальной карточке события из краткой карточки события при выборе события на картографической основе - 3 Информирование – ведение справочника способов оповещения (веб-интерфейс, мессенджер); – формирование сценария выполнения оповещения (настройка условий, способа, параметров оповещения); – выполнение оповещений пользователей 4 Отчетность – формирование отчета и справки о событиях; – фильтрация событий для выгрузки в справку о событиях или в отчет о событиях 5 Администрирование – ведение ролей пользователей; – ведение учетных данных пользователей; – ведение справочника организаций; – ведение справочника групп системы мгновенного обмена сообщениями; – выполнение исходящего звонка на контактный телефонный номер организации; – формирование матрицы эскалации событий Архитектура Модуля СЦ представлена на рисунке 1. Рисунок 1. Архитектура Модуля СЦ - 4. ТРЕБОВАНИЯ К МОДУЛЮ СЦ - 4.4.7.1. Требования к инструментам разработки и процессу контроля версий программного обеспечения 4.4.7.1.1. Система контроля версий Для управления исходным кодом должна использоваться система контроля версий кода, развернутая в инфраструктуре Заказчика. 4.4.7.1.2. Правила именования веток Имя ветки должно соответствовать следующему формату: / / Категории веток: ? feature/ — разработка новой функциональности, а также рефакторинг или удаление существующей; ? fix/ — исправление ошибок; ? hotfix/ — срочные исправления, применяемые в обход стандартного процесса разработки; ? test/ — для проведения экспериментов, не влияющих на основную разработку. Идентификатор задачи: после категории указывается ссылка на задачу (issue) в системе контроля версий кода. Описание: добавляется краткое описание решаемой задачи в формате kebab-case (слова разделяются дефисами, например, add-user-auth). Примеры именования веток: ? feature/#123/add-payment-integration; ? fix/#45/correct-calculation-logic; ? hotfix/#67/urgent-database-connection-patch. 4.4.7.1.3. Правила именования коммитов Сообщение коммита должно соответствовать соглашению Conventional Commits и состоять из категории и описания: : ? fix — исправление ошибки. Примеры сообщений коммитов: ? feat: добавление формы регистрации пользователя; ? fix: исправление ошибки валидации email-адреса; ? refactor: оптимизация алгоритма сортировки данных; ? chore: обновление версий в файле dependencies. 4.4.7.1.4. Модель ветвления В процессе разработки используются следующие основные ветви: ? main / master — стабильная ветка, содержит только код, прошедший полное тестирование и развернутый в продуктивных контурах; ? dev — ветка для интеграции завершенных задач, предназначенная для сборки и тестирования в тестовых средах. Попадание кода в main осуществляется только через Merge Request (MR) из dev - - Значение характеристики не может изменяться участником закупки - 4.4.7.1.5. Требования к используемым зависимостям (библиотекам) Все внешние зависимости проекта должны быть зафиксированы с указанием точных версий. Для контроля версий зависимостей в репозиторий обязательно должны быть включены следующие файлы: · Для JavaScript: package-lock.json или yarn.lock; · Для Python: requirements.txt (с зафиксированными версиями) или Pipfile.lock; · Для Go: go.mod и go.sum; Загрузка всех зависимостей должна производиться исключительно через внутренний прокси-репозиторий Заказчика, настроенный в соответствующем системе менеджере пакетов. Запрещается: · Использование плавающих версий (например, ^1.2.3, ~4.5.0, latest); · Использование библиотек, содержащих критические уязвимости, в том числе зарегистрированные в реестре CVE (Common Vulnerabilities and Exposures). 4.4.7.1.6. Требования к процессу непрерывной интеграции (CI) Сборка программного обеспечения, включая этапы компиляции, тестирования и анализа кода, должна выполняться исключительно в инфраструктуре непрерывной интеграции Заказчика. 4.4.7.1.7. Требования к хранению артефактов сборки Все артефакты сборки (результирующие пакеты, Docker-образы и т.д.) подлежат обязательному хранению в предназначенной для этого инфраструктуре Заказчика (артефакторий). Запрещается размещение финальных артефактов сборки на сторонних ресурсах - 4.5.5.1. Требования к безопасности исходного кода Процесс разработки исходного кода должен соответствовать требованиям законодательства, нормативным правовым актам Российской Федерации, приказу ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по безопасности значимых объектов критической информационной инфраструктуры Российской Федерации», а также учитывать отраслевые практики безопасной разработки. Подрядчик должен предоставить Заказчику Руководство по безопасной разработке программного обеспечения (далее – Руководство), применяемое при разработке исходного кода Модуля СЦ. Руководство должно содержать: · описание процесса безопасной разработки и ролевой модели, отражающей зоны ответственности сотрудников Подрядчика; · описание процессов моделирования, оценки и формирования мер предотвращения угроз, применяемых Подрядчиком; · описание методик, применяемых Подрядчиком при разработке исходного кода (правила написания кода); · описание методик, периодичности проведения и инструментария статического, динамического, композитного и фаззинг тестирования исходного кода, включающего критерии отбора релизных версий ПО, применяемые Подрядчиком в процессе разработки; · описание механизмов безопасности в процессе сборки и доставки (безопасность образов, безопасность секретов, безопасность окружения и сборочной среды), применяемые Подрядчиком; · утвержденные шаблоны отчетной документации (в том числе акты), в соответствии с которыми Заказчик принимает результаты проверок (артефакты сборочного процесса), проведенных Подрядчиком; · описание процедур отслеживания и исправления обнаруженных ошибок и уязвимостей программного обеспечения; · описание способов и сроков доведения Подрядчиком до Заказчика информации об уязвимостях программного обеспечения, о компенсирующих мерах по защите информации или ограничениях по применению программного обеспечения, способов получения пользователями программного обеспечения его обновлений, проверки их целостности и подлинности - Подрядчик должен обеспечить реализацию и проведение внутренних проверок мер по разработке безопасного ПО, приведенных в Руководстве. Подрядчик должен провести анализ угроз безопасности информации программного обеспечения в соответствии с ГОСТ 58412-2019 «Защита информации. Разработка безопасного программного обеспечения. Угрозы безопасности информации при разработке программного обеспечения». Подрядчик должен провести испытания по выявлению уязвимостей в программном обеспечении Системы: · проведение статического анализа исходного кода программы; · проведение динамического анализа исходного кода программы; · проведение композитного анализа исходного кода и образов программы; · проведение фаззинг-тестирования программы, направленного на выявление в ней уязвимостей. Испытания по выявлению уязвимостей в программном обеспечении Системы должны быть проведены в рамках: · предварительных испытаний; · опытной эксплуатации; · приемочных испытаний - 4.5.11. Требования к показателям назначения 4.5.11.1. Требования к показателям назначения мероприятий по развитию Модуля СЦ В рамках выполнения работ по развитию Модуля СЦ, предусмотренных ТЗ, показатель назначения «Количество пользователей» должен соответствовать значениям, приведенным в данном разделе. Пояснения по показателям, связанным с количеством пользователей, приведены в Таблице 8. Таблица 8. Определения показателей, связанных с количеством пользователей в Модуле СЦ № Показатель Определение Расчетное количество пользователей Количество пользователей, работу которых должен обеспечить Модуль СЦ к моменту сдачи работ по Контракту с учетом достижения всех показателей назначения Расчетное количество одновременно работающих пользователей Количество одновременно работающих пользователей, работу которых должен обеспечивать Модуль СЦ к моменту сдачи работ по Контракту с учетом достижения всех показателей назначения Значения показателей количества пользователей, достижение которых необходимо обеспечить, представлено в Таблице 9 - Таблица 9. Значения показателей количества пользователей № Показатель Значение 1. Расчетное количество пользователей 1 000 2. Расчетное среднее количество одновременно работающих пользователей 200 Развитие Модуля СЦ должно быть направлено на достижение следующего эффекта (показателя), подставленного в мероприятии 103.002 «Информационно-аналитическая система регулирования на транспорте (АСУ ТК)» ВПЦТ Минтранса России: Выполнение работ по развитию Модуля СЦ предусмотрено мероприятием по развитию АСУ ТК, приведенном в ВПЦТ Минтранса России на 2026-2028 гг: № 103.002 «АСУ ТК» в составе ИТ расхода 103.26.000005 «Развитие предусматривает реализацию ОКР и эффектов, приведенных в Таблице 10. Таблица 10. ОКР и эффекты, приведенные в ВПЦТ Минтранса России на 2026 г. № ОКР Дата ОКР Эффекты 1 Обеспечено информационное взаимодействие с Минобороны России о происшествиях на транспортных объектах 25.12.2026 Сокращено время сбора и передачи сведений для Минобороны России о ЧС и НС на транспорте с 120 до 10 минут 2 Обеспечена автоматизация формирования отчетов о нештатных ситуациях на транспорте, в том числе по данным внешних систем 25.12.2026 Сокращено время на подготовку отчетов о нештатных ситуациях на транспорте с 20 до 5 минут Реализация остальных ОКР не является предметом данного ТЗ и проводится в рамках отдельного технического задания. - 4.5.11.2. Требования к показателям назначения мероприятий по эксплуатации Модуля СЦ. Работы по эксплуатации Модуля СЦ не должны обеспечивать режимы функционирования Модуля СЦ, приведенные в разделе 4.5.2 данного ТЗ - 4.1. Требования к структуре Модуля СЦ В процессе работ по развитию Системы должны сохраниться основные требования к построению архитектуры Системы в соответствии с принципами трехуровневой архитектуры: 1. уровень хранения данных или уровень базы данных (сервер СУБД); 2. уровень сервера приложений (сервер аналитической обработки); 3. презентационный уровень, обеспечивающий взаимодействие с клиентскими приложениями. В состав Системы должны входить следующие основные компоненты: 4. сервер баз данных; 5. сервер приложений; 6. веб-сервер. Сервер баз данных должен обеспечивать хранение и целостность хранимых данных, создание резервных копий, ведение журнала транзакций, восстановление данных после сбоев. Сервер приложений должен обеспечивать обработку запросов, поступающих от клиентских приложений (через веб-сервер), формирование ответов на запрос в доступном пользователю виде (формирование пользовательских интерфейсов). Веб-сервер должен обеспечивать взаимодействие с оператором и внешними системами по HTTP / HTTPS протоколу в режиме «запрос-ответ» (получения запросов от пользователя и передачи ответа в виде соответствующей информации, обработанной серверами приложений). Взаимодействие Системы с пользователем должно отвечать требованиям модели «тонкого клиента» (т.е. представлять на стороне клиента (пользователя) лишь графический пользовательский интерфейс). Все составляющие Системы должны использовать единую методологию и отвечать единым принципам взаимодействия, надежности и управления. Перечень компонентов Модуля СЦ представлен в Таблице 4. Таблица 4. Перечень компонентов Модуля СЦ, в отношении которых выполняются работы по развитию № п.п. Наименование компонента Модуля СЦ Раздел ТЗ 1 Компонент регистрации событий 4.2.1. 2 Компонент отчетности 4.2.2 3 Компонент визуализации 4.2.3 4 «Интерактивная карта» (компонент создается) 4.2.4 5 Компонент администрирования 4.2.5 - 4.2. Требования к дорабатываемым функциям модуля СЦ 4.2.1. Развитие компонента регистрации событий (1 очередь) Должны быть выполнены следующие доработки: – обеспечение логирования действий пользователя, связанных с карточкой события; – доработка объектной модели в части создания новых типов сущностей (карточек) с учетом реализуемых интеграций с информационными ресурсами (силы и средства предупреждения и ликвидации ЧС и нештатных ситуаций на транспорте, ТС, ограничения воздушного пространства, неблагоприятные и опасные природные явления); – реализация механизма установления связи между сущностями в Модуле СЦ автоматизированным и ручным способами (события, природные явления, силы и средства предупреждения и ликвидации ЧС и нештатных ситуаций на транспорте, ограничения воздушного пространства, ОТИ, ТС и др.); – отображение в карточке установленных связей между сущностями. - 4.2.2. Развитие компонента отчетности (3 очередь) Должна быть обеспечена автоматизация процессов формирования отчетов о ЧС и нештатных ситуациях на транспорте, в т.ч. на основе данных из внешних систем. Включает следующие доработки: – разработка шаблонов отчетов в различных форматах (табличный, текстовый); – реализация выбора фотоматериалов для включения в справку; – форматирование содержимого справок с учетом правил русского языка в отношении окончаний слов (в зависимости от падежа, склонения, числа и рода); – автоматизированное формирование выводов к содержимому справки на основе настраиваемых критериев; – создание интерфейса выбора параметров (фильтрации) для формирования отчетов: o состав полей для включения в отчёт; o настройка диапазонов значений характеристик и дат; o порядок отображения полей; o настройка заголовка. – реализация способа подготовки отчётов в асинхронном режиме (очереди); – реализация интерфейса компонента формирования отчетности для отображения очереди формирования отчетов и статусов их подготовки; – экспорт отчётов в форматы xlsx, csv и справок в форматы pdf, docx. Необходимо разработать не менее 10 шаблонов отчетов и/или справок. Перечень, структура и содержание шаблонов должны быть согласованы с Заказчиком на этапе технического проектирования. - 4.2.3. Развитие компонента визуализации (2 очередь) В рамках развития компонента визуализации должны быть выполнены следующие доработки, обеспечивающие: – вывод перечней (списков) сил и средств предупреждения и ликвидации ЧС и нештатных ситуаций на транспорте с отображением мест их постоянного размещения (дислокации) на карте, включая: o отображение зон ответственности на карте; o возможность их фильтрации (по видам транспорта, регионам и пр.); o реализацию инструмента расчета расстояния (с использованием сети автомобильных и железных дорог) между местом события и местами дислокации сил и средств, а также вывода маршрутов на карте; – отображение зон (полигонов) с установленными ограничениями движения в воздушном пространстве на карте; – отображение термических точек; – реализация возможности отображения данных из паспорта региона, отображаемого в модуле iМинтранс (модуль АСУ ТК); – отображение краткой карточки сущностей и ОТИ (краткой информации и/или динамических характеристик объекта) при выборе объекта на карте с возможностью перехода в полную карточку сущности и ОТИ; – отображение данных от Росгидромета, предусматривающих: o отображение неблагоприятных и опасных природных явлений на карте (с заданным периодом обновления данных); o управление отображением явлений на карте, включая настройку состава отображаемых объектов, поиск, фильтрацию, с использованием соответствующей панели управления; o выведение краткой карточки явления при выборе объекта, с возможностью перехода в полную карточку объекта - – отображение на карте связанных сущностей и ОТИ; – реализация функции выбора темного и светлого стилей отображения элементов интерфейса, карточек сущностей, картографической основы и объектов, отображаемых на карте; – реализация механизма для выбора картографической основы в одном из распространенных форматов WMTS, TMS, MVT и др. Должна быть предусмотрена возможность настройки перечня картографических основ и параметров доступа к ним; – настройка базового набора дашбордов, содержащих преднастроенные виджеты о количестве событий в разрезе видов транспорта с возможностью перехода к исходным данным (карточкам событий, ОТИ и т.д.), с фильтрацией по параметрам. Параметры фильтрации должны быть определены на этапе технического проектирования. Должно быть обеспечено автоматическое и принудительное обновление данных, отображаемых на дашбордах - Таблица 6. Категории обращений и заявок Категория Примеры Запрос на обслуживание Подготовка SQL запроса к СУБД для решения прикладной задачи и д.р. – запрос на любое действие, не являющееся запросом информации и несовершенный на основе происшествия, прямо или косвенно влияющего на работу Модуля СЦ Консультация «Где взять / куда обратиться...?», «Как сделать / выполнить…», «Как это работает…?» - запрос, имеющий своей целью получение информационной поддержки Инцидент Разбор ошибок/сбоев и подготовка материалов (корректировочных релизов, инструкций) для Заказчика для устранения ошибок/сбоев, которые приводят к частичному и полному нарушению работоспособности всех или отдельных функций ППО. Подготовка изменения и материалов, необходимых для проведения аварийно-восстановительных работ для возобновления работоспособности Модуля СЦ ЗНИ Подготовка изменений, связанных с изменением, улучшением/оптимизацией Модуля СЦ и выводом новой модифицированной функциональности в штатном режиме. Подготовка изменений, связанных с модификацией существующих и/или реализация новых интеграционных механизмов для получения/обработки данных внешних систем. Подготовка изменений графического интерфейса по требованиям Заказчика. Перечень статусов обращений (заявок) приведен в пункте 3.3. Регламента оказания Услуг. Назначение обращению (заявке) статуса «Закрыто» осуществляется Заказчиком только после получения от инициатора обращения (заявки) подтверждения о его исполнении или нахождения обращения (заявки) в статусе «Выполнено» и отсутствия повторных вопросов/запросов по данному обращению (заявки) в течение 5 рабочих дней. Категории и статусы обращений (заявок) могут быть скорректированы в процессе оказания услуг исключительно по согласованию с Заказчиком - 4.3.6. Требования к услугам технической поддержки 4.3.6.1. Требования к организации третьего уровня технической поддержки Основными задачами организации третьего уровня технической поддержки в рамках оказания услуг по технической поддержке Модуля СЦ являются организация эксплуатационной службы Подрядчика, проверка готовности технических и программных средств для обеспечения непрерывного функционирования ППО Модуля СЦ. Подрядчиком должны быть проведены организационно-штатные и подготовительные мероприятия (в т. ч. технические) в рамках организации технической поддержки Модуля СЦ. Подрядчик в течение 5 (пяти) рабочих дней с даты заключения Контракта должен: – определить и направить Заказчику документ «Перечень уполномоченных специалистов», содержащий контактную информацию (ФИО, должность, адрес рабочей электронной почты) лиц, ответственных за оказание услуг со стороны Подрядчика; – обеспечить подключение специалистов Подрядчика к Системе регистрации обращений (заявок) (СРО предоставляется Заказчиком) для оказания услуг; – согласовать с Заказчиком способ доступа Подрядчика к Модулю СЦ. Результат выполнения мероприятий фиксируется в Протоколе проверки результатов организационно-штатных и подготовительных мероприятий (см. Приложение Д к настоящему ТЗ) - 4.2.4. Создание компонента «Интерактивная карта» (2 очередь) В составе создаваемого компонента должны отображаться данные, доступные в компоненте визуализации. Требования к интерфейсу интерактивной карты: – интерактивная карта должна быть представлена в виде объемной карты с учетом макетов, представленных в Приложении А к ТЗ; – интерфейс должен корректно отображаться на экранах мониторов (разрешение Full HD 1920?1080), телевизоров (разрешение 4К 3840?2160), жидкокристаллических панелей для видеостены, используемой Заказчиком, с параметрами каждой панели: диагональ 55 дюймов, разрешение 1920x1080; – интерфейс должен корректно отображаться на планшетных устройствах с диагональю экрана 10-12 дюймов, конкретные требования должны быть уточнены на этапе технического проектирования; – должна быть обеспечена кластеризация и генерализация отображения объектов на карте при изменении масштаба; – должно быть обеспечено отображение основных характеристик объектов при выборе их на карте; – должно быть обеспечено управление отображением слоев на карте; – должна быть обеспечена настройка цветовой индикации отображаемых объектов транспортной инфраструктуры; – должно быть обеспечено отображение легенды карты, содержащей отображаемые объекты на карте; – должна быть обеспечена возможность одновременного отображения не менее 5 000 ОТИ и ТС на карте. - На интерактивной карте должны быть отображены подвижные объекты совместно с объектами транспортной инфраструктуры (ОТИ), включая следующие возможности: § отображение местоположения транспортных средств (воздушный, водный и автомобильный транспорт) на карте в режиме реального времени (с заданным периодом обновления данных); § отображение маршрутов движения всех ТС за выбранный период времени, в том числе с использованием эффектов анимации; § отображение маршрутов движения ТС, связанных с карточкой события: ТС, являющихся участниками события, и ТС, находящиеся в заданном радиусе от события; § управление отображением сущностей и ОТИ на карте, включая настройку состава отображаемых объектов, поиск, фильтрацию, с использованием соответствующей панели управления и наглядным представлением результатов; § автоматическое изменение вида отображения объектов (цветовая индикация) по заданным условиям (например, при достижении критических значений параметров, характеризующих функционирование объекта); Должна обеспечиваться производительность обновления изображения на экране в 30 кадров в секунду на тестовой конфигурации пользовательского устройства (модель Бештау AIO2402/B560, входящая в Реестр российской промышленной продукции под номером 10394100 или аналог) при одновременном отображении не менее 5 000 объектов и 200 уникальных моделей объектов. Макеты интерфейсов Модуля СЦ должны быть предварительно согласованы с Заказчиком и разработаны с учетом требований ГОСТ Р ИСО 9241-161-2016 «Элементы графического пользовательского интерфейса» - 4.2.6. Взаимосвязи с внешними автоматизированными системами (1 очередь) Способы взаимодействия с внешними информационными системами должны быть определены на этапе технического проектирования. Должны быть выполнены следующие доработки: – интеграции с информационными ресурсами в целях получения данных о движении подвижных ТС (воздушные суда, суда водного транспорта); – интеграция с информационным ресурсом в целях получения данных о событиях на железнодорожном транспорте. Реализация интеграций должна включать проектирование и реализацию интеграционных механизмов обмена данными с учетом доступных вариантов реализации, обеспечение защищенных способов взаимодействия, настройку отображения отдельных данных на карте (настройка слоев). Взаимодействия, имеющие каналы связи, выходящие за пределы контролируемой зоны взаимодействующих систем, считаются защищенными, если для их защиты используются программные и/или программно-аппаратные шифровальные (криптографические) средства, сертифицированные ФСБ России (далее – СКЗИ). Выбор СКЗИ, схемы подключения и требуемого класса криптостойкости должен производиться в соответствии с Техническими условиями на подключение к информационным ресурсам ФГБУ «СИЦ Минтранса России» и инструкциями по подключению пользователей к ресурсам инфраструктуры Головного центра обработки данных, утвержденных приказом директора ФБГУ «СИЦ Минтранса России» от 24.05.2024 № 21-ОД - 4.3. Требования к оказанию услуг по технической поддержке Модуля СЦ 4.3.1. Общие требования к оказанию Услуг Техническая поддержка Модуля СЦ должна осуществляться с учетом требований постановления Правительства Российской Федерации от 06.07.2015 N 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации». Подрядчик обязан выполнять требования законодательства в сфере защиты информации, требования по защите информации, информационной безопасности, указанные в локальных нормативных актах ФГБУ «СИЦ Минтранса России», регламентирующих условия информационного взаимодействия, защиты информации и подключения к информационным ресурсам ФГБУ «СИЦ Минтранса России», участвующих в информационном взаимодействии в рамках оказания услуг по технической поддержке АСУ ТК в 2026 году - 4.3.1.1. Требования к составу и содержанию услуг третьего уровня технической поддержки Оказание услуг по технической поддержке Системы осуществляется в рамках этапов в соответствии с календарным планом. Подрядчик в течение 5 рабочих дней с даты заключения Контракта должен предоставить со своей стороны, а Заказчик со своей стороны Матрицу ответственных за взаимодействия в соответствии с Приложением 1 к Регламенту оказания услуг по третьему уровню технической поддержки Модуля СЦ (далее – Регламент, Приложение В). Подрядчик в течение 10 рабочих дней с даты заключения Контракта должен провести мероприятия по организации третьего уровня технической поддержки в соответствии с Регламентом. Услуги по третьему уровню технической поддержки Модуля СЦ должны включать: – организацию Подрядчиком третьего уровня технической поддержки; – информационно-консультационную поддержку работников Заказчика; – решение инцидентов, связанных с работой ППО; – адаптационное, конфигурационное и коррекционное сопровождение Модуля СЦ (в рамках действующих программных модулей и функциональности); – устранение уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности - Оказание услуг в рамках данного технического задания осуществляется Подрядчиком по обращению (заявке) Заказчика, направляемой посредством СРО Заказчика. Регистрация обращений, поступивших непосредственно в Модуль СЦ регистрации обращений Заказчика, производится сотрудниками Заказчика, которые обеспечивают первый уровень технической поддержки Модуля СЦ. В случае назначения приоритета «Критический» или «Высокий», информация о назначении также дублируется оповещением ответственных представителей Подрядчика посредством звонка на предоставленные номера телефонов. Обращение (заявка) должна содержать следующую информацию: – контакты пользователя/организации; – приоритет обращения, соответствующий Приложению 2 к Регламенту; – время обнаружения; – наименование компонента АСУ ТК - Модуль СЦ; Информация может быть расширена по согласованию с Заказчиком. Обращения (заявки) сотрудников Заказчика должны приниматься Подрядчиком через веб-интерфейс СРО. В процессе обработки обращений (заявок) Подрядчик должен обеспечить выполнение следующих процедур: – прием обращений(заявок) от сотрудников Заказчика; – оказание информационно-консультационной поддержки в соответствии с требованиями настоящего Технического задания; – информирование сотрудников Заказчика о статусе обработки и результатах обработки обращений(заявок). Подрядчик осуществляет обязательную регистрацию и учет всех обращений и заявок, поступивших к Подрядчику от представителей Заказчика в рамках оказания настоящих услуг - Примечание: в случае приостановки работы по обращению или заявке (обращение или заявка находится в статусе «Приостановлено»), указываются причины, по которым работы по обращению или заявке приостановлены с указанием перечня действий/информации, запрошенных у инициатора обращения, а также даты, формы и адресата такого запроса. В случае отклонения обращения или заявки (заполняется в случае, если обращению или заявке присваивается статус «Отклонено»), указываются подробно причины такого отклонения, а также фиксируется дата и время перехода в статус «Отклонено». В случае, если обращение или заявка отклонены (отменены) самим Инициатором, то указывается дата и способ, которым от инициатора получено соответствующее уведомление. В случае невыполнения Подрядчиком регламентного времени реагирования или решения обращения (заявки) Заказчик вправе отозвать обращение и направить его Подрядчику повторно. При этом каждое отозванное обращение учитывается в Отчёте об оказанных услугах, как обращение с превышением времени реагирования или решения, но оплате не подлежит. В случае, если обращение (заявка) связано с некачественным выполнением Подрядчиком другой задачи, такое обращение решается в регламентное время, установленное Техническим заданием, при этом оплате такие обращения не подлежат, о чем указывается в Отчете об оказанных услугах в графе «Примечание» - 4.3.6.2. Требования к услугам информационно-консультационной поддержки работников Заказчика и пользователей Модуля СЦ Услуги информационно-консультационной поддержки сотрудников Заказчика включают: – обработку обращений и заявок, поступивших от сотрудников Заказчика; – консультирование сотрудников Заказчика и пользователей Модуля СЦ; – актуализацию документации, и других материалов по работе с Модулем СЦ при необходимости. – консультирование и разработку рекомендаций по настройке Модуля СЦ (без изменения программного кода), включая изменение настроек функционирования; – консультации по вопросам использования, настройки и возможностям Модуля СЦ; – консультации по проведению превентивных мер для недопущения аварийных ситуаций в Модуле СЦ; – консультации по предварительной диагностике и локализации возникшей неисправности Модуля СЦ; – консультации по вопросам обеспечения информационной безопасности Модуля СЦ и настройки функций, обеспечивающих корректную работу программного обеспечения для совершения юридически значимых действий в Модуле СЦ; – другие вопросы, связанные с работой Модуля СЦ. 4.3.6.2.1. Требования к порядку оказания услуг информационно-консультационной поддержки работников Заказчика и пользователей Модуля СЦ Подрядчик выполняет консультирование сотрудников Заказчика и пользователей Модуля СЦ. Консультация может быть предоставлена по согласованным с представителем Заказчика каналам коммуникации с регистрацией результата консультации в СРО Подрядчиком. Детальный порядок оказания консультационных услуг определен в Регламенте оказания Услуг - 4.3.6.3. Требования к услугам по решению инцидентов, связанных с работой ППО Подрядчик устраняет неисправности Модуля СЦ, связанные с работой ППО, выявленные в рамках оказания услуг согласно настоящему Техническому заданию, при этом в зону ответственности Подрядчика не входит устранение неисправностей, выявленных на стороне Заказчика и на стороне третьих лиц (провайдера связи, поставщика электропитания и т.д.). Первичная диагностика выявленной неисправности проводится на 1 и 2 уровнях технической поддержки и не входит в зону ответственности Подрядчика. Если при проведении первичной диагностики и попытке устранить неисправности на 1 и 2 уровнях технической поддержки, данную неисправность устранить не удалось и в процессе диагностики было выявлено, что проблема связана с работоспособностью ППО, обращение (заявка) назначается сотруднику Подрядчика, ответственному за оказание услуг технической поддержки 3 уровня. Инцидентами вне зоны ответственности Подрядчика являются: – работоспособность функциональности, выходящая за рамки текущей реализации функций в Модуле СЦ и/или являющаяся расширением требований Заказчика к функциям Модуля СЦ; – проведение профилактических и плановых работ, согласованных с Заказчиком; – нарушение работоспособности функций Модуля СЦ, вызванное проведением работ на стороне Заказчика - 4.2.4.1. Требования к технической реализации компонента «Интерактивная карта» При реализации компонента «Интерактивная карта» должны учитываться требования, указанные ниже. 4.2.4.1.1. Требования к отображению элементов Повторяющихся элементы карты (ТС, ОТИ, события и пр.) должны отрисовываться с использованием аппаратного создания экземпляров объектов на пользовательском устройстве (WebGL/WebGPU)). Отрисовка каждого объекта отдельным запросом не допускается, должна обеспечиваться возможность одновременного отображения не менее 5 000 объектов без снижения производительности (30 кадров в секунду на тестовой конфигурации). 4.2.4.1.2. Уровни детализации объектов Для управления отображением сложных объектов должно быть создано не менее 3-х уровней детализации, отображаемых при изменении масштаба с возможностью автоматического переключения между уровнями. Все отображаемые объекты должны масштабироваться с учетом разрешения экрана пользователя с сохранением качества детализации. 4.2.4.1.3. Полигональная оптимизация и текстурирование При реализации компонента «Интерактивная карта» должна обеспечиваться технология рельефного тестурирования объектов. Не должны использоваться высокополигональные трехмерные модели. Все повторяющиеся элементы должны генерироваться единоразово и повторно использоваться при последующих отображениях. 4.2.4.1.4. Управление памятью Требуется реализовать потоковую загрузку на устройство пользователя элементов карты и текстур. Загрузка данных целиком при старте приложения не допускается. Необходимо реализовать механизм очистки памяти от элементов, которые находятся вне области видимости камеры в течение заданного времени. 4.2.4.1.5. Требования к взаимодействию пользователя с интерфейсом компонента «Интерактивная карта» Программная реализация механизмов управление камерой (масштабирование и навигация) должна быть выполнена с поддержкой технологии WebAssembly (WASM). Элементы управления должны являться неотъемлемой частью интерактивной карты. - 4.2.5. Развитие компонента администрирования (3 очередь) Должна быть выполнена доработка ролевой модели. Ролевая модель должна обеспечивать управление доступом к отдельным объектам Модуля СЦ и их элементам (атрибутам) с разграничением по видам транспорта, регионам и пр., в частности: – определение набора конкретных действий, доступных пользователям (выполняемых над объектом доступа, например, удаление записи, редактирование записи, формирование отчета и др.); – реализация возможности объединения пользователей в группы; – определение прав доступа для групп пользователей; – реализация интерфейса визуальной настройки прав доступа пользователей к объектам Модуля СЦ - 4.3.1.2. Требования к общему порядку оказания услуг Техническая поддержка Модуля СЦ должна быть организована на трех уровнях: – первый и второй уровни технической поддержки организуется Заказчиком; – третий уровень технической поддержки организуется Подрядчиком. Перечень действий на каждом уровне технической поддержки указан в Таблице 5: Таблица 5 – Перечень действий на каждом уровне технической поддержки Уровень технической поддержки Доступные действия Условия передачи задачи на следующий уровень Первый уровень технической поддержки (далее – 1-й уровень) – принимает обращения (заявки) пользователей Модуля СЦ и работников Заказчика; – регистрирует обращения в Модуле СЦ регистрации обращений; – присваивает уникальный идентификационный номер, классифицирует обращения; – самостоятельно решает обращения, которые связаны с недостаточной квалификацией пользователей или настройками в рамках своей компетенции; – взаимодействует с пользователями Модуля СЦ при решении проблемы Передает обращение на второй уровень поддержки в случае невозможности решения на своем уровне Второй уровень технической поддержки (далее – 2-й уровень) – принимает обращения от 1-го уровня; – уточняет классификацию обращения в результате дополнительного анализа; – самостоятельно решает обращения в рамках своей компетенции; – осуществляет техническую и консультационную поддержку Модуля СЦ; – взаимодействует с сотрудниками 1-го и 3-го уровня и пользователями Модуля СЦ; – формирует заявки для 3-го уровня и контролирует исполнение Передает обращение на третий уровень поддержки в случае невозможности решения на своем уровне Третий уровень технической поддержки (далее – 3-й уровень) – принимает обращения от 2-го уровня; – обеспечивает выполнение требований, предъявляемых Контрактом и настоящим Техническим заданием к Услугам, оказываемым Подрядчиком Все поступающие обращения должны быть исполнены Подрядчиком - Для обеспечения взаимодействия с Заказчиком Подрядчик со своей стороны определяет ответственных лиц, уполномоченных в структуре Подрядчика за своевременное и качественное оказание Услуг в рамках настоящего ТЗ, а также контактную информацию ответственных лиц (телефон, электронную почту). Подрядчик должен предоставить Заказчику единый адрес электронной почты для приема обращений (заявок) в течение 3 (трех) рабочих дней после заключения Контракта. Указанный в настоящем пункте адрес электронной почты (способ направления обращений (заявок) применяется в случае сбоя в работе СРО Заказчика. Со своей стороны, Заказчик предоставляет Подрядчику перечень и контактную информацию (телефон, электронную почту) уполномоченных лиц для осуществления взаимодействия с указанием зон ответственности. О любых изменениях в контактной информации ответственных лиц Стороны должны уведомить друг друга в течение 1 (одного) рабочего дня с момента возникновения таких изменений посредством уведомления на электронную почту ответственных лиц и/или в письменной форме. В результате оказания услуг по настоящему ТЗ не должны быть изменены исходные коды, дистрибутивы и иные компоненты Модуля СЦ вне согласованных с Заказчиком изменений. Любые изменения исходных кодов, дистрибутивов и иных компонентов Модуля СЦ должны производиться только после согласования с Заказчиком уполномоченными лицами по электронной почте или иным заранее согласованным способом. Не должна быть ухудшена надежность и производительность Модуля СЦ. Оказание услуг по Контракту не должно нарушать требования к информационной безопасности, описанной в документации на Модуль СЦ - 4.3.1.3. Требования к регламенту оказания услуг Подрядчик должен руководствоваться Регламентом оказания услуг по технической поддержке Модуля СЦ. Регламент оказания услуг содержит следующую информацию: – порядок оказания услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Модуля СЦ; – порядок оказания услуги по решению инцидентов, связанных с работой ППО; – порядок оказания услуги адаптационного, конфигурационного и коррекционного сопровождения Модуля СЦ (в рамках действующих программных модулей и функциональностей); – порядок оказания услуги по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности. – Регламент содержит следующие формы заявок на оказание услуг: – форма заявки на оказание услуги по информационно-консультационной поддержке сотрудников Заказчика; – форма заявки на оказание услуги по решению инцидентов, связанных с работой ППО; – форма заявки на оказание услуг адаптационного, конфигурационного и коррекционного сопровождения Модуля СЦ (в рамках действующих программных модулей и функциональностей) (приоритет заявки определяется Заказчиком); – форма заявки на оказание услуги по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности - 4.3.2. Требования к режиму обеспечения функционирования Модуля СЦ Режим оказания услуг определен в Приложении Б к настоящему ТЗ. По согласованию с Заказчиком, в целях недопущения остановки функционирования Модуля СЦ в период интенсивной работы пользователей в Модуле СЦ, отдельные услуги могут оказываться по специальному графику (в нерабочее время Подрядчика) в соответствии с заявками Заказчика - 4.3.3. Требования к качеству оказываемых услуг Качество оказываемых услуг поддерживается Подрядчиком в соответствии с определяемыми данным ТЗ условиями и правилами и контролируется Заказчиком на постоянной основе, в том числе по соблюдению сроков исполнения и подтверждениям исполнения от инициаторов обращений и другим параметрам. По результатам выполнения работ по устранению инцидента должна быть устранена корневая причина инцидента с окончательным решением, устраняющим причину возникновения проблемы и исключающим вероятность повторного возникновения проблемы (инцидента). Время устранения корневых причин проблемы (инцидента) не должно составлять более 40 рабочих часов - Работы по устранению неисправности приостанавливаются (по согласованию с Заказчиком) в следующих случаях: – если Подрядчиком в результате диагностики выявлено, что неисправность находится в зоне ответственности Заказчика. Подрядчик информирует Заказчика о выявленной неисправности в зоне его ответственности по согласованным каналам связи; – требуется действие со стороны Заказчика – до момента выполнения данного действия Заказчика. Заказчик информируется о необходимых действиях по согласованным каналам связи; – отсутствие возможности связаться со специалистами Заказчика, участие которых необходимо для устранения неисправности; – требуется доставить оборудование на объект – до момента доставки и установки оборудования. В случаях, представленных выше, время приостановки работ не входит в учет продолжительности устранения неисправности. Учет времени устранения неисправности Подрядчиком считается с момента назначения Инцидента специалисту Подрядчика, ответственному за оказание услуг технической поддержки 3 уровня. Подтверждение необходимости приостановления работ находится в зоне ответственности Подрядчика. Приостановление сроков выполнения задач в соответствии с настоящим пунктом подтверждается Заказчиком по мотивированному обращению Подрядчика в СРО, основанному на данных диагностики или на иных фактических обстоятельствах - В случае непринятия Подрядчиком необходимых мер по информированию Заказчика (отсутствие надлежащего обращения от Подрядчика или отсутствие уведомления о необходимости осуществления каких-либо действий Заказчиком) не может являться основанием для приостановления работ по устранению неисправности. В отдельных случаях Подрядчику может потребоваться выполнение технологических работ для устранения причин неисправности или недопущения повторения их в будущем. Для обеспечения устранения неисправности Модуля СЦ Заказчиком проводится классификация в соответствии с приоритетами по степени срочности их устранения. Продолжительность устранения неисправности, а также периодичность информирования Подрядчиком Заказчика о ходе устранения неисправности, определены в Регламенте оказания услуг. При подаче обращения (заявки) наивысшего приоритета через СРО Заказчик должен дополнительно проинформировать службу поддержки Подрядчика о созданном обращении (заявки) по телефону уполномоченного сотрудника Подрядчика. При этом временем подачи обращения (заявки) считается время подачи обращения (заявки) через СРО - 4.3.6.4.1. Требования к проведению изменений Основанием для внесения изменений является запрос от Заказчика. Все активности по внесению изменений должны быть согласованы с Заказчиком, а действия Подрядчика при оказании данной услуги должны быть зафиксированы. В рамках данного Технического задания изменениями считаются локальные доработки функционала Модуля СЦ, которые не должны приводить к необходимости выполнения дополнительных аттестационных испытаний или переаттестации АСУ ТК в соответствии с п. 33 приказа от 29.04.2021 № 77 «Об утверждении Порядка организации и проведения работ по аттестации объектов информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну». При необходимости внесения изменений в Модуль СЦ, не связанных с критичным инцидентом, существенно нарушающим работоспособность Модуля СЦ, Заказчик направляет Подрядчику обращение (заявку), в котором излагает суть изменения, которое требуется внести в Модуль СЦ. Исполнитель, в течение 3 (трех) рабочих дней с момента поступления соответствующего обращения (заявки), оценивает техническую возможность реализации запрашиваемого изменения и варианты реализации. По итогу проведения оценки Подрядчик направляет Заказчику заключение о возможности реализации данного изменения с описанием возможных вариантов реализации и согласует с Заказчиком проведение данного изменения - При проведении работ по изменению и адаптации Подрядчик должен: – обеспечить выполнение требований безопасной разработки программного обеспечения; – обеспечить предварительное проектирование технических решений и согласование с Заказчиком проекта реализации изменения; – использовать семантическое версионирование (SemVer) в работе, передать Заказчику все артефакты разработки (исходный код и сторонние библиотеки, конфигурации, сборочные и собранные образы и др.); – подготовить полноценное описание функционала, включенного в релиз, с необходимыми схемами и пояснениями к обновлению на стендах Заказчика; – обеспечить тестирование разработанного функционала на стендах Заказчика силами Подрядчика; – решение о переносе измененного ППО на продуктивный стенд принимается Заказчиком по итогу результатов проведенного тестирования; – обеспечить техническое сопровождение процедуры тестирования ППО и переноса измененного ППО на продуктивный стенд Заказчика; – обеспечить экстренное внесение соответствующих изменений в случае выявления некорректной работы продуктивного стенда Заказчика после проведения обновления по итогам разработанного изменения в кратчайшие сроки; – актуализировать при необходимости комплект эксплуатационной документации: o руководство пользователя; o руководство администратора; o иные документы (при необходимости). Результат выполнения изменений должен быть отражен в Отчете по оказанию услуг. Типы и приоритеты изменений могут быть скорректированы в процессе оказания услуг исключительно по согласованию с Заказчиком - 4.3.4. Требования к документированию результатов оказываемых услуг Для обеспечения контроля оказываемых услуг по поддержке Модуля СЦ со стороны Заказчика, по окончании каждого отчетного периода по контракту в соответствии с календарным планом, Подрядчик обязан предоставить Заказчику Отчет об оказанных услугах. Отчет должен содержать детальную информацию об оказанных услугах с указанием даты выполненных мероприятий и приложением обосновывающих документов (заявок, запросов, требований) или ссылкой на такие документы, если они содержатся в Модуле СЦ. Информация о выполненных мероприятиях по заявкам должна быть сформирована на основании соответствующих записей СРО по каждому этапу исполнения Контракта. В случае оказания услуги адаптационного, конфигурационного и коррекционного сопровождения Модуля СЦ, должны быть предоставлены документы, подтверждающие выполнение требований п. 29.3 приказа ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации». Фактическое время реагирования и время решения по всем обращениям, поступившим в СРО, формируется в СРО по итогам отчетного периода в разделе «Отчеты». Фактическое время реагирования и время решения по обращениям учитывает суммарное время, затраченное на реагирование и, соответственно, на работу по обращению с момента назначения обращения специалисту Подрядчика или группе исполнителей, ответственным за оказание услуг технической поддержки 3 уровня от начала до завершения работ Подрядчиком. При этом принимается суммарное время нахождения заявки в соответствующих статусах заявки СРО на стороне Подрядчика - 4.3.5. Требования к классификации обращений и заявок Обращения и заявки Заказчика классифицируются в соответствии с приоритетами и регламентными сроками, указанными в Приложении 2 к Регламенту. Регистрация обращений и заявок предусматривает создание новой записи в СРО с присвоением поступившему обращению или заявке (новой записи) уникального идентификатора. Запись в СРО должна содержать вопрос или проблему, которую требуется решить или оказать консультацию. Состав обязательной информации, которую должно содержать обращение или заявка, зафиксирован в Регламенте оказания Услуг. Если обращение или заявка автоматически зарегистрированы в СРО при отправке представителем Заказчика, Подрядчик проверяет корректность классификации обращения или заявки и может обратиться к Заказчику с просьбой корректировки, предоставив обоснования в соответствии с настоящей классификацией (Таблица 6) - 4.3.6.3.1. Требования к порядку оказания услуги по решению инцидентов, связанных с работой ППО При поступлении от Заказчика обращения (заявки), являющегося неисправностью в работе Модуля СЦ (инцидентом), Исполнитель реагирует на инцидент в СРО в срок не более 30 минут с момента поступления. В случае необходимости, для решения инцидента ответственный специалист должен связаться с инициатором обращения (заявки) для уточнения условий воспроизведения проблемы или для получения дополнительных сведений. После получения необходимых сведений от инициатора обращения (заявки) ответственный специалист производит диагностику с целью выявления причины инцидента и возможных путей устранения. В случае, если инцидент невозможно решить без получения дополнительных сведений от инициатора, и не удается связаться с инициатором в течение пяти рабочих дней, обращение (заявка) отклоняется в связи с недостатком данных для его решения, Заказчику направляется уведомление об отклонении обращения (заявки). Время, в течение которого невозможно связаться с инициатором, вычитается из общего времени обработки обращения (заявки). Все попытки связаться с инициатором должны фиксироваться с указанием даты и времени попытки, используемого способа связи (номер телефона, адрес электронной почты) и результата попытки (не удалось дозвониться, абонент недоступен, и т.д.) - Факт и время решения инцидента должны быть зафиксированы и отражены в СРО. В случае, если причиной сбоя в работе Модуля СЦ является выход из строя аппаратного обеспечения или неработоспособность смежной информационной системы, время работы над инцидентом приостанавливается до момента устранения неисправности. В ходе решения инцидентов могут быть выявлены дефекты ППО Модуля СЦ. В случае обнаружения дефектов ППО, Подрядчик информирует об этом Заказчика. Исполнитель может быть привлечен к проверке результата устранения дефекта по инициативе Заказчика. Приоритеты инцидентов приведены в Приложении Б к ТЗ. Детальный порядок оказания услуги по решению инцидентов, связанных с работой ППО Модуля СЦ определен в Регламенте оказания Услуг - 4.3.6.4. Требования к услугам адаптационного, конфигурационного и коррекционного сопровождения и доработки Модуля СЦ (в рамках действующих программных модулей и функциональностей) Услуги адаптационного, конфигурационного и коррекционного сопровождения и доработки Модуля СЦ включают: – управление изменениями и адаптация функций Модуля СЦ; – изменение настроек функционирования Модуля СЦ; – внесение изменений и/или модификаций Модуля СЦ (в рамках действующих программных модулей и функциональностей), направленных на улучшение их работоспособности и функциональных возможностей; – подготовка и передача Заказчику SQL запросов в СУБД для получения агрегированной информации из Модуля СЦ, которую невозможно получить с использованием графического пользовательского интерфейса; – адаптация модулей интеграций со смежными информационными системами - 4.3.6.4.2. Требования к изменению настроек функционирования Изменение настроек функционирования может проводиться в рамках допустимых пределов изменения функционирования, заложенных в архитектуру Модуля СЦ. Изменение настроек функционирования включает в себя изменение данных и справочников, изменение форм документов, формируемых Модулем СЦ, изменение и настройку форматов и версий передачи данных в смежные системы. Доработка программного кода Модуля СЦ может допускаться (в случае необходимости) при выполнении работ по адаптации функций Модуля СЦ в части изменения формата передачи данных в смежные информационные системы при условии соблюдения требований пункта 29.3 приказа ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации» - 4.3.6.5. Требования к услугам по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности По запросу Заказчика Подрядчик должен провести работу по приведению ППО в соответствие с требованиями по обеспечению информационной безопасности. Критичность уязвимости оценивается в соответствии в соответствии с Методическим документом ФСТЭК России «Методика оценки уровня критичности уязвимостей программных, программно-аппаратных средств» (утвержден ФСТЭК России 30.06.2025), а также с учетом ГОСТ 56545-2015 и международными стандартами (CVSS 3.0 и выше), и задает необходимый срок устранения. В процессе проведения Заказчиком обследования Модуля СЦ и выявления уязвимостей в ППО, связанных с исходным кодом Модуля СЦ и/или используемыми компонентами (библиотеками), Заказчик направляет Подрядчику обращение (заявку) на устранение, с указанием критичности и срочности принятия мер по устранению в СРО. - Подрядчик при оказании услуг по обновлению или устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности должен: – провести анализ уязвимостей и связанных с ними исходным кодом и/или используемыми компонентами (библиотеками); – выработать варианты устранения указанных уязвимостей и согласовать с Заказчиком их реализацию; – своевременно внести изменения в исходный код Модуля СЦ и/или используемые компоненты (библиотеки) и подготовить соответствующее обновление; – провести обновление Модуля СЦ в тестовом контуре Заказчика и проинформировать Заказчика о готовности проведения тестирования; – протестировать успешность обновления или устранения уязвимостей в ППО и корректность функционирования Модуля СЦ на тестовом контуре, совместно с Заказчиком; – при невозможности незамедлительного устранения уязвимости приоритетов «Критический» и «Высокий» Подрядчик обязан предоставить исчерпывающий список причин и согласовать план достаточных компенсирующих мер с ответственными сотрудниками Заказчика. Результат внесения изменений отображается в соответствующей записи в СРО и в составе Отчета об оказанных услугах - 4.3.6.5.1. Требования к порядку оказания услуг по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности Подрядчик в соответствии с приоритетами обращений и контрольными сроками исполнения (см. Приложение Б к ТЗ) оценивает техническую возможность и сроки устранения уязвимостей, и реализацию обновления Модуля СЦ. По итогу проведения оценки Подрядчик направляет в заявке СРО Заказчику заключение о возможности устранения уязвимостей и/или обновления в ППО и согласует с Заказчиком проведение данных работ - 4.4.8. Требования к техническому обеспечению Количество серверов, подключаемых и настраиваемых сервисов, их параметров, схемы соединений и настройки межсетевого взаимодействия должны быть согласованы с Заказчиком на этапе № 1 Техническое проектирование. Доступ к комплексу технических средств предоставляется Заказчиком по письменному запросу Подрядчика. Применяемые в Системе программно-аппаратные и аппаратные комплексы должны соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации», требованиям Постановления Правительства Российской Федерации от 23 декабря 2024 г. № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц». Модуль СЦ, работающий в составе АСУ ТК, развернут на вычислительных мощностях ГЦОД СИЦ Минтранса России - 4.5. Общие технические требования 4.5.1. Требования к численности и квалификации персонала и пользователей Модуля СЦ Программное обеспечение Модуля СЦ не должно требовать изменения штатной численности персонала Заказчика. Программное обеспечение Модуля СЦ не должно требовать наличия у пользователей дополнительной квалификации в сфере информационных технологий, кроме базовых знаний в обращении с персональным компьютером, базовых навыков работы в интернет-обозревателях и знаний о Модуле СЦ в объеме документов Руководство пользователя, Руководство администратора - 4.5.2. Требования к режимам функционирования Модуля СЦ Модуль СЦ должен предусматривать наличие следующих режимов работы: – штатный; – регламентный (профилактический); – аварийный. Основным режимом функционирования является штатный. В штатном режиме все компоненты корректно и полностью выполняют свои функции. Перерывов в работе как Модуля СЦ в целом, так и одного, либо нескольких компонентов не предусмотрено. Режим регламентного (профилактического) обслуживания предназначен для проведения работ по обновлению и техническому обслуживанию компонентов Модуля СЦ, а также резервному копированию данных. При работе в данном режиме допускаются перерывы в работе Модуля СЦ с предварительным информированием пользователей. Состав процедур по регламентному обслуживанию Модуля СЦ и их периодичность определяются Подрядчиком в процессе выполнения работ по созданию Модуля СЦ. В режиме регламентного (профилактического) обслуживания Модуль СЦ может функционировать с частичным ограничением своих функциональных возможностей, либо без ограничения, но со снижением показателей надежности и производительности. Перевод в данный режим работы должен осуществляться сразу после начала выполнения любой операции, отнесенной к этому режиму, с последующим возвратом в штатный режим функционирования сразу после ее завершения. Перевод в указанный режим должен осуществляться при возникновении необходимости проведения работ по обновлению и техническому обслуживанию компонентов Модуля СЦ, а также резервному копированию данных с условием предварительного оповещения пользователей. Аварийный режим функционирования характеризуется отказом одной или нескольких подсистем, вызванных выходом из строя аппаратного и/или программного обеспечения, а также в случае временной неработоспособности каналов связи между серверами. - По результатам анализа угроз безопасности информации программного обеспечения и испытаний по выявлению уязвимостей в программном обеспечении Системы должна быть предоставлена отчетная документация по формам, утвержденным в Руководстве, и артефакты сборочной среды, подтверждающие проведение испытаний по выявлению уязвимостей в программном обеспечении Систем. Уязвимости подлежат устранению в сроки, обозначенные Заказчиком. В случае обнаружения уязвимого компонента Подрядчик должен заменить/обновить библиотеки. В случае, если уязвимость не подлежит исправлению на программном уровне, Подрядчик должен разработать меры предотвращения угроз безопасности, в том числе правила безопасности для наложенных средств защиты, рекомендации по безопасной настройке конфигурации для устранения потенциальных уязвимостей и снижения рисков информационной безопасности. Уязвимости, найденные ФСБ России, ФСТЭК России, Минцифры России, Роскомнадзором в ходе исполнения Контракта, а также в течение гарантийного периода, должны быть устранены Подрядчиком за свой счет в сроки, согласованные с Заказчиком - 4.5.6. Требования к эргономике и технической эстетике Взаимодействие пользователей с Модулем СЦ должно осуществляться посредством визуального графического интерфейса. Ввод-вывод данных, прием управляющих команд и отображение результатов их исполнения должны выполняться в интерактивном режиме. Интерфейс должен быть рассчитан на преимущественное использование манипулятора типа «мышь», то есть управление Модулем СЦ должно осуществляться с помощью набора экранных меню, кнопок, значков и т. п. элементов. Клавиатурный режим ввода должен использоваться главным образом при заполнении и/или редактировании текстовых и числовых полей экранных форм. Все надписи экранных форм, а также сообщения, выдаваемые пользователю (кроме системных сообщений), должны быть на русском языке. Модуль СЦ должен обеспечивать проверку вводимых пользователем данных и предупреждать о некорректно введённых значениях - Экранные формы должны проектироваться с учетом требований унификации: – все экранные формы пользовательского интерфейса должны быть выполнены в едином графическом дизайне, с одинаковым расположением основных элементов управления и навигации; – для обозначения сходных операций должны использоваться сходные графические элементы, кнопки и другие управляющие (навигационные) элементы. Термины, используемые для обозначения типовых операций, а также последовательности действий пользователя при их выполнении должны быть унифицированы; – внешнее поведение сходных элементов интерфейса (реакция на наведение указателя «мыши», переключение фокуса, нажатие кнопки) должно реализовываться одинаково. Структура размещения информации и представление этой структуры в Модуле СЦ должны соответствовать следующим требованиям: – пункты меню в пользовательском веб-интерфейсе должны быть сгруппированы в соответствии с тематикой информации, функциональными задачами и технологией работы; – каждому пункту меню должна соответствовать только одна выполняемая функция; – при совершении пользователями ошибочных действий должны выдаваться сообщения об ошибках. Эскизы визуального оформления компонента «Интерактивная карта» представлены в Приложении А. - При проведении работ по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности необходимо выполнить следующее: – Заказчику сформировать заявку на устранение (обновление) в СРО с полным списком обнаруженных уязвимостей и планируемыми работами; – согласовать в рабочем порядке время начала и завершения работ, перечень работ, выполняемых в рамках обновления или устранения уязвимостей в ППО с Заказчиком; – оповестить Заказчика о начале проведения работ на тестовом контуре; – провести работы по обновлению или устранению уязвимостей в ППО на тестовом контуре Модуля СЦ в установленные сроки; – протестировать выполнение работ в тестовом контуре и проинформировать Заказчика о готовности переноса ППО на продуктивный контур; – силами Заказчика обновить продуктивный контур Модуля СЦ, в соответствии с планом устранения и выполненными работами; – совместно с Заказчиком проверить корректность функционирования Модуля СЦ и устранения уязвимостей в продуктивном контуре Модуля СЦ по результатам обновления; – при необходимости актуализировать документацию (описание архитектуры, анкеты постановки на мониторинг и иные документы). Любые изменения в части обновления или устранения уязвимостей в ППО на промышленном контуре Модуля СЦ должны применяться только в случае успешного проведения аналогичных работ на тестовом контуре. Детальный порядок оказания услуги по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности определен в Регламенте оказания Услуг - 4.4. Требования к видам обеспечения 4.4.1. Требования к лингвистическому обеспечению Документация на Модуль СЦ должна разрабатываться на русском языке. Взаимодействие пользователей с Модулем СЦ посредством графического интерфейса должно происходить на русском языке за исключением сообщений, зависящих от настроек системного программного обеспечения, установленного на рабочих местах пользователей. При разработке программных решений Модуля СЦ должно быть предусмотрено использование языков программирования высокого уровня, приведенных в Таблице 7. Таблица 7. Языки и средства разработки, специального программного обеспечения Модуля СЦ Категория Наименование Назначение Языки программирования Kotlin Разработка серверной логики и сервисов (backend) JavaScript / TypeScript Разработка клиентской части (frontend) Python Разработка скриптов интеграции, обработки данных и автоматизации Фреймворки и библиотеки Vue.JS Разработка пользовательских интерфейсов (веб-интерфейсы компонентов визуализации и отчетности) React Разработка пользовательских интерфейсов (при необходимости создания сложных интерактивных компонентов) Решения по лингвистическому обеспечению, включая перечень используемых языков программирования, должны быть согласованы с Заказчиком на этапе технического проектирования - В аварийном режиме осуществляется поиск неисправностей и проведение работ по их устранению. Перевод в аварийный режим должен осуществляться при возникновении сбоев, аварий и прочих незапланированных воздействий, сразу после наступления одной или нескольких аварийных ситуаций, с последующим возвратом в штатный режим функционирования сразу после окончания восстановительных работ. ПО Модуля СЦ должно обладать надежностью, обеспечивающей работу пользователей в произвольном режиме и оперативное восстановление работоспособности при сбоях. В целях обеспечения надежного функционирования ПО должно предусматривать: – сохранение целостности данных при нештатном завершении работы компонентов Модуля СЦ; – сохранение работоспособности программного обеспечения при некорректных действиях пользователя; – резервное копирование базы данных Модуля СЦ. – время восстановления работоспособности Модуля СЦ после отказа не более 4 часов. – отказоустойчивость на уровне 99% при единовременной количестве не менее 200 пользовательских сессий в Модуле СЦ. Указанные характеристики приведены без учета характеристик надежности инфраструктуры и времени передачи информации по каналам связи. При возникновении сбоев в аппаратном обеспечении, включая аварийное отключение электропитания, Модуль СЦ должен автоматически восстанавливать свою работоспособность (не требовать перенастройки) после устранения сбоев и корректного перезапуска аппаратного обеспечения - Технические меры по обеспечению надежности должны предусматривать: – резервирование критически важных компонентов и данных Системы и отсутствие единой точки отказа; – использование программного резервирования (программной избыточности); – изменение конфигурации используемых средств и применение специализированного ПО, обеспечивающего высокую надёжность. Организационные меры по обеспечению надежности должны быть направлены на минимизацию ошибок пользователей (а также обслуживающего персонала при эксплуатации и проведении работ по обслуживанию), минимизацию времени ремонта или замены вышедших из строя компонентов за счёт: – обеспечения для обслуживающего персонала требуемого уровня квалификации; – регламентации и нормативного обеспечения выполнения работ обслуживающим персоналом; – своевременной диагностики неисправностей. Расчетное значение коэффициента доступности Модуля СЦ должно составлять не менее 0,95. - 4.5.3. Требования по диагностированию Модуля СЦ Диагностирование Модуля СЦ должно осуществляться путем анализа записей в системных журналах СУБД, операционных систем серверов, а также с помощью встроенных средств диагностирования общего программного обеспечения Модуля СЦ. Диагностированию подлежат: – сбои и нарушения функционирования технического обеспечения (серверов) Модуля СЦ; – сбои и нарушения функционирования системного программного обеспечения серверов, используемых для работы Модуля СЦ; – сбои и нарушения функционирования прикладного программного обеспечения серверов, используемых для работы Модуля СЦ; – случаи недоступности (отсутствия ответа) или некорректные ответы внешних систем; – сбои и нарушения функционирования СУБД; – сбои при выполнении регламентных операций резервного копирования. При возникновении аварийных ситуаций либо ошибок в программном обеспечении диагностические инструменты должны позволять сохранять набор информации, необходимой для идентификации и устранения проблемы. Модуль СЦ и ее компоненты должны обеспечивать возможность диагностики своей работоспособности с возможностью интеграции с модулем мониторинга АСУ ТК. Набор передаваемых журналов и метрик должен быть определен на этапе технического проектирования - 4.5.7. Требования по сохранности информации при авариях В случае возникновения аварии или сбоя в процессе выполнения пользовательских задач должно быть обеспечено восстановление баз данных до состояния на момент последней завершенной Модулем СЦ транзакции, и структуры файлового хранилища. Все аварийные ситуации должны обрабатываться программно с выдачей соответствующих сообщений, с корректной обработкой ситуации (завершение транзакций, закрытие файлов и т.п.), без потери обрабатываемой информации. В Модуле СЦ должны быть предусмотрены меры, обеспечивающие целостность данных в случае отказа программного обеспечения или аппаратных средств, исключая случаи физического уничтожения носителя или нарушения функциональности носителя, операционной системы или СУБД по вине их производителя либо обслуживающего персонала. Используемые аппаратные и системные платформы должны обеспечивать сохранность и целостность информации в Модуле СЦ при полном или частичном отключении электропитания, аварии сетей телекоммуникации, полном или частичном отказе технических средств Модуля СЦ. Технические решения должны обеспечивать сохранность информации в случае возникновения следующих событий (аварий, отказов и т.п.): – отказ аппаратного обеспечения на сервере; – отключение питания на сервере; – отказ аппаратного обеспечения на рабочей станции; – отключение питания на рабочей станции администратора; – отказ линий связи, в том числе при осуществлении обмена данными - 4.5.8. Требования к защите от влияния внешних воздействий Требования к защите от влияния внешних воздействий не предъявляются - 4.5.9. Требования к патентной чистоте и патентоспособности 4.5.9.1. Исключительные права на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, базы данных, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, принадлежат Российской Федерации в лице Заказчика. Право собственности на результаты работ, отчетные документы и материалы, полученные в ходе выполнения работ по Контракту, принадлежат Российской Федерации в лице Заказчика и считаются переданными с момента подписания Сторонами Акта сдачи-приемки выполненных работ. Разработанное программное обеспечение поставляется вместе с исходными кодами. 4.5.9.2. Все проектные и технические решения должны отвечать требованиям четвертой части Гражданского кодекса Российской Федерации. Результаты Работ должны быть свободными от возможности предъявления любых прав и притязаний третьих лиц, основанных на промышленной, интеллектуальной или другой собственности. 4.5.9.3 Результаты выполненных Работ не должны повлечь необходимость осуществления Заказчиком закупок программного обеспечения (как исключительных, так и неисключительных прав) для обеспечения функциональности Системы в соответствии с Техническим заданием. При выполнении работ Подрядчик должен использовать только объекты интеллектуальной собственности, права на которые приобретены (получены) и используются без нарушений прав на интеллектуальную собственность третьих лиц или предоставлены Заказчиком - 4.4.2. Требования к математическому обеспечению Требования к математическому обеспечению не предъявляются. 4.4.3. Требования к метрологическому обеспечению Требования к метрологическому обеспечению не предъявляются. 4.4.4. Требования к организационному обеспечению Требования к организационному обеспечению не предъявляются. 4.4.5. Требования к методическому обеспечению Задачи методического обеспечения Модуля СЦ должны быть обеспечены за счет использования технологических и методических документов касающихся вопросов функционирования транспортного комплекса и разработки и эксплуатации ПО. 4.4.6. Требования к информационному обеспечению Состав, структура и способы организации информационного обеспечения в Модуле СЦ должны быть определены на этапе технического проектирования. Факты информационного обмена с внешними системами должны фиксироваться в соответствующем журнале - 4.4.7. Требования к программному обеспечению Общесистемное ПО, используемое в составе Модуля СЦ, должно быть зарегистрировано в Едином реестре российских программ для электронных вычислительных машин и баз данных и соответствовать рекомендованным показателям эффективности и соответствующим им значениям индикаторов эффективности перехода подведомственных организаций на использование российского ПО, заданных Приказом Минцифры России от 18.01.2023 № 21 «Об утверждении методических рекомендаций по переходу на использование российского программного обеспечения, в том числе на значимых объектах критической информационной инфраструктуры Российской Федерации, и о реализации мер, направленных на ускоренный переход органов государственной власти и организаций на использование российского программного обеспечения в Российской Федерации». Применяемое в системе программное обеспечение должно соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации, постановления Правительства Российской Федерации от 23 декабря 2024 г. № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц» - Прикладное программное обеспечение должно отвечать следующим требованиям: – совместимость программных продуктов в части используемых технических средств, системного программного обеспечения и общесистемной инфраструктуры в пределах требований к техническому обеспечению, а также их информационная совместимость в пределах требований к информационному обмену; – обеспечение трехуровневой архитектуры с разделением на уровень хранения данных (сервер БД), уровень бизнес-логики (сервер приложений) и уровень представления ( - 4.5.4. Требования к надежности Должно быть предусмотрено сохранение работоспособности Модуля СЦ при некорректных действиях пользователя и сохранение целостности данных при нештатном завершении работы Модуля СЦ (отказ рабочей станции, потеря сетевого доступа и т.п.). Модуль СЦ должен предоставлять механизмы обеспечения сохранности данных через применение процедур резервного копирования и восстановления, описанных в документации на Систему. Ключевые показатели надежности информационной системы — допустимое время на восстановление работоспособности Модуля СЦ (RTO - recovery time objective) и/или допустимый интервал времени потери изменений в данных при сбоях/отказах (RPO – recovery point objective) должны быть определены Подрядчиком и согласованы с Заказчиком на этапе технического проектирования - 4.5.5. Требования к информационной безопасности Работы по защите информации/информационной безопасности, не включенные в состав настоящего раздела, требуемые в соответствии с требованиями постановления Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации», а также нормативно правовых актов в области защиты персональных данных и обеспечения безопасности объектов критической информационной инфраструктуры, будут проведены в рамках исполнения отдельного контракта, заключенного по результатам отдельной закупочной процедуры (не является частью данного ТЗ), включающего: – определение актуальных угроз безопасности информации и актуализация модели угроз безопасности информации (при необходимости); – выполнение требований о согласовании технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России в установленном порядке; – выполнение требований по устранению Подрядчиком замечаний и недостатков, в случае их выявления при согласовании Заказчиком технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России; – выполнение требований к классу защищенности ГИС, уровню защищенности персональных данных и категории значимости объекта КИИ РФ, установленных для Головного центра обработки данных ФГБУ «СИЦ Минтранса России» (далее – ГЦОД); - 4.5.9.4. Подрядчик подтверждает, что обладает всеми правами на передачу Заказчику исключительных прав в соответствии с требованиями настоящего раздела Технического задания. В случае, если к Заказчику по вине Подрядчика будут предъявлены претензии в этой части, иски третьих лиц, связанные с нарушением их прав, Подрядчик принимает на себя такие претензии и иски и возмещает Заказчику все расходы и весь ущерб, понесенный в связи с ними. 4.5.9.5. Подрядчик обязан согласовать с Заказчиком необходимость использования при выполнении работ охраняемых результатов интеллектуальной деятельности, права на которые принадлежат Подрядчику или третьим лицам. 4.5.9.6. В случае, если при выполнении Работ используется готовое программное обеспечение (платформа, подсистема, СУБД и т.д.), которое становится частью (компонентом) Системы, Заказчику передаются полные исключительные права, или неисключительные права (путем заключения лицензионного/сублицензионного договора/соглашения) на такое программное обеспечение со следующими возможностями: – права передаются бессрочно (на весь срок действия исключительных прав); – территория действия Российская Федерация; – должно быть обеспечено право Российской Федерации (в лице Заказчика) передавать, дорабатывать, распространять, развивать результаты работ, созданные в процессе исполнения Контракта, а также перерабатывать такое программное обеспечение. Лицензионное (сублицензионное) соглашение (договор), Акт передачи прав, подписанные Подрядчиком, согласие правообладателя, оформленное в соответствии с положениями Гражданского кодекса Российской Федерации (в случае, если Подрядчик не является правообладателем такого программного обеспечения), инструкция по инсталляции, руководство администратора, руководство пользователя передаются Заказчику в сроки, установленные Техническим заданием для соответствующего функционала Системы - Лицензионное (сублицензионное) соглашение (договор) не может возлагать на Заказчика какие-либо обязанности (в т.ч. в части конфиденциальности, предоставления отчетности), не предусмотренные Контрактом. 4.5.9.7. Передача Заказчику исключительных прав, или простых (неисключительных) прав не может повлечь увеличение стоимости Контракта и/или изменение иных существенных условий Контракта. 4.5.9.8. Функциональность Модуля СЦ передается в объеме и в сроки, установленные Техническим заданием. 4.5.9.9. Нарушение условий настоящего раздела Технического задания, в т.ч. отсутствие соответствующего лицензионного (сублицензионного) соглашения (или договора), либо предоставление лицензионного (сублицензионного) соглашения (или договора), не соответствующего требованиям действующего законодательства Российской Федерации или требованиям Контракта, является нарушением существенных условий Контракта. 4.5.9.10. В случае, если в соответствии с пунктом 4.5.9.6 Заказчику передается исключительное право, такая передача осуществляется в порядке, установленном Гражданским кодексом Российской Федерации. 4.5.9.11. В случае, если при выполнении Работ положения пунктов 4.5.9.5-4.5.9.6 не применялись, Подрядчик в составе отчетной документации предоставляет об этом декларацию в свободной форме. Декларация должна содержать сведения о полном соответствии результата Работ требованиям Контракта, а также о неприменении при выполнении работ готового программного обеспечения (платформ, подсистем, СУБД и т.д.), которое стало частью (компонентом) Системы - – определение перечня объектов защиты информационной системы; – описание (актуализированных) требований к системе защиты информации, а также к мерам защиты информации информационной системы в зависимости от установленных классов защищенности, уровня защищенности персональных данных и категории значимости объектов КИИ РФ (приказы ФСТЭК России № 21, 117, 239); – выполнение требований к мерам по защите ГИС от атак, направленных на отказ в обслуживании, в соответствии с пунктами 30, 34, 59, 63 Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений, утвержденных приказом ФСТЭК России от 11.04.2025 № 117; – описание (актуализированных) требований по защите информации, подлежащих реализации в информационно телекоммуникационной инфраструктуре ГЦОД; – выполнение требований о применении сертифицированных средств защиты информации, включая их классы защиты и уровни доверия; – выполнение требований о запрете использования с 01.01.2025 органами (организациями) средств защиты информации странами происхождения, которых являются иностранные государства в соответствии с пунктом 6 Указа Президента Российской Федерации от 01.05.2022 № 250; – выполнение требований по обеспечению непрерывного взаимодействия с ГосСОПКА в установленном порядке; - – выполнение требований по обеспечению в автоматизированном режиме с Национальной системой противодействия DDoS-атакам (НСПА) Центра мониторинга и управления сетью связи общего пользования ФГУП «ГРЧЦ» в рамках реализации мер по защите ГИС от атак, направленных на отказ в обслуживании; – детализированные требования к составу и содержанию работ по аттестации, а также к их результатам в соответствии с пунктами 13, 15 и 16 требований приказа ФСТЭК России от 29.04.2021 № 77 «Об утверждении Порядка организации и проведения работ по аттестации объектов информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну» - 4.5.9.12. Передача Заказчику комплекта документов, материалов и сведений, предусмотренных нормативными правовыми актами Российской Федерации в сфере информационных технологий, защиты информации, правовой защиты интересов государства в области интеллектуальной собственности, включая документы, подтверждающие отказ авторов (разработчиков) от исключительных прав на передаваемые объекты интеллектуальной собственности в пользу Подрядчика, с проектами заявок на государственную регистрацию в установленном порядке прав Заказчика на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, базы данных, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, осуществляется Подрядчиком в составе отчетной документации, предусмотренной условиями Контракта. 4.5.9.13. По результатам выполнения работ по развитию системы должны быть подготовлены материалы для регистрации доработанной версии Системы (объекта учета) в НФАП в соответствии с требованиями постановления Правительства Российской Федерации от 30 января 2013?г. №?62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин» (с изменениями и дополнениями) в части обязательности размещения результатов работ в национальном фонде алгоритмов и программ для электронных вычислительных машин - 4.5.10. Требования по стандартизации и унификации К Модулю СЦ предъявляются следующие требования в части стандартизации и унификации: – работы по развитию Модуля СЦ должны производиться в соответствии с действующими стандартами и нормами Российской Федерации; – при создании и модернизации элементов Модуля СЦ следует руководствоваться действующими в Российской Федерации национальными стандартами и другими нормативно-техническими документами; – используемые оборудование и материалы, подлежащие обязательной сертификации, должны иметь соответствующие сертификаты; – ПО Модуля СЦ должно проектироваться и разрабатываться с учётом обеспечения требований унификации; – применяемые при создании Модуля СЦ технические (форматы данных, протоколы передачи и прочие) и организационные (регламенты, требования, инструкции) решения должны быть доступны и документированы в виде, достаточном для независимой (без обращения к Подрядчику) реализации третьими сторонами; – термины, обозначения и наименования, используемые в ПО, должны быть стандартизованы и унифицированы, выполнены на русском языке; – взаимодействие элементов и их внешнее поведение должно быть реализовано одинаково и производиться по единым правилам - 5. СОСТАВ И СОДЕРЖАНИЕ РАБОТ ПО РАЗВИТИЮ И ТЕХНИЧЕСКОЙ ПОДДЕРЖКЕ МОДУЛЯ СЦ (КАЛЕНДАРНЫЙ ПЛАН) - Сдача-приемка результатов выполненных работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная техническая документация, а также результаты работ предоставляются Заказчику в порядке, предусмотренном Контрактом и ТЗ, до размещения Подрядчиком в ЕИС документа о приемке. Документ о приемке размещается в ЕИС по каждому этапу в соответствии с условиями Контракта. Этапы выполнения работ по развитию Модуля СЦ приведены в Таблице 11. Таблица 11. Этапы выполнения работ по развитию Модуля СЦ. № этапа Наименование этапа Результат (отчетная документация) Срок исполнения этапа - - Значение характеристики не может изменяться участником закупки - Работы по развитию Системы (за исключением этапов проведения опытной эксплуатации и услуг по технической поддержке) могут быть выполнены досрочно. При досрочном выполнении работ (этапов работ) Подрядчик в письменной форме уведомляет Заказчика о готовности представить для приемки результаты проведения работ в соответствии с требованиями Контракта. Подрядчик также вправе досрочно приступать к работам в рамках очередного этапа при наличии технической, организационной готовности - при условии получения соответствующего согласования Заказчиком. Сдача-приемка результатов выполненных работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная, техническая документация, а также результаты Работ по каждому этапу предоставляется Заказчику в порядке, предусмотренном Контрактом и настоящим Техническим заданием, до размещения Подрядчиком в Единой информационной системе в сфере закупок документа о приемке. Документ о приемке размещается в ЕИС по каждому этапу в соответствии с условиями Контракта. Согласование документов осуществляется в электронном виде посредством переписки с адресов электронной почты Заказчика и Подрядчика, указанных в контракте. - 1 Техническое проектирование Сопроводительным письмом предоставляются Заказчику: · Технический проект, включая следующие документы: – Ведомость технического проекта; – Ведомость машинных носителей информации – Пояснительная записка; – Описание информационного обеспечения системы; – Описание автоматизируемых функций; – Схема функциональной структуры; – Описание организации информационной базы; – Описание программного обеспечения; · Макеты экранных форм компонента «Интерактивная карта»; · Руководство по безопасной разработке программного обеспечения; · Документ о приемке Начало: с даты заключения контракта Окончание: не позднее 31.07.2026 - 2 Услуги по технической поддержке Модуля СЦ (с даты заключения контракта по 10.09.2026) По окончании оказания Услуг сопроводительным письмом предоставляются Заказчику: – Отчет об оказанных Услугах по технической поддержке; – Актуальные на дату окончания оказания Услуг по данному этапу исходные коды прикладного ПО на электронном носителе (в случае внесения изменений); – Инструкция по сборке и развертыванию (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство пользователя (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство администратора (в случае внесения изменений); – Документ о приемке Начало: с даты заключения контракта Окончание: не позднее 10.09.2026 - 3 Разработка программного обеспечения (1 очередь, пп. 4.2.1, 4.2.6 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ; – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 1 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 1 очереди; – Руководство по резервному копированию; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 16.09.2026 - 4 Разработка программного обеспечения (2 очередь, пп. 4.2.3, 4.2.4 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ. – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 2 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 2 очереди; – Руководство по резервному копированию; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 25.09.2026 - 5 Разработка программного обеспечения (3 очередь, пп. 4.2.2, 4.2.5 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ; – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 3 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 3 очереди; – Руководство по резервному копированию; – Описание ролевой модели; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 09.10.2026 - 6 Опытная эксплуатация (1 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акт о завершении опытной эксплуатации 1 очереди; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке 17.09.2026 Окончание: не позднее 26.10.2026 - 7 Опытная эксплуатация (2 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акт о завершении опытной эксплуатации 2 очереди; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке 26.09.2026 Окончание: не позднее 26.10.2026 - 8 Опытная эксплуатация (3 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Акт о завершении опытной эксплуатации 3 очереди; – Документ о приемке Начало: с 10.10.2026 Окончание: не позднее 26.10.2026 - 9 Приемочные испытания Сопроводительным письмом предоставляются Заказчику: – Программа и методика приёмочных испытаний; – Протокол приемочных испытаний; – Исходные коды и дистрибутивы на электронном носителе (при условии внесения изменений, с учетом доработок по результатам опытной эксплуатации и проведенных испытаний); – Комплект рабочей документации на Модуль СЦ (при условии внесения изменений, с учетом доработок по результатам опытной эксплуатации и проведенных испытаний); – Акт приемки Системы в эксплуатацию; – Акт приемки-передачи исключительных прав на объект; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке; – Документы в соответствии с разделом 4.5.9 ТЗ; – Обеспечение гарантийных обязательств Начало: с 27.10.2026 Окончание: не позднее 10.11.2026 - 10 Услуги по технической поддержке Модуля СЦ (с 11.09.2026 по 15.12.2026) По окончании оказания Услуг сопроводительным письмом предоставляются Заказчику: – Отчет об оказанных Услугах по технической поддержке; – Актуальные на дату окончания оказания Услуг по данному этапу исходные коды прикладного ПО на электронном носителе (в случае внесения изменений); – Инструкция по сборке и развертыванию (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство пользователя (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство администратора (в случае внесения изменений); – Документ о приемке Начало: с 11.09.2026 Окончание: не позднее 15.12.2026 - 6. ПОРЯДОК РАЗРАБОТКИ МОДУЛЯ СЦ - Проектирование Модуля СЦ должно включать разработку следующих документов: – Ведомость технического проекта; – Ведомость машинных носителей информации – Пояснительная записка; – Описание информационного обеспечения системы; – Описание автоматизируемых функций; – Схема функциональной структуры; – Описание организации информационной базы; – Руководство по безопасной разработке программного обеспечения; – Описание программного обеспечения; – Макеты экранных форм компонента «Интерактивная карта». Структура документов должна соответствовать ГОСТ Р 59795-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов». Разработка Модуля СЦ должна включать в себя: – разработку программного обеспечения в части новых функций Модуля СЦ; – сборка исходного кода, развертывание и настройку доработанного программного обеспечения Модуля СЦ на вычислительных мощностях Заказчика (тестовый контур); – Комплект рабочей документации на Модуль СЦ; – разработку документа «Программа и методика предварительных испытаний»; – разработку документа «Программа и методика приемочных испытаний»; – разработку документа «Программа опытной эксплуатации». Структура документов должна соответствовать ГОСТ Р 59795-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов». В ходе выполнения работ формируется правоустанавливающая, отчетная, рабочая и техническая документация в соответствии с Контрактом и Календарным планом, приведенном в разделе 5. - - Значение характеристики не может изменяться участником закупки - 6.1. Сведения о гарантийном обслуживании Модуля СЦ Под гарантией понимается устранение Подрядчиком своими силами и за свой счет допущенных по его вине недостатков, выявленных после приемки выполненных Работ, как в работе самой Модуля СЦ, так и недостатков в отчетной документации. Если в период гарантийного срока обнаружатся недостатки, то Подрядчик обязан устранить их за свой счет, в сроки, установленные Заказчиком. Гарантийный срок в этом случае продлевается на период устранения недостатков. Срок гарантии: 1 год с даты приемки Заказчиком результатов исполнения Этапа № 9 контракта. Подрядчиком должны быть внесены соответствующие исправления в техническую и рабочую документацию (указанную в пунктах 5 и 6 настоящего ТЗ), связанные с устранением замечаний к работе Модуля СЦ или в случае выявления Заказчиком недостатков в такой документации в период гарантийного срока. Внесение изменений в документацию технического и рабочего проектирования осуществляется в соответствии с ГОСТ 2.503-2023 и ГОСТ Р 2.504-2021. - 7. ПОРЯДОК КОНТРОЛЯ И ПРИЕМКИ РЕЗУЛЬТАТОВ ВЫПОЛНЕНИЯ РАБОТ ПО РАЗВИТИЮ МОДУЛЯ СЦ - Испытания должны быть организованы и проведены в соответствии с ГОСТ Р 59792-2021 «Информационная технология. Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем». Должны быть проведены следующие виды испытаний: – предварительные испытания; – опытная эксплуатация; – приемочные испытания. Указанные виды испытаний проводятся в отношении не функциональных требований и функциональных возможностей, разрабатываемых в соответствии с настоящим ТЗ. Отдельные виды испытаний проводятся поэтапно в сроки, установленные Календарным планом. Предварительные испытания, опытная эксплуатация, приемочные испытания проводятся комиссией, создаваемой организационно-распорядительным документом Заказчика, который должен определять состав комиссии, порядок ее работы. Методы предварительных испытаний и порядок их проведения должны быть определены в документе «Программа и методика предварительных испытаний», который должен быть утвержден Заказчиком до начала предварительных испытаний. По результатам предварительных испытаний оформляется Протокол предварительных испытания и Акт о приемке в опытную эксплуатацию. Порядок проведения и методы испытаний во время опытной эксплуатации должны быть определены в документе «Программа опытной эксплуатации», который должен быть утвержден Заказчиком до начала опытной эксплуатации. Ход и результаты опытной эксплуатации отражаются в документе «Журнал опытной эксплуатации», и учитываются в ходе приемочных испытаний. По результатам опытной эксплуатации подписывается Акт о завершении опытной эксплуатации - - Значение характеристики не может изменяться участником закупки - До момента подключения внешних ИС, Подрядчиком могут быть использованы эмуляторы ИС для прохождения предварительных испытаний, опытной эксплуатации и приемочных испытаний. В рамках опытной эксплуатации должны быть проведены мероприятия по нагрузочному тестированию Модуля СЦ. Документ «Программа и методика приемочных испытаний» должен быть разработан с учетом недостатков, выявленных в ходе опытной эксплуатации, утвержден Заказчиком до начала приемочных испытаний, при этом проверки Модуля СЦ в части не устраненных недостатков, выявленных в процессе опытной эксплуатации, должны быть вынесены в отдельный раздел «Программы и методики приемочных испытаний». В процессе приемочных испытаний должно быть проверено устранение недостатков, полученных в ходе опытной эксплуатации. После завершения устранения всех замечаний, препятствующих приемке Системы в эксплуатацию, перечисленных в Протоколе приемочных испытаний, Подрядчик должен письменно уведомить Заказчика о том, что все замечания устранены, после чего приемочные испытания по решению Заказчика могут быть проведены повторно. Процедура приемочных испытаний проводится до подписания Протокола приемочных испытаний, не содержащего замечаний, препятствующих приемке Системы в эксплуатацию. Приемочные испытания Системы считаются завершенными успешно, если Протокол приемочных испытаний не содержит замечаний, препятствующих приемке Системы в эксплуатацию - 8. ТРЕБОВАНИЯ К СОСТАВУ И СОДЕРЖАНИЮ РАБОТ ПО ПОДГОТОВКЕ МОДУЛЯ СЦ К ВВОДУ В ЭКСПЛУАТАЦИЮ - По результатам проведения приемочных испытаний оформляется Протокол приемочных испытаний и Акт приемки в эксплуатацию. В случае, если взаимодействие с внешними системами не может быть проверено на средах постоянной эксплуатации взаимодействующих систем (по причине неготовности со стороны внешней системы или иным причинам), функции взаимодействия, разработанные в соответствии с требованиями ТЗ, должны быть проверены на тестовых данных с использованием программ-имитаторов взаимодействия. По результатам выполнения этапа приемочных испытаний должны быть подготовлены материалы для регистрации доработанной версии Модуля СЦ (объекта учета) в НФАП в соответствии с требованиями постановления Правительства Российской Федерации от 30 января 2013?г. №?62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин» (с изменениями и дополнениями) в части обязательности размещения результатов работ в национальном фонде алгоритмов и программ для электронных вычислительных машин. Сдача-приемка результатов выполнения Работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная, техническая документация, а также программное обеспечение предоставляется Заказчику в порядке, предусмотренном Контрактом и ТЗ до размещения Подрядчиком в Единой информационной системе в сфере закупок документа о приемке. Результаты проведения опытной эксплуатации, предварительных и приемочных испытаний должны быть зафиксированы в соответствующих протоколах и актах. Выявленные отклонения от настоящего ТЗ, оформляются как недостатки Модуля СЦ - - Значение характеристики не может изменяться участником закупки - Протоколы предварительных и приемочных испытаний должны содержать вывод о соответствии Модуля СЦ предъявляемым требованиям, а также сроки устранения замечаний и реализации рекомендаций, сформулированных комиссией в ходе предварительных и приемочных испытаний. Условием для передачи Модуля СЦ в промышленную эксплуатацию является устранение всех замечаний. Документация на Модуль СЦ и ее части (техническая и рабочая) должна содержать исчерпывающее описание принятых проектных решений в объеме, достаточном для ее дальнейшего развития и эксплуатации. Техническая и рабочая документация должна содержать описание разработанных результатов работ, в том числе программ для ЭВМ, прикладных программных интерфейсов, алгоритмов и протоколов информационного взаимодействия, технических требований, спецификаций и форматов обмена данными для взаимодействия с другими информационными системами, в объеме, достаточном для их установки, настройки, эксплуатации и развития в дальнейшем без привлечения Подрядчика. Исходные коды передаются в виде и составе, позволяющем провести: – сборку (компиляцию) Модуля СЦ в контролируемой Заказчиком среде; – установку полученной Модуля СЦ на специально подготовленную контролируемую Заказчиком инфраструктуру; – проверку функциональных возможностей Модуля СЦ; – оформление Модуля СЦ в качестве объекта национального фонда алгоритмов и программ для электронных вычислительных машин - 8.1. Требования, предъявляемые в соответствии с Приказом Минцифры России от 17.12.2020 № 715 «Об утверждении типовых условий контрактов на выполнение работ по созданию и (или) развитию (модернизации) государственных (муниципальных) и (или) иных информационных систем» Передача исходных кодов, разработанных в ходе выполнения работ, программ для электронных вычислительных машин (далее – программа для ЭВМ) должна сопровождаться передачей всех необходимых для сборки и запуска программы для ЭВМ библиотек зависимостей, программных сценариев (скриптов) для проведения установки (развертывания) программы для ЭВМ. Подрядчик в процессе сдачи-приемки работ по Контракту должен провести демонстрацию процесса и установки (развертывания) разработанных программ для ЭВМ. Документация на Модуль СЦ должна содержать описание принятых проектных решений в объеме, достаточном для ее дальнейшего развития и эксплуатации - 9. ТРЕБОВАНИЯ К ДОКУМЕНТИРОВАНИЮ - 9.1. Общие требования Документация на Модуль СЦ должна быть разработана в составе, указанном в разделах 5-8 данного ТЗ, и должна удовлетворять требованиям комплекса стандартов и руководящих документов на автоматизированные системы: – ГОСТ Р 2.105-2019 в части оформления текстовых документов; – ГОСТ 34.201-2020 в части наименования и обозначения документов. Документация на Модуль СЦ должны оформляться на листах формата А4. Допускается для размещения рисунков и таблиц использование листов формата А3 с подшивкой по короткой стороне листа. Документы объемом более 25 (двадцати пяти) листов должны содержать информационную часть, состоящую из аннотации и содержания. Исходные коды должны быть представлены в 1 (одном) экземпляре на электронном носителе, отчетные материалы должны быть представлены в 2 (двух) экземплярах на бумажном носителе (по одному экземпляру для Заказчика и Подрядчика) и в 1 (одном) экземпляре на электронном носителе в формате документов DOCX и PDF. При разработке документов на Модуль СЦ допускается отклонение от требований комплекса стандартов, описанных выше. Документам на Модуль СЦ должны в обязательном порядке присваиваться уникальные децимальные номера в соответствии с порядком, установленном в ГОСТ 34.201-2020. Документ «Программа и методика предварительных испытаний» должен включать приложения с формой протокола предварительных испытаний и формой акта приемки в опытную эксплуатацию. Документ «Программа опытной эксплуатации» должен включать приложение с формой журнала опытной эксплуатации. Документ «Программа и методика приемочных испытаний» должен включать приложения с формой протокола приемочных испытаний и формой акта приемки в эксплуатацию - - Значение характеристики не может изменяться участником закупки - 10. ИСТОЧНИКИ РАЗРАБОТКИ - 10.1. Список литературы Специальная литература для разработки ТЗ не использовалась. 10.2. Нормативно-методические документы Список используемых нормативно-методических документов представлен в разделе 1.6 технического задания. ? Приложение А Эскизы визуального оформления компонента «Интерактивная карта» - - Значение характеристики не может изменяться участником закупки - Приложение Б Параметры оказания услуг - 1 Режим работы Системы Круглосуточно (24х7) 2 Режим доступности информационно-консультационной поддержки пользователей Системы 2.1 Прием и регистрация обращений (заявок) в СРО Регистрация обращений (заявок) производится круглосуточно в режиме 24х7, без праздников и выходных дней. Обработка заявок первой линией поддержки осуществляется в рабочие дни с 9 до 18 часов 2.2 Консультирование сотрудников Заказчика и пользователей Системы в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 3 Режим доступности по решению инцидентов, связанных с работой ППО: 3.1 - приоритет «Критический» Круглосуточно (24х7) 3.2 - приоритет «Высокий» Круглосуточно (24х7) 3.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 3.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4 Режим доступности услуг по адаптации, конфигурации и коррекционному сопровождению Системы 4.1 - приоритет «Критический» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.2 - приоритет «Высокий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 5 Режим доступности по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности 5.1 - приоритет «Критический» Круглосуточно (24х7) 5.2 - приоритет «Высокий» Круглосуточно (24х7) 5.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 5.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) - - Значение характеристики не может изменяться участником закупки - Таблица Б.1.2. Сроки предоставления отчетности, с момента получения запроса № п/п Параметр Значение 1 Предоставление отчета об оказанных услугах за произвольный период 10 рабочих дней 2 Предоставление подробной информации по инциденту с приоритетом «Критический» 16 рабочих часов 3 Предоставление актуализированной документации 10 рабочих дней - Б.2. Приоритеты и регламентные сроки решения обращений (заявок) В зависимости от уровня сбоя в работе Системы обращению (заявке) присваивается один из следующих приоритетов, а также в зависимости от приоритета обращения (заявки) устанавливаются следующие контрольные сроки решения в соответствии с таблицей ниже (Таблица Б.2.1). Таблица Б.2.1 – Приоритеты и регламентные сроки решения обращений (заявок) № п/п Приоритет Максимальное время реагирования Время решения (срок выполнения) Описание приоритета По информационно-консультационной поддержке сотрудников Заказчика и пользователей Системы 1 - не более 1 часа не более 10 часов - По решению инцидентов, связанных с работой ППО: 1 Критический не более 30 минут не более 4 часов - полная недоступность ППО; - недоступность ключевых функций - ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО; - невозможность информационного обмена с ППО для ИС более 4 часов 2 Высокий не более 1 часа не более 8 часов - ошибки/сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; - снижение быстродействия СПО (время отклика ППО на операции превышает 30 секунд); - недоступность управления правами и ролями пользователей 3 Средний не более 4 часов не более 24 часов - невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым -недоступность функции формирования отчетов 4 Низкий не более 8 часов не более 40 часов - отклонение в работе ППО, не влияющее на корректную работу функций; - другие сбои и ошибки, затрагивающие основные функции ППО - По адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) 1 Критический не более 40 минут не более 8 часов - изменения, необходимые при проведении аварийно-восстановительных работ для возобновления работоспособности Системы; - изменения, связанные с критичными ошибками, блокирующими возможность оказания государственных услуг и/или чтение и внесение данных в Систему 2 Высокий не более 1 часа не более 40 часов - изменения, относящиеся к обеспечению работоспособности основной функциональности Системы, устраняют выявленные дефекты в работе Системы, оказывающие существенное влияние на работу пользователей в Системе; - изменения, затрагивающие три и более подсистемы/модуля Системы для адаптации 3 Средний не более 4 часов не более 72 часов - изменения, связанные с развитием/улучшением/оптимизацией Системы и выводом новой функциональности в штатном режиме для одного-двух модулей/подсистем; - изменения, связанные с развитием интеграционных механизмов Системы, например обновление существующих и/или реализация новых видов сведений СМЭВ, обновление существующих и/или реализация новых API, адаптация и/или изменение механизмов импорта и экспорта данных Системы и т.д. 4 Низкий не более 8 часов не более 160 часов - изменения, связанные с ошибками/корректировкой/изменением в отображении информации в пользовательском графическом интерфейсе Системы (графика, текст, органы управления, элементы интерфейса) - По устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности 1 Критический не более 30 минут не более 24 часов - критические уязвимости, влияющие на возможную полную недоступность ППО, ключевых функций Системы, ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО без возможности восстановления работоспособности Системы. - Критический уровень CVSS > 8.0 2 Высокий не более 1 часа не более 84 часов - критические уязвимости, влияющие на ошибки и сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО. - Высокий уровень CVSS 5.0 - 8.0 3 Средний не более 4 часов не более 120 часов - уязвимости, влияющие на невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым - Средний уровень CVSS 2.0 - 4.9 4 Низкий не более 8 часов не более 160 часов - уязвимости, влияющие на отклонение в работе ППО, не влияющее на корректную работу функций; - другие сбои и ошибки, затрагивающие основные функции ППО - Низкий уровень CVSS < 2.0 - Взаимодействие Заказчика и Подрядчика в части регистрации и контроля времени реагирования и решения обращения (заявки) осуществляется через СРО. Заказчик предоставляет Подрядчику доступ к СРО после заключения Контракта. Поступившие от разных пользователей заявки по поводу однотипных инцидентов или имеющие общую причину должны объединяться в одну заявку. Срок выполнения включает время диагностики инцидента, в ходе которого определяется причина инцидента (проблемы) и способ его устранения. Подрядчик должен обеспечить функционирование Модуля СЦ в соответствии с требованиями и параметрами, указанными в настоящем ТЗ и Регламенте оказании услуг. Основные параметры быстродействия типовых операций в Модуле СЦ указаны в таблице ниже (таблица Б.2.2). Таблица Б.2.2 - Параметры быстродействия Модуля СЦ № п/п Наименование параметра Значение (секунд) 1 Среднее время получения сообщения из очереди сообщений 10 2 Среднее время получения ответа от Системы 5 3 Среднее время открытия карточки реестра 5 - Б.1. Базовые параметры оказания Услуг Базовые параметры оказания Услуг приведены ниже: – режимы оказания Услуг (таблица Б.1.1); – сроки предоставления отчетности (таблица Б.1.2). Таблица Б.1.1 - Режимы оказания Услуг № п/п Параметр Значение - Приложение В Регламент оказания услуг - 2.2 Общее описание процесса оказания сопровождения (технической поддержки) Системы Процесс оказания технической поддержки Системы включает: 1. Поступление обращений (заявок) от пользователей и их регистрацию. 2. Сопровождение обращений (заявок) в соответствии с их классификацией и приоритизацией, в том числе, с их последующей эскалацией. 3. Определение ролей и регламент их взаимодействия при осуществлении деятельности по процессу. 4. Решение обращений (заявок) в установленные настоящим Регламентом сроки. 5. Взаимодействие между 1-м, 2-м и 3-м уровнями технической поддержки, в том числе, с формированием заданий для сопровождения Системы. 6. Контроль качества выполняемых Исполнителем работ, состоящий из проверки сценария, приводящего к ошибке, зафиксированной в Инциденте, и/или к ошибке воспроизведения, а также тестирование внесенных изменений в рамках ЗНИ. 7. Обеспечение мониторинга и проведение анализа процесса обработки поступающих в техническую поддержку обращений (заявок). Техническая поддержка реализуется путем проведения ответственными сотрудниками соответствующей информационно-консультационной деятельности в соответствии с определенными ролями, а также выполнения Исполнителем конкретных действий по своевременному выявлению причин сбоев и аварийных ситуаций и их устранению, а также по адаптации, конфигурированию, корректировке Системы, включая выполнение процедур тестирования и участия в обновлениях Системы. Все роли подразделяются на уровни поддержки, взаимодействующие между собой в соответствии с блок-схемой процесса технической поддержки. Общая схема процесса рассмотрения обращений (заявок) в соответствии с видами технической поддержки представлена на рисунке 1. . Рисунок 1 - Общая схема процесса рассмотрения обращений (заявок) в соответствии с видами технической поддержки - - Значение характеристики не может изменяться участником закупки - 2.3 Каналы связи Должна быть предусмотрена омниканальность в части приема обращений (заявок). Получение обращений (заявок) технической поддержкой происходит по следующим каналам связи: – СРО; – электронная почта; – телефонная линия. Исполнитель обеспечивает прием обращений (заявок) от Заказчика и предоставляет информацию в рамках оказания услуг по техническому сопровождению Системы, руководствуясь матрицей взаимодействия, приведенной в Приложении 1 к настоящему Регламенту - 3 Порядок оказания Услуг 3.1 Типы обращений (заявок) Обращения и заявки Заказчика классифицируются в соответствии с приоритетами и регламентными сроками, указанными в Приложении 2 к настоящему Регламенту. Регистрация обращений и заявок предусматривает создание новой записи в СРО с присвоением поступившему обращению или заявке (новой записи) уникального идентификатора. Запись в СРО должна содержать вопрос или проблему, которую требуется решить или оказать консультацию. Если обращение или заявка автоматически зарегистрированы в СРО при отправке представителем Заказчика, Исполнитель проверяет корректность указанного типа обращения (заявки) и может обратиться к Заказчику с просьбой корректировки, предоставив обоснования в соответствии с настоящей классификацией (Таблица 1) - Таблица 1 - Типы обращений (заявок) Тип обращения (заявки) Описание Запрос на обслуживание Подготовка SQL запроса к СУБД для решения прикладной задачи и д р. – запрос на любое действие, не являющееся запросом информации и несовершенный на основе происшествия, прямо или косвенно влияющего на работу Системы Консультация (входит в тип обращения (заявки) «Запрос на обслуживание») «Где взять / куда обратиться...?», «Как сделать / выполнить…», «Как это работает…?» - запрос, имеющий своей целью получение информационной поддержки Инцидент Разбор ошибок/сбоев и подготовка материалов (корректировочных релизов, инструкций) для Заказчика для устранения ошибок/сбоев, которые приводят к частичному и полному нарушению работоспособности всех или отдельных функций ППО. Подготовка изменения и материалов, необходимых для проведения аварийно-восстановительных работ для возобновления работоспособности Системы. ЗНИ Подготовка изменений, связанных с изменением, улучшением/оптимизацией Системы и выводом новой модифицированной функциональности в штатном режиме. Подготовка изменений, связанных с модификацией существующих и/или реализация новых интеграционных механизмов для получения/обработки данных внешних систем. Подготовка изменений графического интерфейса по требованиям Заказчика - 3.2 Участники технической поддержки, осуществляющие сопровождение обращений (заявок) Техническая поддержка Системы должна быть организована на трех уровнях: 1. Первый и второй уровни технической поддержки организуется Заказчиком. 2. Третий уровень технической поддержки организуется Исполнителем. Зона ответственности каждого уровня технической поддержки указана в Таблице 2. Таблица 2 - Зона ответственности каждого уровня технической поддержки Участники технической поддержки Описание - Первый уровень технической поддержки (далее – 1-й уровень) Группа ответственных сотрудников 1-го уровня Заказчика, осуществляющая прием и первичную обработку обращений (заявок) (описание предмета обращения, первичная классификация и приоритизация, определение назначения, маршрутизация обращений (заявок) по назначению), руководствуется в своей работе настоящим Регламентом и БЗ, наполняемой 2-м уровнем поддержки, самостоятельно решает часть обращений (заявок), связанных с недостаточной квалификацией пользователей или настройками в рамках своей компетенции. В случае невозможности решения обращений (заявок) на 1-ом уровне ответственный сотрудник передает ее на 2-й уровень - Второй уровень технической поддержки (далее – 2-й уровень) Группа ответственных сотрудников 2-го уровня Заказчика по установленным компетенциям (информационная безопасность, сопровождение и эксплуатация информационно-аналитических систем, развитие информационно-аналитических систем, техническая поддержка информационно-аналитических систем) отвечает за поддержание работоспособности Системы, обработку обращений (заявок) и их решение в регламентные сроки в соответствии с установленными приоритетами. Осуществляет информационно-консультационную поддержку пользователей Системы в рамках своей компетенции. Оказывает экспертную помощь ответственным сотрудникам 1-го уровня в части формирования БЗ, содержащей ответы на часто задаваемые вопросы пользователей, с целью передачи знаний, навыков и инструментария на 1-й уровень для ускорения решения обращений (заявок). В случае невозможности решения обращения (заявки) на 2-ом уровне ответственный сотрудник передает его на 3-й уровень. При выявлении необходимости изменений в ППО Системы инициирует формирование обращения (заявки) и направляет его на группу ответственных сотрудников 3-го уровня по соответствующему классификатору (ЗНО, ЗНИ, и т.д.) - 4.3. Форма обращения (заявки) на оказание услуг по адаптационному конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) При подаче обращения (заявки) типа «ЗНИ» в СРО указывается (Таблица 7): Таблица 7 – Описание атрибутов формы обращения (заявки) на оказание услуг по адаптационному, конфигурационному и коррекционному сопровождению Системы Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 10) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 9) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 10) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 10) Категория обращения (заявки): запрос на изменение Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 7) Приоритет изменения Время, очередность решения обращения (заявки), ресурсы, привлекаемые для решения обращения (заявки), порядок/процедура действий при решении обращения (заявки) – поле СРО «Приоритет» (см. рисунок 7) Тип изменения Справочник, классифицирующий типовые запросы характерные для Системы – поле СРО «Предмет обращения» (см. рисунок 7) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 7) Текст запроса на оказание услуги по адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 7) - На рисунке 7 приведена форма обращения (заявки) типа «ЗНИ» в СРО. Рисунок 7 - Форма обращения (заявки) типа «ЗНИ» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуг по адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей), заполненную в свободной форме - 4.4. Форма обращения (заявки) на оказание услуги по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности При подаче обращения (заявки) типа «Инцидент» в СРО указывается (Таблица 8): Таблица 8 – Описание атрибутов формы обращения (заявки) на оказание услуг по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности - Третий уровень технической поддержки (далее – 3-й уровень) Группа ответственных сотрудников Исполнителя, отвечающая за устранение сбоев и аварий, проведение информационно-консультационной поддержки пользователей Системы, проведение адаптации и конфигурирования Системы в объемах действующих контрактов на оказание технической поддержки - 3.3 Перечень и описание статусов обращений (заявок) В Таблице 3 приведен перечень статусов обращений (заявок), действующий в СРО, и их описание. Таблица 3 - Перечень статусов обращений (заявок) и их описание Статус Описание Зарегистрирован Обращение (заявка) принято и зарегистрировано Направлен в группу Присваивается при назначении ответственными сотрудниками 1-го уровня группе ответственных сотрудников 2-го уровня по тематике обращения (заявки) после заполнения всей необходимой информации и полей обращения (заявки), а также при его передаче между группами 2-го уровня Передан в группу Присваивается при передаче обращения (заявки) ответственными сотрудниками 2-го уровня на группу ответственных сотрудников 3-го уровня Назначен Присваивается при назначении обращения (заявки) на ответственного сотрудника для его решения в рамках компетенции В работе Присваивается при приеме обращения (заявки) в работу ответственным сотрудником для его решения Решен Присваивается ответственным сотрудником, выполнившим работы по обращению (заявке) Закрыт Присваивается автоматически при решении запроса по обращению (заявке), а также отсутствии дополнительных запросов пользователя в соответствии с действующим SLA, или при подтверждении решения обращения (заявки) со стороны пользователя Запрос доп. информации Присваивается при необходимости запроса дополнительной информации и/или уточнения предмета обращения по обращению (заявке) у пользователя Ответ предоставлен Присваивается после ответа пользователем на запрос дополнительной информации Отклонен Присваивается, если обращение (заявка) не актуальна (по информации от пользователя), отсутствует техническая возможность решения обращения (заявки), предмет обращения не входит в компетенции технической поддержки, или существует влияние доработки на другие компоненты, что нарушает общий порядок работы Системы - Согласование Присваивается при необходимости согласования направления обращения (заявки) ответственным сотрудником Заказчика на 3-й уровень Анализ Присваивается при проведении анализа на предмет возможности внесения изменений, связанных с развитием/улучшением/оптимизацией Системы и выводом новой функциональности и оценке ресурсоемкости Тестирование Присваивается Исполнителем при завершении разработки и проведенном предварительном тестировании для последующего осуществления приемочного тестирования Специалистом 2-го уровня Релиз Присваивается ответственным сотрудником Заказчика при принятии решения о возможности вывода доработки в продуктивную среду Утверждение заказчиком Присваивается при согласовании группой профильных специалистов на 2-м уровне поддержки с пользователем технического задания для внесения изменений, связанных с развитием/улучшением/оптимизацией Системы и выводом новой функциональности Доработка Присваивается в случае несогласования Заказчиком работ, проведенных Исполнителем в рамках контрактных обязательств, по внесению изменений, связанных с развитием/улучшением/оптимизацией Системы и выводом новой функциональности в штатном режиме, и необходимости последующего направления Исполнителю для ее доработки Отложен Присваивается в случае невозможности выполнения запроса, изложенного в обращении (заявке), в связи с необходимостью запроса дополнительной информации у третьих сторон - Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 8) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 8) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 8) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 8) Категория обращения (заявки): инцидент Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 8) Приоритет Время, очередность решения обращения (заявки), ресурсы, привлекаемые для решения обращения (заявки), порядок/процедура действий при решении обращения (заявки) – поле СРО «Приоритет» (см. рисунок 8) Тип изменения Справочник, классифицирующий типовые запросы характерные для Системы – поле СРО «Предмет обращения» (см. рисунок 8) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 8) Текст запроса на оказание услуги по обновлению или удалению уязвимых компонентов (библиотек) ППО в соответствии с требованиями к обеспечению информационной безопасности Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 8) - На рисунке 8 приведена форма обращения (заявки) типа «Инцидент» в СРО. Рисунок 8 - Форма обращения (заявки) типа «Инцидент» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуги по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности, заполненную в свободной форме - Приложение 1 к Регламенту Матрица ответственных за взаимодействия в рамках выполнения работ по техническому сопровождению Системы Таблица 1 – Ответственные за взаимодействия в рамках выполнения работ по техническому сопровождению Системы со стороны Исполнителя ФИО Должность Адрес электронной почты Телефон — — — Общий контакт - Приложение 2 к Регламенту Приоритеты и регламентные сроки решения обращений (заявок) Приоритеты и регламентные сроки решения обращений (заявок) приведены в таблице 1. Таблица 1 – Приоритеты и регламентные сроки решения обращений (заявок) № п/п Приоритет Максимальное время реагирования Время решения (срок выполнения) Описание приоритета - По информационно-консультационной поддержке сотрудников Заказчика и пользователей Системы 1 – не более 1 часа не более 10 часов – - Термины и сокращения В настоящем регламенте используются следующие термины и сокращения на русском и английском языках: Термины/сокращения Полное наименование/описание БЗ (База знаний) База данных Системы регистрации обращений (заявок), созданная для сбора, хранения и поиска способов решения известных проблем в рамках Системы Жизненный цикл обращения (заявки) Совокупность статусов, по которым проходит обращение (заявка), и правила перехода обращения (заявки) из одного статуса в другой Заказчик ФГБУ «СИЦ Минтранса России» – Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» ЗНИ Запрос на изменение – тип заявки, предполагающий внесение изменений в прикладное программное обеспечение Системы ЗНО Запрос на обслуживание – тип заявки, предполагающий работы по предоставлению консультации, предоставление доступа к Системе или стандартизированные типовые изменения конфигураций Системы Инцидент Тип заявки, классифицируемый как нештатное событие в работе компонентов функциональных задач Системы, которое привело или может привести к нарушению или снижению качества функционирования Системы ИС Информационная система Исполнитель Организация, которая определяется по результатам конкурсных процедур Классификация Анализ и заполнение классификационных полей справочными значениями, определяющими последовательность действий и этапов жизненного цикла заявки, а также порядок рассмотрения заявок Консультация Разъяснения по алгоритму работы, требуемых настроек прикладного программного обеспечения и технологии обработки данных при работе с Системой, предоставление информации Маршрутизация Определение процесса движения обращения (заявки) в Системе управления заявками между уровнями технической поддержки и организационными структурами на уровнях поддержки путем назначения обращения (заявки) в соответствии с его классификацией и выставленным приоритетом - Обращение (заявка) Устное или письменное обращение пользователя АСУ ТК с вопросом, касающимся работоспособности АСУ ТК, по одному из определённых каналов связи: электронная почта, Система регистрации обращений (заявок) Пользователь Инициатор обращения (заявки) или пользователь Системы ППО Прикладное программное обеспечение Предмет обращения Справочник, классифицирующий типовые запросы в Системе регистрации обращений (заявок), характерные для Системы, выбранное значение определяет маршрутизацию обращения (заявки) (группу ответственных сотрудников) Приоритизация Значение, определяющее время, очередность решения обращений (заявок), ресурсы, привлекаемые для решения обращений (заявок), . Приоритет устанавливается в соответствии с масштабом выявленной проблемы, которая привела или может привести к нарушению или снижению качества функционирования Системы Релиз Выпуск версии прикладного программного обеспечения Системы, от разработки до тестирования и планового обновления Системы на продуктивной среде для установки изменений, связанных с развитием/улучшением/оптимизацией Системы Система, АСУ ТК, Информационно-аналитическая система регулирования на транспорте Информационно-аналитическая система, предназначенная для автоматизации и информационно-аналитического обеспечения процессов управления развитием транспортного комплекса Российской Федерации, обеспечения публичности деятельности органов государственного управления транспортным комплексом, а также обеспечения процессов оказания государственных услуг в электронном виде в сфере транспорта СМЭВ Система межведомственного электронного взаимодействия СПО Системное программное обеспечение СРО Система регистрации обращений (заявок) Статус обращения (заявки) Текущее состояние обращения (заявки) в жизненном цикле процесса оказания технической поддержки Системы СУБД Система управления базами данных - 3.4 Порядок регистрации и сопровождения Заявок Порядок регистрации и сопровождения обращений (заявок) в рамках оказываемых услуг по технической поддержке Системы зависит от типа обращения (заявки): 1. Услуга по решению инцидентов, связанных с работой ППО – тип обращения (заявки) «Инцидент». 2. Услуга по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности – тип обращения (заявки) «Инцидент». 3. Услуга информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы – тип обращения (заявки) «Запрос на обслуживание» (в том числе, консультационный запрос). 4. Услуга адаптационного, конфигурационного и коррекционного сопровождения Системы (в рамках действующих программных модулей и функциональностей) – тип обращения (заявки) «Запрос на изменение». В случае недоступности СРО взаимодействие и информирование Исполнителем о ходе оказания услуги по обращению (заявке), изменению статусов обращений (заявок) осуществляется по согласованию с Заказчиком в соответствии с матрицей взаимодействия, представленной в Приложении 1 к настоящему Регламенту. - 3.4.1 Инцидент На рисунке 2 представлена функциональная схема регистрации и сопровождения обращений (заявок) типа «Инцидент». Рисунок 2 - Функциональная схема регистрации и сопровождения обращений (заявок) типа «Инцидент» 3.4.2 Запрос на обслуживание На рисунке 3 представлена функциональная схема регистрации и сопровождения обращения (заявки) типа «ЗНО». Рисунок 3 - Функциональная схема регистрации и сопровождения обращения (заявки) типа «ЗНО» 3.4.3 Запрос на изменение На рисунке 4 представлена функциональная схема регистрации и сопровождения обращений (заявок) типа «ЗНИ». Рисунок 4 - Функциональная схема регистрации и сопровождения обращений (заявок) типа «ЗНИ» - 3.5 Порядок классификации и приоритизации обращений (заявок) Классификация является начальной стадией процесса оказания технической поддержки, необходимой для идентификации обращения (заявки) и определения соответствующих действий для его обработки. Для проведения первичной классификации необходимо получить от пользователя и зафиксировать в описании обращения (заявки) подробные сведения о сути запроса, в том числе, для Инцидентов зафиксировать сценарий воспроизведения обнаруженной ошибки. Для проведения вторичной классификации необходимо провести анализ и диагностику для определения корневой причины и затронутой Инцидентом функциональной области (инфраструктура, сеть, ППО). В процессе классификации осуществляется первичная диагностика и оценка проблемы, описанной пользователем Системы в обращении (заявке), в части функционирования и/или удобства использования Системы. Корректная классификация позволяет увеличить скорость обработки обращения (заявки) и решения описанной в обращении (заявке) проблемы при минимальном привлечении ресурсов, в частности, за счет использования известных решений для типовых обращений (заявок), которые должны описываться в БЗ СРО. Классификация позволяет произвести первоначальное назначение обращения (заявки) на ответственного сотрудника и выставить приоритет с учетом приоритизации. Приоритизация применяется для определения критичности описанной в обращении (заявке) проблемы для функционирования ППО Системы. Приоритет рассмотрения обращения (заявки) определяется в процессе ее классификации на основании ряда параметров, вводимых при заполнении обращения (заявки). Приоритизация используется для того, чтобы при одновременном наличии нескольких обращений (заявок) в первую очередь рассматривалась обращения (заявки) с наивысшим приоритетом и не позднее установленных для данного приоритета сроков - По решению инцидентов, связанных с работой ППО 1 Критический не более 30 минут не более 4 часов – полная недоступность ППО; – недоступность ключевых функций; – ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО; – невозможность информационного обмена с ППО для ИС более 4 часов 2 Высокий не более 1 часа не более 8 часов – ошибки/сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; – снижение быстродействия СПО (время отклика ППО на операции превышает 30 секунд); – невозможность управления правами и ролями пользователей 3 Средний не более 4 часов не более 24 часов – невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым недоступность функции формирования отчетов 4 Низкий не более 8 часов не более 40 часов – отклонение в работе ППО, не влияющее на корректную работу функций; – другие сбои и ошибки, затрагивающие основные функции ППО - По адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) 1 Критический не более 40 минут не более 8 часов – изменения необходимые при проведении аварийно-восстановительных работ для возобновления работоспособности Системы; – изменения, связанные с критичными ошибками, блокирующими возможность оказания государственных услуг и/или чтение и внесение данных в Систему 2 Высокий не более 1 часа не более 40 часов – изменения относящиеся к обеспечению работоспособности основной функциональности Системы, устраняют выявленные дефекты в работе Системы, оказывающие существенное влияние на процесс оказания государственных услуг и работу пользователей в Системе; – изменения, затрагивающие три и более подсистемы/модуля Системы для адаптации 3 Средний не более 4 часов не более 72 часов – изменения, связанные с развитием/улучшением/оптимизацией Системы и выводом новой функциональности в штатном режиме для одного-двух модулей/подсистем; – изменения, связанные с развитием интеграционных механизмов Системы, например, обновление существующих и/или реализация новых видов сведений СМЭВ, обновление существующих и/или реализация новых API, адаптация и/или изменение механизмов импорта и экспорта данных Системы и т.д. 4 Низкий не более 8 часов не более 160 часов – изменения, связанные с ошибками/ корректировкой/изменение в отображении информации в пользовательском графическом интерфейсе Системы (графика, текст, органы управления, элементы интерфейса) - По устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности 1 Критический не более 30 минут не более 24 часов – критические уязвимости, влияющие на возможную полную недоступность ППО, ключевых функций Системы, ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО без возможности восстановления работоспособности Системы; – Критический уровень CVSS > 8.0 2 Высокий не более 1 часа не более 84 часов – критические уязвимости, влияющие на ошибки и сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; – Высокий уровень CVSS 5.0 - 8.0 3 Средний не более 4 часов не более 120 часов – уязвимости, влияющие на невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым; – Средний уровень CVSS 2.0 - 4.9 4 Низкий не более 8 часов не более 160 часов – уязвимости, влияющие на отклонение в работе ППО, не влияющее на корректную работу функций; – другие сбои и ошибки, затрагивающие основные функции ППО; – Низкий уровень CVSS < 2.0 - Уровень технической поддержки Организационно-структурная часть технической поддержки, имеющая определённые организационно-нормативными документами зоны ответственности, обязанности, а также временные нормативы, в течение которых эти обязательства должны выполняться либо эскалироваться на следующий уровень технической поддержки Услуги Услуги по технической поддержке Информационно-аналитической системы регулирования на транспорте АСУ ТК ФИО Фамилия, имя, отчество Эскалация Процедура повышения внимания к обращению (заявке) путем повышения его приоритета и/или передачи на следующий уровень технической поддержки, а также привлечение ролей, которые могут принимать решения без передачи на следующий уровень технической поддержки API Англ. Application Programming Interface — программный интерфейс приложения, интерфейс прикладного программирования — описание способов (набор классов, процедур, функций, структур или констант), которыми одна компьютерная программа может взаимодействовать с другой программой - CVSS Англ. Common Vulnerability Scoring System - открытый стандарт, используемый для расчета количественных оценок уязвимости в безопасности компьютерной системы, обычно с целью понять приоритет ее исправления. В современном инструментарии информационной безопасности используется версия 3.0 и выше с дополнительными метриками к базовым оценкам ID Англ. Identifier – идентификатор, уникальный признак объекта, позволяющий отличать его от других объектов, то есть, идентифицировать SLA Англ. Service Level Agreement - утвержденные условия по обработке обращения (заявки) с установленными метриками времени, которые определяют пороговые значения для эскалации в зависимости от статуса обращения (заявки) (например, время реакции – время от регистрации до осуществления первичной обработки, время решения – время от регистрации обращения (заявки) до его решения и т.д.) SQL Англ. Structured Query Language — «язык структурированных запросов», — декларативный язык программирования, применяемый для создания, модификации и управления данными в реляционной базе данных, управляемой соответствующей СУБД - 1 Общие сведения 1.1 Полное наименование Услуг Оказание услуг по технической поддержке Модуля СЦ АСУ ТК в 2026 году. 1.2 Предмет Регламента оказания услуг Требования Технического задания - 2 Общие положения 2.1 Цель и задачи оказания услуг Целью технической поддержки Системы является обеспечение ее стабильного и безопасного функционирования и эксплуатации, предупреждение, выявление и устранение сбоев в работе Системы и минимизация их неблагоприятного влияния. Для достижения поставленной цели требуется решение следующих задач: 1. Обеспечение информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы. 2. Поддержание параметров функционирования ППО Системы, удовлетворяющих требованиям производственных процессов, включая их непрерывность. 3. Обеспечение бесперебойного функционирования ППО и своевременное устранение сбоев и аварийных ситуаций в Системе. 4. Своевременное устранение уязвимостей при выявлении таковых, в соответствии с требованиями к обеспечению информационной безопасности. 5. Адаптация, конфигурирование, коррекция программного обеспечения в соответствии с изменениями нормативно-правовой базы и запросами уполномоченных сотрудников органов государственной власти, включая выполнение процедур тестирования и участие в обновлениях ППО на стендах Заказчика. 6. Обеспечение сохранения работоспособности ППО в изменяемой среде эксплуатации. 7. Ведение документации по настоящему контракту и инициирование актуализации документации на Систему по результатам обработки запросов Заказчика и внесения соответствующих изменений в ППО - Изменение приоритета уже зарегистрированного обращения (заявки) используется в случае появления новых обстоятельств, которые ведут к изменению влияния и/или срочности существующего обращения (заявки). При регистрации обращения (заявки) необходимо провести его приоритизацию. В процессе управления обращениями (заявками) каждому обращению (заявке) присваивается приоритет, принимающий одно из значений: Низкий, Средний, Высокий или Критический. В соответствии с приоритетом определяется время, очередность устранения, , ресурсы, привлекаемые для работ по обращению (заявке), а также может определяться порядок/процедура действий при работе с обращением (заявкой). Заказчиком в зависимости от уровня сбоя в работе Системы обращению (заявке) присваивается приоритет с указанием максимального времени реакции и решения в соответствии с требованиями, указанными в Приложении 2 к настоящему Регламенту - 4 Формы обращений (заявок) на оказание услуг по технической поддержке Системы, заполняемые в СРО 4.1. Форма обращения (заявки) на оказание услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы При подаче обращения (заявки) типа «ЗНО» в СРО указывается (Таблица 5): Таблица 5 – Описание атрибутов формы обращения (заявки) на оказание услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 5) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 5) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 5) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 5) Категория обращения: информационно-консультационная поддержка Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 5) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 5) Текст запроса на оказание услуги по информационно-консультационной поддержке сотрудников Заказчика Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 5) - На рисунке 5 приведена форма обращения (заявки) типа «ЗНО» в СРО. Рисунок 5 - Форма обращения (заявки) типа «ЗНО» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы, заполненную в свободной форме. - Приложение Г Форма Отчета об оказанных услугах Отчет об оказанных услугах за этап «наименование этапа» в период с «__» _________ по «__» _________. № п/п Наименование услуги Общее количество Номер ОРС Краткое Описание Время реагирования по ТЗ Время реагирования фактическое Время решения по ТЗ Время решения фактическое Результат соблюдения времени реагирования Результат соблюдения времени решения Примечание 1 Услуги по информационно-консультационной поддержке работников Заказчика 2 546782 Консультация по работе Модуля СЦ 1 2 10 часов 11 часов Нет Нет 567123 Консультация по схеме БД 1 1 10 часов 1 час Да Да 2 … … Заказчик Подрядчик /Должность/ /Должность/ ____________________ /Ф.И.О/ ___________________ /Ф.И.О/ М.П. М.П. «_____»_______________________202_г. «_____»_______________________202_г - Приложение 1 к Отчету об оказанных услугах Журнал обращений (заявок) на оказание услуги по информационно-консультационной поддержке пользователей Системы (шаблон) Наименование Исполнителя в этапе «наименование этапа» в период с ________________ по _______________ оказал(о) Услугу по поддержке пользователей Системы в объеме, указанном в Таблице 1 Таблица 1 - Журнал обращений (заявок) пользователей Системы № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. ИТОГО зарегистрировано: Всего обращений (заявок): ________ ИТОГО решено: Всего обращений (заявок): ________ - Приложение 2 к Отчету об оказанных услугах Журнал обращений (заявок) по решению инцидентов, связанных с работой ППО (шаблон) Наименование Исполнителя в этапе «наименование этапа» в период с ________________ по _______________ оказал(о) Услугу по решению инцидентов в объеме, указанном в Таблице 1. Таблица 1 - Журнал по решению инцидентов № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. ИТОГО зарегистрировано: Всего инцидентов: ________ ИТОГО решено: Всего инцидентов: ________ - Приложение 3 к Отчету об оказанных услугах Журнал обращений (заявок) выполнения адаптационного, конфигурационного и коррекционного сопровождения Системы (шаблон) Журнал выполнения адаптации, конфигурации и коррекции Системы сформирован за этап «наименование этапа» в период с «__» _________ по «__» ____________ и представлен в таблице ниже (Таблица 1). Таблица 1 - Журнал выполнения адаптации, конфигурации и коррекции сопровождения Системы № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. Количество выполненных заявок за этап: ________ - Приложение 4 к Отчету об оказанных услугах Журнал обращений (заявок) по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности (шаблон) Журнал обращений (заявок) по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности сформирован за этап «наименование этапа» в период с «__» _________ по «__» ____________ и представлен в таблице ниже (Таблица 1). Таблица 1 - Журнал выполнения заявок по устранению уязвимостей в ППО № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. Количество выполненных заявок за этап: ________ - 4.2. Форма обращения (заявки) на оказание услуги по решению инцидентов, связанных с работой ППО При подаче обращения (заявки) типа «Инцидент» в СРО указывается (Таблица 6): Таблица 6 – Описание атрибутов формы обращения (заявки) на оказание услуги по решению инцидентов, связанных с работой ППО Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 6) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 6) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 6,) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 6) Категория обращения (заявки): инцидент Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 6) Приоритет изменения Время - одно из значений: Низкий, Средний, Высокий или Критический. Определяет, очередность решения обращения (заявки), ресурсы, привлекаемые для решения обращения (заявки), порядок/процедура действий при решении обращения (заявки) – поле СРО «Приоритет» (см. рисунок 6,) - Тип изменения Справочник, классифицирующий типовые запросы характерные для Системы – поле СРО «Предмет обращения» (см. рисунок 6) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 6) Полное описание инцидента, включая скриншоты и описание шагов, приведших к неисправности Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 6) Однократность/неоднократность Круг пользователей или компьютеров, затронутых данным инцидентом Действия, предпринятые для самостоятельного решения инцидента (при наличии) Версии используемого программного обеспечения на клиентской рабочей станции, где воспроизводится ошибка (операционная система, прикладное программное обеспечение) Дополнительная информация - На рисунке 6 приведена форма обращения (заявки) типа «Инцидент» в СРО. Рисунок 6 - Форма обращения (заявки) типа «Инцидент» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуги по решению инцидентов, связанных с работой ППО, заполненную в свободной форме - Приложение Д Форма Протокола проверки результатов организационно-штатных и подготовительных мероприятий (шаблон) Протокол проверки результатов организационно-штатных и подготовительных мероприятий Настоящий Протокол содержит результаты проверки организационно-штатных и подготовительных мероприятий, проведенных Исполнителем (Таблица Д.1). Таблица Д.1. Протокол проверки результатов № Мероприятия Подготовительного этапа Результат проверки 1. Определить и направить Заказчику документ «Ответственные за взаимодействия в рамках выполнения работ по техническому сопровождению Системы со стороны Исполнителя». Документ содержит контактную информацию (ФИО, должность, адрес электронной рабочей почты, номер телефона) не менее чем о 2 лицах, ответственных за оказание услуг со стороны Подрядчика Выполнено/Не выполнено 2. Обеспечить подключение специалистов Подрядчика к Системе Выполнено/Не выполнено 3. Обеспечить подключение специалистов Подрядчика к СРО Выполнено/Не выполнено Заказчик Подрядчик /Должность/ /Должность/ ____________________ /Ф.И.О/ ___________________ /Ф.И.О/ М.П. М.П. «_____»_______________________202_г. «_____»_______________________202_г

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

ОПРЕДЕЛЕНИЯ, ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ - Автоматизированная система (АС) Система, состоящая из комплекса средств автоматизации, реализующего информационную технологию выполнения установленных функций, и персонала, обеспечивающего его функционирование (ГОСТ Р 59853-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения») АРМ Автоматизированное рабочее место АСУ ТК, Система Информационно-аналитическая система регулирования на транспорте АТС Автоматическая телефонная станция БД База данных ГИС Государственная информационная система ГОСТ Государственный стандарт ГЦОД СИЦ Минтранса России, ГЦОД Головной центр обработки данных ФГБУ «СИЦ Минтранса России» Дашборд Интерактивная аналитическая панель, графический интерфейс. ЕИС Единая информационная система в сфере закупок ЕСИА Единая система идентификации и аутентификации Заказчик Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» КИИ Критическая информационная инфраструктура Кластер Кла?стер (англ. cluster) – объединение нескольких однородных элементов, которое может рассматриваться как самостоятельная единица, обладающая определёнными свойствами Компонент Часть АС, выделенная по определенному признаку или совокупности признаков и рассматриваемая как единое целое (ГОСТ Р 59853-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения») Контракт Контракт на выполнение работ по развитию и оказанию услуг по технической поддержке Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК в 2026 году, заключаемый по результатам проведения конкурентной процедуры закупки в соответствии с требованиями Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» - - Значение характеристики не может изменяться участником закупки

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

ФГБУ «СИЦ Минтранса России» Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации», Заказчик Федеральный закон № 44-ФЗ Федеральный закон от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» ФЗ Функциональная задача ФЗ «Реестр объектов» Функциональная задача «Формирование и ведение единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации» ФСБ России Федеральная служба безопасности Российской Федерации ФСТЭК России Федеральная служба по техническому и экспортному контролю ЧС Чрезвычайная ситуация ЭВМ Электронно-вычислительная машина API От англ. Application Programming Interface – интерфейс прикладного программирования – совокупность инструментов и функций в виде интерфейса для взаимодействия с программой CSS От англ. Cascading Style Sheets — каскадные таблицы стилей FPS От англ. frame per second - количество кадров в секунду HTML От англ. HyperText Markup Language - стандартный язык разметки документов, создающий основу и структуру всех веб-страниц JSON От англ. JavaScript Object Notation – текстовый формат обмена данными, основанный на JavaScript WebAssembly (Wasm) Открытый стандарт, представляющий собой низкоуровневый бинарный формат инструкций, который позволяет выполнять код, написанный на языках C++, Rust или Go, в браузерах с производительностью, близкой к нативной

1. ОБЩИЕ СВЕДЕНИЯ - 1.1. Наименование Системы Полное наименование системы: Информационно-аналитическая система регулирования на транспорте. Условное обозначение системы: АСУ ТК. Полное наименование модуля: Модуль сбора, ведения и анализа информации о нештатных ситуациях на транспорте. Условное обозначение модуля: Модуль СЦ. Модуль СЦ создан в рамках контракта от 05.08.2024 № ОК/24_04 на выполнение работ по развитию АСУ ТК в части создания модуля «Сбора, ведения и анализа информации о нештатных ситуациях на транспорте». Развитие Модуля СЦ осуществлено в рамках контракта от 19.05.2025 № ОК/25_09 на выполнение работ по развитию Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК - - Значение характеристики не может изменяться участником закупки

1.2. Шифр темы или номер контракта Присваивается Заказчиком по результатам организации закупочных процедур. 1.2.1. Предмет контракта Выполнение работ по развитию Модуля СЦ. Код по ОКПД2: 62.01.11.000 – услуги по проектированию и разработке информационных технологий для прикладных задач и тестированию программного обеспечения. Оказание услуг по технической поддержке Модуля СЦ. Код по ОКПД2: 62.02.30.000 – услуги по технической поддержке информационных технологий. Выполнение работ по развитию Модуля СЦ предусмотрено с учетом ключевых результатов (ОКР) Ведомственной программы цифровой трансформации Минтранса России на 2026-2028 (далее - ВПЦТ Минтранса России) в составе мероприятия № 103.002 «АСУ ТК» ИТ расхода 103.26.000005 «Развитие Информационно-аналитической системы регулирования на транспорте (АСУ ТК)»: · «Обеспечено информационное взаимодействие с Минобороны о происшествиях на транспортных объектах»; · «Обеспечена автоматизация формирования отчетов о нештатных ситуациях на транспорте, в том числе по данным внешних систем». Выполнение работ по технической поддержке АСУ ТК предусмотрено ВПЦТ Минтранса России в составе мероприятия № 103.002 «АСУ ТК» ИТ расхода 103.26.000021 «Эксплуатация Информационно-аналитической системы регулирования на транспорте (АСУ ТК)»

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

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

1.5. Основания для выполнения работ Работы осуществляются на основании следующих документов: – постановление Правительства Российской Федерации от 30.12.2003 № 794 «О единой государственной системе предупреждения и ликвидации чрезвычайных ситуаций»; – постановление Правительства Российской Федерации от 08.11.2013 № 1007 «О силах и средствах единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций»; – распоряжение Правительства Российской Федерации от 27.11.2021 № 3363-р «О Транспортной стратегии Российской Федерации до 2030 года с прогнозом на период до 2035 года»; – Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 26.08.2025 №ЕФ-3; – Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 27.11.2025 №ЕФ-23;

– приказ Минкомсвязи России от 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 «Национальный стандарт Российской Федерации. Интеллектуальная собственность. Патентные исследования. Содержание и порядок проведения»;

– Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 19.02.2026 №ЕФ-1; – План мероприятий по профилактике случаев непроизводственного травматизма граждан на железнодорожном транспорте, являющийся приложением к постановлению коллегии Министерства транспорта Российской Федерации от 11.03.2026 № 2

1.6. Перечень документов, требования которых должны быть учтены при выполнении работ – Федеральный закон Российской Федерации от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации»; – Федеральный закон Российской Федерации от 27.07.2006 № 152-ФЗ «О персональных данных»; – Федеральный закон Российской Федерации от 06.04.2011 № 63-ФЗ «Об электронной подписи»; – Федеральный закон Российской Федерации от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации»; – Указ Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации»; – Указ Президента Российской Федерации от 01.05.2022 № 250 «О дополнительных мерах по обеспечению информационной безопасности Российской Федерации»; – Указ Президента Российской Федерации от 31.03.2010 № 403 «О создании комплексной системы обеспечения безопасности населения на транспорте»; – постановление Правительства Российской Федерации от 30.07.2004 № 395 «Об утверждении Положения о Министерстве транспорта Российской Федерации»; – постановление Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации»; – постановление Правительства Российской Федерации от 16.11.2015 № 1236 «Об установлении запрета на допуск программного обеспечения, происходящего из иностранных государств, для целей осуществления закупок для обеспечения государственных и муниципальных нужд»; – постановление Правительства Российской Федерации от 23.12.2024 № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц»;

– ГОСТ Р 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.7. Сроки начала и окончания работ Начало работ: с даты заключения Контракта. Окончание работ: не позднее 15.12.2026. Работы выполняются в соответствии с этапами. Сроки выполнения этапов работ по развитию и технической поддержке Модуля СЦ определяются Календарным планом. Календарный план, приведен в разделе 5 настоящего ТЗ

– постановление Правительства Российской Федерации от 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 Федерального закона «Об электронной подписи»;

– постановление Правительства Российской Федерации от 08.06.2011 № 451 «Об инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг и исполнения государственных и муниципальных функций в электронной форме»; – постановление Правительства Российской Федерации от 30.01.2013 № 62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин»; – приказ ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации»; – приказ ФСТЭК России от 11.04.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений»; – приказ ФСБ России от 18.03.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений, с использованием шифровальных (криптографических) средств»; – приказ ФСБ России от 10.07.2014 № 378 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных с использованием средств криптографической защиты информации, необходимых для выполнения установленных Правительством Российской Федерации требований к защите персональных данных»;

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

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

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

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

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

2.1. Назначение АСУ ТК АСУ ТК предназначена для автоматизации и информационно-аналитического обеспечения процессов управления развитием транспортного комплекса Российской Федерации, обеспечения публичности деятельности органов государственного управления транспортным комплексом. Основными целями АСУ ТК являются: – повышение эффективности процессов управления функционированием и развитием транспортного комплекса на основе создания единой информационной среды и комплекса информационно-аналитических услуг на уровне органов государственного управления ТК; – повышение уровня безопасности ТК на базе получения полной, достоверной и оперативной информации о происходящих изменениях, своевременного выявления негативных тенденций и для принятия соответствующих мер по их устранению и ликвидации последствий

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

3. ХАРАКТЕРИСТИКА ОБЪЕКТА АВТОМАТИЗАЦИИ - 3.3. Состав используемого ПО Модуля СЦ Программная архитектура Модуля СЦ разработана как трехуровневая клиент-серверная архитектура. Архитектура включает в себя следующие уровни: • уровень представления – презентационный уровень, обеспечивающий взаимодействие с пользователя с клиентскими приложениями с использованием веб-браузера («тонкий» клиент); • уровень приложений – реализован в виде сервисов, обеспечивает обработку запросов, поступающих от клиентских приложений, формирование ответов на запрос в доступном пользователю виде (формирование пользовательских интерфейсов); • уровень хранения данных – реализуется как сервер БД и обеспечивает хранение и целостность хранимых данных, создание резервных копий, ведение журнала транзакций, восстановление данных после сбоев. Программная архитектура Модуля СЦ включает в себя сервисы и интерфейсы, указанные в Таблице 3. Таблица 3. Программная архитектура Модуля СЦ Программный сервис/интерфейс Технологии реализации Уровень представления Интерфейс пользователя и администратора (front-end) Javascript Уровень приложений Сервис (GateWay) Kotlin Сервис геокодирования (geocoding-service) Kotlin Сервис уведомлений (notifiсation-service) Kotlin Сервис работы с файлами (file-service) Kotlin Сервис отчетности (report-service) Kotlin Сервис управления событиями (event-service) Kotlin Сервис информирования через мессенджер (messenger-notifier) Python Сервис внешних интеграций (integration-service) Сбор информации из внешних систем и сервисов Брокер сообщений Kafka Уровень хранения данных Файловое хранилище MinIO S3 СУБД Postgres Pro Enterprise - - Значение характеристики не может изменяться участником закупки

3.4. Информационное взаимодействие программных сервисов и интерфейсов Модуля СЦ Объект автоматизации функционирует в распределенной информационной среде. Обмен данными осуществляется по защищенным каналам связи (в том числе ведомственным сетям передачи данных). Источники информации включают: · внешние автоматизированные системы (органов государственной власти); · внутренние базы данных (реестры объектов транспортной инфраструктуры, паспорта регионов и пр.); · оперативная информация от персонала, поступающая через автоматизированные рабочие места (АРМ) и мобильные устройства. 3.4.1. Взаимодействие Модуля СЦ со смежными подсистемами АСУ ТК Модуль СЦ входит в состав АСУ ТК и взаимодействует со следующими ее функциональными задачами и подсистемами: · Функциональной задачей «Формирование и ведение единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации» (ФЗ «Реестр объектов»); · Геоинформационной подсистемой АСУ ТК (П-ГИС); · Подсистемой ведения нормативно-справочной информации и метаданных (П-НСИ); · Подсистемой сбора данных и централизованное хранилище данных (П-СД); · Подсистемой информационного взаимодействия (П-ИВ). 3.4.2. Взаимодействие с внешними информационными системами Список внешних информационных систем, с которыми осуществляется взаимодействие Модуля СЦ: · ЕСИА; · мессенджер; · Яндекс Геокодер; · Информационная система «Централизованная система сбора информации систем-112»; · ПВК «Поиск-Море», АИС РПТ; · облачная АТС

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

3.1. Описание объекта автоматизации АСУ ТК Объектом автоматизации являются процессы основной и обеспечивающей деятельности, направленные на управление транспортным комплексом, в том числе, процессы информационного взаимодействия с другими организациями и субъектами транспортного комплекса. АСУ ТК относится к государственным информационным системам, а также к информационным системам персональных данных и значимым объектам критической информационной инфраструктуры Российской Федерации. АСУ ТК соответствует требованиям, предъявляемым к: – ГИС второго класса защищенности в соответствии с приказом ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах»; – ИС персональных данных при обеспечении третьего уровня защищенности персональных данных в соответствии с требованиями постановления Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»; – значимым объектам КИИ Российской Федерации второй категории значимости с постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении Правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений». Модуль СЦ является подсистемой АСУ ТК. Перечень платформенных решений и функциональных задач АСУ ТК представлен в Таблице 1

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

8 Подсистема проектного архива АСУ ТК Подсистема проектного архива АСУ ТК предназначена для автоматизации деловых процессов должностных лиц Министерства транспорта Российской Федерации, подведомственных агентств и службы, в том числе, и процессов информационного взаимодействия внутреннего и внешнего характера 9 ФЗ «Реестр объектов» Функциональная задача предназначена для формирования и ведения единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации 10 ФЗ «СТП» Функциональная задача предназначена для организации информационно-аналитической поддержки процессов территориального планирования Российской Федерации в области федерального транспорта 11 ФЗ «МРТБ ПП» Функциональная задача предназначена для формирования и ведения межрегионального транспортного баланса пассажирских перевозок в дальнем (межрегиональном) сообщении 12 ФЗ «МДД» Функциональная задача предназначена для осуществления мониторинга дорожного движения 13 ФЗ «ТПР» Функциональная задача предназначена для формирования и ведения транспортного паспорта региона 14 ФЗ «Данные по грузообороту» Функциональная задача предназначена для обеспечения подсистем и пользователей АСУ ТК данными по грузообороту между Российской Федерацией и зарубежными странами 15 ФЗ «МЖТ» Функциональная задача предназначена для осуществления мониторинга железнодорожного транспорта 16 ФЗ «МГМП» Функциональная задача предназначена для осуществления мониторинга грузопотоков в морских портах с целью формирования единой цифровой среды мониторинга и планирования перевозок в/из портов Дальнего Востока

17 Модуль ГЭТ Модуль предназначен для получения, хранения данных инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по отдельно взятому предприятию-перевозчику. Формирования отчетов об инвентаризации с детальными данными по каждому разделу инвентаризации с маршрутизацией в муниципалитет / регион / Минтранс. Содержит агрегированные данные инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по всем перевозчикам, относящихся к данному муниципалитету. Формирует сводный отчет по муниципалитету по каждому разделу инвентаризации с маршрутизацией в регион / Минтранс. Формирует агрегированные данные инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по всем перевозчикам, относящиеся к данному региону и по всем муниципалитетам, относящимся к данному региону. Аналитические и статистические данные о состоянии ГЭТ региона. Содержит данные о видах транспорта, цифровых транспортных сервисах и платежных инструментах Региона. Формирует сводный отчет по каждому разделу инвентаризации с маршрутизацией в Минтранс. Формирует агрегированную статистику и аналитику по всем регионам страны в разрезе транспортных средств, маршрутов, пассажиропотоков, инфраструктуры ГЭТ. Данные о рейтинге регионов и перевозчиков на основании выбранных параметров, документооборот с участниками Системы: получение подписанных печатных форм, их утверждение, возврат на доработку. 18 Модуль iМинтранс Модуль создан для отчета по ключевым показателям транспортного комплекса России (Отраслевые и статистические показатели, исполнение бюджета, исполнение поручений, аналитика СМИ, происшествия по видам транспорта). 19 Модуль СЦ Модуль СЦ предназначен для оперативного мониторинга нештатных ситуаций транспортной отрасли, оповещения заинтересованных лиц и структур и предоставления данных о нештатных ситуациях

АСУ ТК осуществляет идентификацию и авторизацию посредством Единой системы идентификации и аутентификации (ЕСИА). Информационный обмен с внешними информационными системами осуществляется посредством СМЭВ 3 и СМЭВ 4. АСУ ТК развернута на вычислительных мощностях ГЦОД СИЦ Минтранса России

3.2. Описание и текущее состояние объекта автоматизации Модуля СЦ Объектом автоматизации является процесс организации мониторинга информации о НС и ЧС на транспорте. Предметом деятельности Учреждения являются следующие функции: – информационное обеспечение в области транспортной безопасности, защиты населения и территорий от чрезвычайных ситуаций природного и техногенного характера в транспортном комплексе; – подготовка справочных материалов при угрозе возникновения и возникновении чрезвычайных ситуаций и иных происшествий в транспортном комплексе; – взаимодействие и обмен оперативной информацией с органами управления Единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций; – организация оперативного мониторинга обстановки на объектах транспорта при угрозе и возникновении чрезвычайных ситуаций и иных происшествий. Перечень компонентов Модуля СЦ и выполняемые ими функции представлены в Таблице 2

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

3 Информирование – ведение справочника способов оповещения (веб-интерфейс, мессенджер); – формирование сценария выполнения оповещения (настройка условий, способа, параметров оповещения); – выполнение оповещений пользователей 4 Отчетность – формирование отчета и справки о событиях; – фильтрация событий для выгрузки в справку о событиях или в отчет о событиях 5 Администрирование – ведение ролей пользователей; – ведение учетных данных пользователей; – ведение справочника организаций; – ведение справочника групп системы мгновенного обмена сообщениями; – выполнение исходящего звонка на контактный телефонный номер организации; – формирование матрицы эскалации событий Архитектура Модуля СЦ представлена на рисунке 1. Рисунок 1. Архитектура Модуля СЦ

4. ТРЕБОВАНИЯ К МОДУЛЮ СЦ - 4.4.7.1. Требования к инструментам разработки и процессу контроля версий программного обеспечения 4.4.7.1.1. Система контроля версий Для управления исходным кодом должна использоваться система контроля версий кода, развернутая в инфраструктуре Заказчика. 4.4.7.1.2. Правила именования веток Имя ветки должно соответствовать следующему формату: / / Категории веток: ? feature/ — разработка новой функциональности, а также рефакторинг или удаление существующей; ? fix/ — исправление ошибок; ? hotfix/ — срочные исправления, применяемые в обход стандартного процесса разработки; ? test/ — для проведения экспериментов, не влияющих на основную разработку. Идентификатор задачи: после категории указывается ссылка на задачу (issue) в системе контроля версий кода. Описание: добавляется краткое описание решаемой задачи в формате kebab-case (слова разделяются дефисами, например, add-user-auth). Примеры именования веток: ? feature/#123/add-payment-integration; ? fix/#45/correct-calculation-logic; ? hotfix/#67/urgent-database-connection-patch. 4.4.7.1.3. Правила именования коммитов Сообщение коммита должно соответствовать соглашению Conventional Commits и состоять из категории и описания: : ? fix — исправление ошибки. Примеры сообщений коммитов: ? feat: добавление формы регистрации пользователя; ? fix: исправление ошибки валидации email-адреса; ? refactor: оптимизация алгоритма сортировки данных; ? chore: обновление версий в файле dependencies. 4.4.7.1.4. Модель ветвления В процессе разработки используются следующие основные ветви: ? main / master — стабильная ветка, содержит только код, прошедший полное тестирование и развернутый в продуктивных контурах; ? dev — ветка для интеграции завершенных задач, предназначенная для сборки и тестирования в тестовых средах. Попадание кода в main осуществляется только через Merge Request (MR) из dev - - Значение характеристики не может изменяться участником закупки

4.4.7.1.5. Требования к используемым зависимостям (библиотекам) Все внешние зависимости проекта должны быть зафиксированы с указанием точных версий. Для контроля версий зависимостей в репозиторий обязательно должны быть включены следующие файлы: · Для JavaScript: package-lock.json или yarn.lock; · Для Python: requirements.txt (с зафиксированными версиями) или Pipfile.lock; · Для Go: go.mod и go.sum; Загрузка всех зависимостей должна производиться исключительно через внутренний прокси-репозиторий Заказчика, настроенный в соответствующем системе менеджере пакетов. Запрещается: · Использование плавающих версий (например, ^1.2.3, ~4.5.0, latest); · Использование библиотек, содержащих критические уязвимости, в том числе зарегистрированные в реестре CVE (Common Vulnerabilities and Exposures). 4.4.7.1.6. Требования к процессу непрерывной интеграции (CI) Сборка программного обеспечения, включая этапы компиляции, тестирования и анализа кода, должна выполняться исключительно в инфраструктуре непрерывной интеграции Заказчика. 4.4.7.1.7. Требования к хранению артефактов сборки Все артефакты сборки (результирующие пакеты, Docker-образы и т.д.) подлежат обязательному хранению в предназначенной для этого инфраструктуре Заказчика (артефакторий). Запрещается размещение финальных артефактов сборки на сторонних ресурсах

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

Подрядчик должен обеспечить реализацию и проведение внутренних проверок мер по разработке безопасного ПО, приведенных в Руководстве. Подрядчик должен провести анализ угроз безопасности информации программного обеспечения в соответствии с ГОСТ 58412-2019 «Защита информации. Разработка безопасного программного обеспечения. Угрозы безопасности информации при разработке программного обеспечения». Подрядчик должен провести испытания по выявлению уязвимостей в программном обеспечении Системы: · проведение статического анализа исходного кода программы; · проведение динамического анализа исходного кода программы; · проведение композитного анализа исходного кода и образов программы; · проведение фаззинг-тестирования программы, направленного на выявление в ней уязвимостей. Испытания по выявлению уязвимостей в программном обеспечении Системы должны быть проведены в рамках: · предварительных испытаний; · опытной эксплуатации; · приемочных испытаний

4.5.11. Требования к показателям назначения 4.5.11.1. Требования к показателям назначения мероприятий по развитию Модуля СЦ В рамках выполнения работ по развитию Модуля СЦ, предусмотренных ТЗ, показатель назначения «Количество пользователей» должен соответствовать значениям, приведенным в данном разделе. Пояснения по показателям, связанным с количеством пользователей, приведены в Таблице 8. Таблица 8. Определения показателей, связанных с количеством пользователей в Модуле СЦ № Показатель Определение Расчетное количество пользователей Количество пользователей, работу которых должен обеспечить Модуль СЦ к моменту сдачи работ по Контракту с учетом достижения всех показателей назначения Расчетное количество одновременно работающих пользователей Количество одновременно работающих пользователей, работу которых должен обеспечивать Модуль СЦ к моменту сдачи работ по Контракту с учетом достижения всех показателей назначения Значения показателей количества пользователей, достижение которых необходимо обеспечить, представлено в Таблице 9

Таблица 9. Значения показателей количества пользователей № Показатель Значение 1. Расчетное количество пользователей 1 000 2. Расчетное среднее количество одновременно работающих пользователей 200 Развитие Модуля СЦ должно быть направлено на достижение следующего эффекта (показателя), подставленного в мероприятии 103.002 «Информационно-аналитическая система регулирования на транспорте (АСУ ТК)» ВПЦТ Минтранса России: Выполнение работ по развитию Модуля СЦ предусмотрено мероприятием по развитию АСУ ТК, приведенном в ВПЦТ Минтранса России на 2026-2028 гг: № 103.002 «АСУ ТК» в составе ИТ расхода 103.26.000005 «Развитие предусматривает реализацию ОКР и эффектов, приведенных в Таблице 10. Таблица 10. ОКР и эффекты, приведенные в ВПЦТ Минтранса России на 2026 г. № ОКР Дата ОКР Эффекты 1 Обеспечено информационное взаимодействие с Минобороны России о происшествиях на транспортных объектах 25.12.2026 Сокращено время сбора и передачи сведений для Минобороны России о ЧС и НС на транспорте с 120 до 10 минут 2 Обеспечена автоматизация формирования отчетов о нештатных ситуациях на транспорте, в том числе по данным внешних систем 25.12.2026 Сокращено время на подготовку отчетов о нештатных ситуациях на транспорте с 20 до 5 минут Реализация остальных ОКР не является предметом данного ТЗ и проводится в рамках отдельного технического задания.

4.5.11.2. Требования к показателям назначения мероприятий по эксплуатации Модуля СЦ. Работы по эксплуатации Модуля СЦ не должны обеспечивать режимы функционирования Модуля СЦ, приведенные в разделе 4.5.2 данного ТЗ

4.1. Требования к структуре Модуля СЦ В процессе работ по развитию Системы должны сохраниться основные требования к построению архитектуры Системы в соответствии с принципами трехуровневой архитектуры: 1. уровень хранения данных или уровень базы данных (сервер СУБД); 2. уровень сервера приложений (сервер аналитической обработки); 3. презентационный уровень, обеспечивающий взаимодействие с клиентскими приложениями. В состав Системы должны входить следующие основные компоненты: 4. сервер баз данных; 5. сервер приложений; 6. веб-сервер. Сервер баз данных должен обеспечивать хранение и целостность хранимых данных, создание резервных копий, ведение журнала транзакций, восстановление данных после сбоев. Сервер приложений должен обеспечивать обработку запросов, поступающих от клиентских приложений (через веб-сервер), формирование ответов на запрос в доступном пользователю виде (формирование пользовательских интерфейсов). Веб-сервер должен обеспечивать взаимодействие с оператором и внешними системами по HTTP / HTTPS протоколу в режиме «запрос-ответ» (получения запросов от пользователя и передачи ответа в виде соответствующей информации, обработанной серверами приложений). Взаимодействие Системы с пользователем должно отвечать требованиям модели «тонкого клиента» (т.е. представлять на стороне клиента (пользователя) лишь графический пользовательский интерфейс). Все составляющие Системы должны использовать единую методологию и отвечать единым принципам взаимодействия, надежности и управления. Перечень компонентов Модуля СЦ представлен в Таблице 4. Таблица 4. Перечень компонентов Модуля СЦ, в отношении которых выполняются работы по развитию № п.п. Наименование компонента Модуля СЦ Раздел ТЗ 1 Компонент регистрации событий 4.2.1. 2 Компонент отчетности 4.2.2 3 Компонент визуализации 4.2.3 4 «Интерактивная карта» (компонент создается) 4.2.4 5 Компонент администрирования 4.2.5

4.2. Требования к дорабатываемым функциям модуля СЦ 4.2.1. Развитие компонента регистрации событий (1 очередь) Должны быть выполнены следующие доработки: – обеспечение логирования действий пользователя, связанных с карточкой события; – доработка объектной модели в части создания новых типов сущностей (карточек) с учетом реализуемых интеграций с информационными ресурсами (силы и средства предупреждения и ликвидации ЧС и нештатных ситуаций на транспорте, ТС, ограничения воздушного пространства, неблагоприятные и опасные природные явления); – реализация механизма установления связи между сущностями в Модуле СЦ автоматизированным и ручным способами (события, природные явления, силы и средства предупреждения и ликвидации ЧС и нештатных ситуаций на транспорте, ограничения воздушного пространства, ОТИ, ТС и др.); – отображение в карточке установленных связей между сущностями.

4.2.2. Развитие компонента отчетности (3 очередь) Должна быть обеспечена автоматизация процессов формирования отчетов о ЧС и нештатных ситуациях на транспорте, в т.ч. на основе данных из внешних систем. Включает следующие доработки: – разработка шаблонов отчетов в различных форматах (табличный, текстовый); – реализация выбора фотоматериалов для включения в справку; – форматирование содержимого справок с учетом правил русского языка в отношении окончаний слов (в зависимости от падежа, склонения, числа и рода); – автоматизированное формирование выводов к содержимому справки на основе настраиваемых критериев; – создание интерфейса выбора параметров (фильтрации) для формирования отчетов: o состав полей для включения в отчёт; o настройка диапазонов значений характеристик и дат; o порядок отображения полей; o настройка заголовка. – реализация способа подготовки отчётов в асинхронном режиме (очереди); – реализация интерфейса компонента формирования отчетности для отображения очереди формирования отчетов и статусов их подготовки; – экспорт отчётов в форматы xlsx, csv и справок в форматы pdf, docx. Необходимо разработать не менее 10 шаблонов отчетов и/или справок. Перечень, структура и содержание шаблонов должны быть согласованы с Заказчиком на этапе технического проектирования.

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

– отображение на карте связанных сущностей и ОТИ; – реализация функции выбора темного и светлого стилей отображения элементов интерфейса, карточек сущностей, картографической основы и объектов, отображаемых на карте; – реализация механизма для выбора картографической основы в одном из распространенных форматов WMTS, TMS, MVT и др. Должна быть предусмотрена возможность настройки перечня картографических основ и параметров доступа к ним; – настройка базового набора дашбордов, содержащих преднастроенные виджеты о количестве событий в разрезе видов транспорта с возможностью перехода к исходным данным (карточкам событий, ОТИ и т.д.), с фильтрацией по параметрам. Параметры фильтрации должны быть определены на этапе технического проектирования. Должно быть обеспечено автоматическое и принудительное обновление данных, отображаемых на дашбордах

Таблица 6. Категории обращений и заявок Категория Примеры Запрос на обслуживание Подготовка SQL запроса к СУБД для решения прикладной задачи и д.р. – запрос на любое действие, не являющееся запросом информации и несовершенный на основе происшествия, прямо или косвенно влияющего на работу Модуля СЦ Консультация «Где взять / куда обратиться...?», «Как сделать / выполнить…», «Как это работает…?» - запрос, имеющий своей целью получение информационной поддержки Инцидент Разбор ошибок/сбоев и подготовка материалов (корректировочных релизов, инструкций) для Заказчика для устранения ошибок/сбоев, которые приводят к частичному и полному нарушению работоспособности всех или отдельных функций ППО. Подготовка изменения и материалов, необходимых для проведения аварийно-восстановительных работ для возобновления работоспособности Модуля СЦ ЗНИ Подготовка изменений, связанных с изменением, улучшением/оптимизацией Модуля СЦ и выводом новой модифицированной функциональности в штатном режиме. Подготовка изменений, связанных с модификацией существующих и/или реализация новых интеграционных механизмов для получения/обработки данных внешних систем. Подготовка изменений графического интерфейса по требованиям Заказчика. Перечень статусов обращений (заявок) приведен в пункте 3.3. Регламента оказания Услуг. Назначение обращению (заявке) статуса «Закрыто» осуществляется Заказчиком только после получения от инициатора обращения (заявки) подтверждения о его исполнении или нахождения обращения (заявки) в статусе «Выполнено» и отсутствия повторных вопросов/запросов по данному обращению (заявки) в течение 5 рабочих дней. Категории и статусы обращений (заявок) могут быть скорректированы в процессе оказания услуг исключительно по согласованию с Заказчиком

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

4.2.4. Создание компонента «Интерактивная карта» (2 очередь) В составе создаваемого компонента должны отображаться данные, доступные в компоненте визуализации. Требования к интерфейсу интерактивной карты: – интерактивная карта должна быть представлена в виде объемной карты с учетом макетов, представленных в Приложении А к ТЗ; – интерфейс должен корректно отображаться на экранах мониторов (разрешение Full HD 1920?1080), телевизоров (разрешение 4К 3840?2160), жидкокристаллических панелей для видеостены, используемой Заказчиком, с параметрами каждой панели: диагональ 55 дюймов, разрешение 1920x1080; – интерфейс должен корректно отображаться на планшетных устройствах с диагональю экрана 10-12 дюймов, конкретные требования должны быть уточнены на этапе технического проектирования; – должна быть обеспечена кластеризация и генерализация отображения объектов на карте при изменении масштаба; – должно быть обеспечено отображение основных характеристик объектов при выборе их на карте; – должно быть обеспечено управление отображением слоев на карте; – должна быть обеспечена настройка цветовой индикации отображаемых объектов транспортной инфраструктуры; – должно быть обеспечено отображение легенды карты, содержащей отображаемые объекты на карте; – должна быть обеспечена возможность одновременного отображения не менее 5 000 ОТИ и ТС на карте.

На интерактивной карте должны быть отображены подвижные объекты совместно с объектами транспортной инфраструктуры (ОТИ), включая следующие возможности: § отображение местоположения транспортных средств (воздушный, водный и автомобильный транспорт) на карте в режиме реального времени (с заданным периодом обновления данных); § отображение маршрутов движения всех ТС за выбранный период времени, в том числе с использованием эффектов анимации; § отображение маршрутов движения ТС, связанных с карточкой события: ТС, являющихся участниками события, и ТС, находящиеся в заданном радиусе от события; § управление отображением сущностей и ОТИ на карте, включая настройку состава отображаемых объектов, поиск, фильтрацию, с использованием соответствующей панели управления и наглядным представлением результатов; § автоматическое изменение вида отображения объектов (цветовая индикация) по заданным условиям (например, при достижении критических значений параметров, характеризующих функционирование объекта); Должна обеспечиваться производительность обновления изображения на экране в 30 кадров в секунду на тестовой конфигурации пользовательского устройства (модель Бештау AIO2402/B560, входящая в Реестр российской промышленной продукции под номером 10394100 или аналог) при одновременном отображении не менее 5 000 объектов и 200 уникальных моделей объектов. Макеты интерфейсов Модуля СЦ должны быть предварительно согласованы с Заказчиком и разработаны с учетом требований ГОСТ Р ИСО 9241-161-2016 «Элементы графического пользовательского интерфейса»

4.2.6. Взаимосвязи с внешними автоматизированными системами (1 очередь) Способы взаимодействия с внешними информационными системами должны быть определены на этапе технического проектирования. Должны быть выполнены следующие доработки: – интеграции с информационными ресурсами в целях получения данных о движении подвижных ТС (воздушные суда, суда водного транспорта); – интеграция с информационным ресурсом в целях получения данных о событиях на железнодорожном транспорте. Реализация интеграций должна включать проектирование и реализацию интеграционных механизмов обмена данными с учетом доступных вариантов реализации, обеспечение защищенных способов взаимодействия, настройку отображения отдельных данных на карте (настройка слоев). Взаимодействия, имеющие каналы связи, выходящие за пределы контролируемой зоны взаимодействующих систем, считаются защищенными, если для их защиты используются программные и/или программно-аппаратные шифровальные (криптографические) средства, сертифицированные ФСБ России (далее – СКЗИ). Выбор СКЗИ, схемы подключения и требуемого класса криптостойкости должен производиться в соответствии с Техническими условиями на подключение к информационным ресурсам ФГБУ «СИЦ Минтранса России» и инструкциями по подключению пользователей к ресурсам инфраструктуры Головного центра обработки данных, утвержденных приказом директора ФБГУ «СИЦ Минтранса России» от 24.05.2024 № 21-ОД

4.3. Требования к оказанию услуг по технической поддержке Модуля СЦ 4.3.1. Общие требования к оказанию Услуг Техническая поддержка Модуля СЦ должна осуществляться с учетом требований постановления Правительства Российской Федерации от 06.07.2015 N 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации». Подрядчик обязан выполнять требования законодательства в сфере защиты информации, требования по защите информации, информационной безопасности, указанные в локальных нормативных актах ФГБУ «СИЦ Минтранса России», регламентирующих условия информационного взаимодействия, защиты информации и подключения к информационным ресурсам ФГБУ «СИЦ Минтранса России», участвующих в информационном взаимодействии в рамках оказания услуг по технической поддержке АСУ ТК в 2026 году

4.3.1.1. Требования к составу и содержанию услуг третьего уровня технической поддержки Оказание услуг по технической поддержке Системы осуществляется в рамках этапов в соответствии с календарным планом. Подрядчик в течение 5 рабочих дней с даты заключения Контракта должен предоставить со своей стороны, а Заказчик со своей стороны Матрицу ответственных за взаимодействия в соответствии с Приложением 1 к Регламенту оказания услуг по третьему уровню технической поддержки Модуля СЦ (далее – Регламент, Приложение В). Подрядчик в течение 10 рабочих дней с даты заключения Контракта должен провести мероприятия по организации третьего уровня технической поддержки в соответствии с Регламентом. Услуги по третьему уровню технической поддержки Модуля СЦ должны включать: – организацию Подрядчиком третьего уровня технической поддержки; – информационно-консультационную поддержку работников Заказчика; – решение инцидентов, связанных с работой ППО; – адаптационное, конфигурационное и коррекционное сопровождение Модуля СЦ (в рамках действующих программных модулей и функциональности); – устранение уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности

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

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

4.3.6.2. Требования к услугам информационно-консультационной поддержки работников Заказчика и пользователей Модуля СЦ Услуги информационно-консультационной поддержки сотрудников Заказчика включают: – обработку обращений и заявок, поступивших от сотрудников Заказчика; – консультирование сотрудников Заказчика и пользователей Модуля СЦ; – актуализацию документации, и других материалов по работе с Модулем СЦ при необходимости. – консультирование и разработку рекомендаций по настройке Модуля СЦ (без изменения программного кода), включая изменение настроек функционирования; – консультации по вопросам использования, настройки и возможностям Модуля СЦ; – консультации по проведению превентивных мер для недопущения аварийных ситуаций в Модуле СЦ; – консультации по предварительной диагностике и локализации возникшей неисправности Модуля СЦ; – консультации по вопросам обеспечения информационной безопасности Модуля СЦ и настройки функций, обеспечивающих корректную работу программного обеспечения для совершения юридически значимых действий в Модуле СЦ; – другие вопросы, связанные с работой Модуля СЦ. 4.3.6.2.1. Требования к порядку оказания услуг информационно-консультационной поддержки работников Заказчика и пользователей Модуля СЦ Подрядчик выполняет консультирование сотрудников Заказчика и пользователей Модуля СЦ. Консультация может быть предоставлена по согласованным с представителем Заказчика каналам коммуникации с регистрацией результата консультации в СРО Подрядчиком. Детальный порядок оказания консультационных услуг определен в Регламенте оказания Услуг

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

4.2.4.1. Требования к технической реализации компонента «Интерактивная карта» При реализации компонента «Интерактивная карта» должны учитываться требования, указанные ниже. 4.2.4.1.1. Требования к отображению элементов Повторяющихся элементы карты (ТС, ОТИ, события и пр.) должны отрисовываться с использованием аппаратного создания экземпляров объектов на пользовательском устройстве (WebGL/WebGPU)). Отрисовка каждого объекта отдельным запросом не допускается, должна обеспечиваться возможность одновременного отображения не менее 5 000 объектов без снижения производительности (30 кадров в секунду на тестовой конфигурации). 4.2.4.1.2. Уровни детализации объектов Для управления отображением сложных объектов должно быть создано не менее 3-х уровней детализации, отображаемых при изменении масштаба с возможностью автоматического переключения между уровнями. Все отображаемые объекты должны масштабироваться с учетом разрешения экрана пользователя с сохранением качества детализации. 4.2.4.1.3. Полигональная оптимизация и текстурирование При реализации компонента «Интерактивная карта» должна обеспечиваться технология рельефного тестурирования объектов. Не должны использоваться высокополигональные трехмерные модели. Все повторяющиеся элементы должны генерироваться единоразово и повторно использоваться при последующих отображениях. 4.2.4.1.4. Управление памятью Требуется реализовать потоковую загрузку на устройство пользователя элементов карты и текстур. Загрузка данных целиком при старте приложения не допускается. Необходимо реализовать механизм очистки памяти от элементов, которые находятся вне области видимости камеры в течение заданного времени. 4.2.4.1.5. Требования к взаимодействию пользователя с интерфейсом компонента «Интерактивная карта» Программная реализация механизмов управление камерой (масштабирование и навигация) должна быть выполнена с поддержкой технологии WebAssembly (WASM). Элементы управления должны являться неотъемлемой частью интерактивной карты.

4.2.5. Развитие компонента администрирования (3 очередь) Должна быть выполнена доработка ролевой модели. Ролевая модель должна обеспечивать управление доступом к отдельным объектам Модуля СЦ и их элементам (атрибутам) с разграничением по видам транспорта, регионам и пр., в частности: – определение набора конкретных действий, доступных пользователям (выполняемых над объектом доступа, например, удаление записи, редактирование записи, формирование отчета и др.); – реализация возможности объединения пользователей в группы; – определение прав доступа для групп пользователей; – реализация интерфейса визуальной настройки прав доступа пользователей к объектам Модуля СЦ

4.3.1.2. Требования к общему порядку оказания услуг Техническая поддержка Модуля СЦ должна быть организована на трех уровнях: – первый и второй уровни технической поддержки организуется Заказчиком; – третий уровень технической поддержки организуется Подрядчиком. Перечень действий на каждом уровне технической поддержки указан в Таблице 5: Таблица 5 – Перечень действий на каждом уровне технической поддержки Уровень технической поддержки Доступные действия Условия передачи задачи на следующий уровень Первый уровень технической поддержки (далее – 1-й уровень) – принимает обращения (заявки) пользователей Модуля СЦ и работников Заказчика; – регистрирует обращения в Модуле СЦ регистрации обращений; – присваивает уникальный идентификационный номер, классифицирует обращения; – самостоятельно решает обращения, которые связаны с недостаточной квалификацией пользователей или настройками в рамках своей компетенции; – взаимодействует с пользователями Модуля СЦ при решении проблемы Передает обращение на второй уровень поддержки в случае невозможности решения на своем уровне Второй уровень технической поддержки (далее – 2-й уровень) – принимает обращения от 1-го уровня; – уточняет классификацию обращения в результате дополнительного анализа; – самостоятельно решает обращения в рамках своей компетенции; – осуществляет техническую и консультационную поддержку Модуля СЦ; – взаимодействует с сотрудниками 1-го и 3-го уровня и пользователями Модуля СЦ; – формирует заявки для 3-го уровня и контролирует исполнение Передает обращение на третий уровень поддержки в случае невозможности решения на своем уровне Третий уровень технической поддержки (далее – 3-й уровень) – принимает обращения от 2-го уровня; – обеспечивает выполнение требований, предъявляемых Контрактом и настоящим Техническим заданием к Услугам, оказываемым Подрядчиком Все поступающие обращения должны быть исполнены Подрядчиком

Для обеспечения взаимодействия с Заказчиком Подрядчик со своей стороны определяет ответственных лиц, уполномоченных в структуре Подрядчика за своевременное и качественное оказание Услуг в рамках настоящего ТЗ, а также контактную информацию ответственных лиц (телефон, электронную почту). Подрядчик должен предоставить Заказчику единый адрес электронной почты для приема обращений (заявок) в течение 3 (трех) рабочих дней после заключения Контракта. Указанный в настоящем пункте адрес электронной почты (способ направления обращений (заявок) применяется в случае сбоя в работе СРО Заказчика. Со своей стороны, Заказчик предоставляет Подрядчику перечень и контактную информацию (телефон, электронную почту) уполномоченных лиц для осуществления взаимодействия с указанием зон ответственности. О любых изменениях в контактной информации ответственных лиц Стороны должны уведомить друг друга в течение 1 (одного) рабочего дня с момента возникновения таких изменений посредством уведомления на электронную почту ответственных лиц и/или в письменной форме. В результате оказания услуг по настоящему ТЗ не должны быть изменены исходные коды, дистрибутивы и иные компоненты Модуля СЦ вне согласованных с Заказчиком изменений. Любые изменения исходных кодов, дистрибутивов и иных компонентов Модуля СЦ должны производиться только после согласования с Заказчиком уполномоченными лицами по электронной почте или иным заранее согласованным способом. Не должна быть ухудшена надежность и производительность Модуля СЦ. Оказание услуг по Контракту не должно нарушать требования к информационной безопасности, описанной в документации на Модуль СЦ

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

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

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

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

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

4.3.6.4.1. Требования к проведению изменений Основанием для внесения изменений является запрос от Заказчика. Все активности по внесению изменений должны быть согласованы с Заказчиком, а действия Подрядчика при оказании данной услуги должны быть зафиксированы. В рамках данного Технического задания изменениями считаются локальные доработки функционала Модуля СЦ, которые не должны приводить к необходимости выполнения дополнительных аттестационных испытаний или переаттестации АСУ ТК в соответствии с п. 33 приказа от 29.04.2021 № 77 «Об утверждении Порядка организации и проведения работ по аттестации объектов информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну». При необходимости внесения изменений в Модуль СЦ, не связанных с критичным инцидентом, существенно нарушающим работоспособность Модуля СЦ, Заказчик направляет Подрядчику обращение (заявку), в котором излагает суть изменения, которое требуется внести в Модуль СЦ. Исполнитель, в течение 3 (трех) рабочих дней с момента поступления соответствующего обращения (заявки), оценивает техническую возможность реализации запрашиваемого изменения и варианты реализации. По итогу проведения оценки Подрядчик направляет Заказчику заключение о возможности реализации данного изменения с описанием возможных вариантов реализации и согласует с Заказчиком проведение данного изменения

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

4.3.4. Требования к документированию результатов оказываемых услуг Для обеспечения контроля оказываемых услуг по поддержке Модуля СЦ со стороны Заказчика, по окончании каждого отчетного периода по контракту в соответствии с календарным планом, Подрядчик обязан предоставить Заказчику Отчет об оказанных услугах. Отчет должен содержать детальную информацию об оказанных услугах с указанием даты выполненных мероприятий и приложением обосновывающих документов (заявок, запросов, требований) или ссылкой на такие документы, если они содержатся в Модуле СЦ. Информация о выполненных мероприятиях по заявкам должна быть сформирована на основании соответствующих записей СРО по каждому этапу исполнения Контракта. В случае оказания услуги адаптационного, конфигурационного и коррекционного сопровождения Модуля СЦ, должны быть предоставлены документы, подтверждающие выполнение требований п. 29.3 приказа ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации». Фактическое время реагирования и время решения по всем обращениям, поступившим в СРО, формируется в СРО по итогам отчетного периода в разделе «Отчеты». Фактическое время реагирования и время решения по обращениям учитывает суммарное время, затраченное на реагирование и, соответственно, на работу по обращению с момента назначения обращения специалисту Подрядчика или группе исполнителей, ответственным за оказание услуг технической поддержки 3 уровня от начала до завершения работ Подрядчиком. При этом принимается суммарное время нахождения заявки в соответствующих статусах заявки СРО на стороне Подрядчика

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

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

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

4.3.6.4. Требования к услугам адаптационного, конфигурационного и коррекционного сопровождения и доработки Модуля СЦ (в рамках действующих программных модулей и функциональностей) Услуги адаптационного, конфигурационного и коррекционного сопровождения и доработки Модуля СЦ включают: – управление изменениями и адаптация функций Модуля СЦ; – изменение настроек функционирования Модуля СЦ; – внесение изменений и/или модификаций Модуля СЦ (в рамках действующих программных модулей и функциональностей), направленных на улучшение их работоспособности и функциональных возможностей; – подготовка и передача Заказчику SQL запросов в СУБД для получения агрегированной информации из Модуля СЦ, которую невозможно получить с использованием графического пользовательского интерфейса; – адаптация модулей интеграций со смежными информационными системами

4.3.6.4.2. Требования к изменению настроек функционирования Изменение настроек функционирования может проводиться в рамках допустимых пределов изменения функционирования, заложенных в архитектуру Модуля СЦ. Изменение настроек функционирования включает в себя изменение данных и справочников, изменение форм документов, формируемых Модулем СЦ, изменение и настройку форматов и версий передачи данных в смежные системы. Доработка программного кода Модуля СЦ может допускаться (в случае необходимости) при выполнении работ по адаптации функций Модуля СЦ в части изменения формата передачи данных в смежные информационные системы при условии соблюдения требований пункта 29.3 приказа ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации»

4.3.6.5. Требования к услугам по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности По запросу Заказчика Подрядчик должен провести работу по приведению ППО в соответствие с требованиями по обеспечению информационной безопасности. Критичность уязвимости оценивается в соответствии в соответствии с Методическим документом ФСТЭК России «Методика оценки уровня критичности уязвимостей программных, программно-аппаратных средств» (утвержден ФСТЭК России 30.06.2025), а также с учетом ГОСТ 56545-2015 и международными стандартами (CVSS 3.0 и выше), и задает необходимый срок устранения. В процессе проведения Заказчиком обследования Модуля СЦ и выявления уязвимостей в ППО, связанных с исходным кодом Модуля СЦ и/или используемыми компонентами (библиотеками), Заказчик направляет Подрядчику обращение (заявку) на устранение, с указанием критичности и срочности принятия мер по устранению в СРО.

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

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

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

4.5. Общие технические требования 4.5.1. Требования к численности и квалификации персонала и пользователей Модуля СЦ Программное обеспечение Модуля СЦ не должно требовать изменения штатной численности персонала Заказчика. Программное обеспечение Модуля СЦ не должно требовать наличия у пользователей дополнительной квалификации в сфере информационных технологий, кроме базовых знаний в обращении с персональным компьютером, базовых навыков работы в интернет-обозревателях и знаний о Модуле СЦ в объеме документов Руководство пользователя, Руководство администратора

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

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

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

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

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

4.4. Требования к видам обеспечения 4.4.1. Требования к лингвистическому обеспечению Документация на Модуль СЦ должна разрабатываться на русском языке. Взаимодействие пользователей с Модулем СЦ посредством графического интерфейса должно происходить на русском языке за исключением сообщений, зависящих от настроек системного программного обеспечения, установленного на рабочих местах пользователей. При разработке программных решений Модуля СЦ должно быть предусмотрено использование языков программирования высокого уровня, приведенных в Таблице 7. Таблица 7. Языки и средства разработки, специального программного обеспечения Модуля СЦ Категория Наименование Назначение Языки программирования Kotlin Разработка серверной логики и сервисов (backend) JavaScript / TypeScript Разработка клиентской части (frontend) Python Разработка скриптов интеграции, обработки данных и автоматизации Фреймворки и библиотеки Vue.JS Разработка пользовательских интерфейсов (веб-интерфейсы компонентов визуализации и отчетности) React Разработка пользовательских интерфейсов (при необходимости создания сложных интерактивных компонентов) Решения по лингвистическому обеспечению, включая перечень используемых языков программирования, должны быть согласованы с Заказчиком на этапе технического проектирования

В аварийном режиме осуществляется поиск неисправностей и проведение работ по их устранению. Перевод в аварийный режим должен осуществляться при возникновении сбоев, аварий и прочих незапланированных воздействий, сразу после наступления одной или нескольких аварийных ситуаций, с последующим возвратом в штатный режим функционирования сразу после окончания восстановительных работ. ПО Модуля СЦ должно обладать надежностью, обеспечивающей работу пользователей в произвольном режиме и оперативное восстановление работоспособности при сбоях. В целях обеспечения надежного функционирования ПО должно предусматривать: – сохранение целостности данных при нештатном завершении работы компонентов Модуля СЦ; – сохранение работоспособности программного обеспечения при некорректных действиях пользователя; – резервное копирование базы данных Модуля СЦ. – время восстановления работоспособности Модуля СЦ после отказа не более 4 часов. – отказоустойчивость на уровне 99% при единовременной количестве не менее 200 пользовательских сессий в Модуле СЦ. Указанные характеристики приведены без учета характеристик надежности инфраструктуры и времени передачи информации по каналам связи. При возникновении сбоев в аппаратном обеспечении, включая аварийное отключение электропитания, Модуль СЦ должен автоматически восстанавливать свою работоспособность (не требовать перенастройки) после устранения сбоев и корректного перезапуска аппаратного обеспечения

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

4.5.3. Требования по диагностированию Модуля СЦ Диагностирование Модуля СЦ должно осуществляться путем анализа записей в системных журналах СУБД, операционных систем серверов, а также с помощью встроенных средств диагностирования общего программного обеспечения Модуля СЦ. Диагностированию подлежат: – сбои и нарушения функционирования технического обеспечения (серверов) Модуля СЦ; – сбои и нарушения функционирования системного программного обеспечения серверов, используемых для работы Модуля СЦ; – сбои и нарушения функционирования прикладного программного обеспечения серверов, используемых для работы Модуля СЦ; – случаи недоступности (отсутствия ответа) или некорректные ответы внешних систем; – сбои и нарушения функционирования СУБД; – сбои при выполнении регламентных операций резервного копирования. При возникновении аварийных ситуаций либо ошибок в программном обеспечении диагностические инструменты должны позволять сохранять набор информации, необходимой для идентификации и устранения проблемы. Модуль СЦ и ее компоненты должны обеспечивать возможность диагностики своей работоспособности с возможностью интеграции с модулем мониторинга АСУ ТК. Набор передаваемых журналов и метрик должен быть определен на этапе технического проектирования

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

4.5.8. Требования к защите от влияния внешних воздействий Требования к защите от влияния внешних воздействий не предъявляются

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

4.4.2. Требования к математическому обеспечению Требования к математическому обеспечению не предъявляются. 4.4.3. Требования к метрологическому обеспечению Требования к метрологическому обеспечению не предъявляются. 4.4.4. Требования к организационному обеспечению Требования к организационному обеспечению не предъявляются. 4.4.5. Требования к методическому обеспечению Задачи методического обеспечения Модуля СЦ должны быть обеспечены за счет использования технологических и методических документов касающихся вопросов функционирования транспортного комплекса и разработки и эксплуатации ПО. 4.4.6. Требования к информационному обеспечению Состав, структура и способы организации информационного обеспечения в Модуле СЦ должны быть определены на этапе технического проектирования. Факты информационного обмена с внешними системами должны фиксироваться в соответствующем журнале

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

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

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

4.5.5. Требования к информационной безопасности Работы по защите информации/информационной безопасности, не включенные в состав настоящего раздела, требуемые в соответствии с требованиями постановления Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации», а также нормативно правовых актов в области защиты персональных данных и обеспечения безопасности объектов критической информационной инфраструктуры, будут проведены в рамках исполнения отдельного контракта, заключенного по результатам отдельной закупочной процедуры (не является частью данного ТЗ), включающего: – определение актуальных угроз безопасности информации и актуализация модели угроз безопасности информации (при необходимости); – выполнение требований о согласовании технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России в установленном порядке; – выполнение требований по устранению Подрядчиком замечаний и недостатков, в случае их выявления при согласовании Заказчиком технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России; – выполнение требований к классу защищенности ГИС, уровню защищенности персональных данных и категории значимости объекта КИИ РФ, установленных для Головного центра обработки данных ФГБУ «СИЦ Минтранса России» (далее – ГЦОД);

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

Лицензионное (сублицензионное) соглашение (договор) не может возлагать на Заказчика какие-либо обязанности (в т.ч. в части конфиденциальности, предоставления отчетности), не предусмотренные Контрактом. 4.5.9.7. Передача Заказчику исключительных прав, или простых (неисключительных) прав не может повлечь увеличение стоимости Контракта и/или изменение иных существенных условий Контракта. 4.5.9.8. Функциональность Модуля СЦ передается в объеме и в сроки, установленные Техническим заданием. 4.5.9.9. Нарушение условий настоящего раздела Технического задания, в т.ч. отсутствие соответствующего лицензионного (сублицензионного) соглашения (или договора), либо предоставление лицензионного (сублицензионного) соглашения (или договора), не соответствующего требованиям действующего законодательства Российской Федерации или требованиям Контракта, является нарушением существенных условий Контракта. 4.5.9.10. В случае, если в соответствии с пунктом 4.5.9.6 Заказчику передается исключительное право, такая передача осуществляется в порядке, установленном Гражданским кодексом Российской Федерации. 4.5.9.11. В случае, если при выполнении Работ положения пунктов 4.5.9.5-4.5.9.6 не применялись, Подрядчик в составе отчетной документации предоставляет об этом декларацию в свободной форме. Декларация должна содержать сведения о полном соответствии результата Работ требованиям Контракта, а также о неприменении при выполнении работ готового программного обеспечения (платформ, подсистем, СУБД и т.д.), которое стало частью (компонентом) Системы

– определение перечня объектов защиты информационной системы; – описание (актуализированных) требований к системе защиты информации, а также к мерам защиты информации информационной системы в зависимости от установленных классов защищенности, уровня защищенности персональных данных и категории значимости объектов КИИ РФ (приказы ФСТЭК России № 21, 117, 239); – выполнение требований к мерам по защите ГИС от атак, направленных на отказ в обслуживании, в соответствии с пунктами 30, 34, 59, 63 Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений, утвержденных приказом ФСТЭК России от 11.04.2025 № 117; – описание (актуализированных) требований по защите информации, подлежащих реализации в информационно телекоммуникационной инфраструктуре ГЦОД; – выполнение требований о применении сертифицированных средств защиты информации, включая их классы защиты и уровни доверия; – выполнение требований о запрете использования с 01.01.2025 органами (организациями) средств защиты информации странами происхождения, которых являются иностранные государства в соответствии с пунктом 6 Указа Президента Российской Федерации от 01.05.2022 № 250; – выполнение требований по обеспечению непрерывного взаимодействия с ГосСОПКА в установленном порядке;

– выполнение требований по обеспечению в автоматизированном режиме с Национальной системой противодействия DDoS-атакам (НСПА) Центра мониторинга и управления сетью связи общего пользования ФГУП «ГРЧЦ» в рамках реализации мер по защите ГИС от атак, направленных на отказ в обслуживании; – детализированные требования к составу и содержанию работ по аттестации, а также к их результатам в соответствии с пунктами 13, 15 и 16 требований приказа ФСТЭК России от 29.04.2021 № 77 «Об утверждении Порядка организации и проведения работ по аттестации объектов информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну»

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

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

5. СОСТАВ И СОДЕРЖАНИЕ РАБОТ ПО РАЗВИТИЮ И ТЕХНИЧЕСКОЙ ПОДДЕРЖКЕ МОДУЛЯ СЦ (КАЛЕНДАРНЫЙ ПЛАН) - Сдача-приемка результатов выполненных работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная техническая документация, а также результаты работ предоставляются Заказчику в порядке, предусмотренном Контрактом и ТЗ, до размещения Подрядчиком в ЕИС документа о приемке. Документ о приемке размещается в ЕИС по каждому этапу в соответствии с условиями Контракта. Этапы выполнения работ по развитию Модуля СЦ приведены в Таблице 11. Таблица 11. Этапы выполнения работ по развитию Модуля СЦ. № этапа Наименование этапа Результат (отчетная документация) Срок исполнения этапа - - Значение характеристики не может изменяться участником закупки

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

1 Техническое проектирование Сопроводительным письмом предоставляются Заказчику: · Технический проект, включая следующие документы: – Ведомость технического проекта; – Ведомость машинных носителей информации – Пояснительная записка; – Описание информационного обеспечения системы; – Описание автоматизируемых функций; – Схема функциональной структуры; – Описание организации информационной базы; – Описание программного обеспечения; · Макеты экранных форм компонента «Интерактивная карта»; · Руководство по безопасной разработке программного обеспечения; · Документ о приемке Начало: с даты заключения контракта Окончание: не позднее 31.07.2026

2 Услуги по технической поддержке Модуля СЦ (с даты заключения контракта по 10.09.2026) По окончании оказания Услуг сопроводительным письмом предоставляются Заказчику: – Отчет об оказанных Услугах по технической поддержке; – Актуальные на дату окончания оказания Услуг по данному этапу исходные коды прикладного ПО на электронном носителе (в случае внесения изменений); – Инструкция по сборке и развертыванию (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство пользователя (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство администратора (в случае внесения изменений); – Документ о приемке Начало: с даты заключения контракта Окончание: не позднее 10.09.2026

3 Разработка программного обеспечения (1 очередь, пп. 4.2.1, 4.2.6 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ; – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 1 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 1 очереди; – Руководство по резервному копированию; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 16.09.2026

4 Разработка программного обеспечения (2 очередь, пп. 4.2.3, 4.2.4 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ. – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 2 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 2 очереди; – Руководство по резервному копированию; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 25.09.2026

5 Разработка программного обеспечения (3 очередь, пп. 4.2.2, 4.2.5 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ; – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 3 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 3 очереди; – Руководство по резервному копированию; – Описание ролевой модели; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 09.10.2026

6 Опытная эксплуатация (1 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акт о завершении опытной эксплуатации 1 очереди; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке 17.09.2026 Окончание: не позднее 26.10.2026

7 Опытная эксплуатация (2 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акт о завершении опытной эксплуатации 2 очереди; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке 26.09.2026 Окончание: не позднее 26.10.2026

8 Опытная эксплуатация (3 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Акт о завершении опытной эксплуатации 3 очереди; – Документ о приемке Начало: с 10.10.2026 Окончание: не позднее 26.10.2026

9 Приемочные испытания Сопроводительным письмом предоставляются Заказчику: – Программа и методика приёмочных испытаний; – Протокол приемочных испытаний; – Исходные коды и дистрибутивы на электронном носителе (при условии внесения изменений, с учетом доработок по результатам опытной эксплуатации и проведенных испытаний); – Комплект рабочей документации на Модуль СЦ (при условии внесения изменений, с учетом доработок по результатам опытной эксплуатации и проведенных испытаний); – Акт приемки Системы в эксплуатацию; – Акт приемки-передачи исключительных прав на объект; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке; – Документы в соответствии с разделом 4.5.9 ТЗ; – Обеспечение гарантийных обязательств Начало: с 27.10.2026 Окончание: не позднее 10.11.2026

10 Услуги по технической поддержке Модуля СЦ (с 11.09.2026 по 15.12.2026) По окончании оказания Услуг сопроводительным письмом предоставляются Заказчику: – Отчет об оказанных Услугах по технической поддержке; – Актуальные на дату окончания оказания Услуг по данному этапу исходные коды прикладного ПО на электронном носителе (в случае внесения изменений); – Инструкция по сборке и развертыванию (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство пользователя (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство администратора (в случае внесения изменений); – Документ о приемке Начало: с 11.09.2026 Окончание: не позднее 15.12.2026

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

6.1. Сведения о гарантийном обслуживании Модуля СЦ Под гарантией понимается устранение Подрядчиком своими силами и за свой счет допущенных по его вине недостатков, выявленных после приемки выполненных Работ, как в работе самой Модуля СЦ, так и недостатков в отчетной документации. Если в период гарантийного срока обнаружатся недостатки, то Подрядчик обязан устранить их за свой счет, в сроки, установленные Заказчиком. Гарантийный срок в этом случае продлевается на период устранения недостатков. Срок гарантии: 1 год с даты приемки Заказчиком результатов исполнения Этапа № 9 контракта. Подрядчиком должны быть внесены соответствующие исправления в техническую и рабочую документацию (указанную в пунктах 5 и 6 настоящего ТЗ), связанные с устранением замечаний к работе Модуля СЦ или в случае выявления Заказчиком недостатков в такой документации в период гарантийного срока. Внесение изменений в документацию технического и рабочего проектирования осуществляется в соответствии с ГОСТ 2.503-2023 и ГОСТ Р 2.504-2021.

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

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

8. ТРЕБОВАНИЯ К СОСТАВУ И СОДЕРЖАНИЮ РАБОТ ПО ПОДГОТОВКЕ МОДУЛЯ СЦ К ВВОДУ В ЭКСПЛУАТАЦИЮ - По результатам проведения приемочных испытаний оформляется Протокол приемочных испытаний и Акт приемки в эксплуатацию. В случае, если взаимодействие с внешними системами не может быть проверено на средах постоянной эксплуатации взаимодействующих систем (по причине неготовности со стороны внешней системы или иным причинам), функции взаимодействия, разработанные в соответствии с требованиями ТЗ, должны быть проверены на тестовых данных с использованием программ-имитаторов взаимодействия. По результатам выполнения этапа приемочных испытаний должны быть подготовлены материалы для регистрации доработанной версии Модуля СЦ (объекта учета) в НФАП в соответствии с требованиями постановления Правительства Российской Федерации от 30 января 2013?г. №?62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин» (с изменениями и дополнениями) в части обязательности размещения результатов работ в национальном фонде алгоритмов и программ для электронных вычислительных машин. Сдача-приемка результатов выполнения Работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная, техническая документация, а также программное обеспечение предоставляется Заказчику в порядке, предусмотренном Контрактом и ТЗ до размещения Подрядчиком в Единой информационной системе в сфере закупок документа о приемке. Результаты проведения опытной эксплуатации, предварительных и приемочных испытаний должны быть зафиксированы в соответствующих протоколах и актах. Выявленные отклонения от настоящего ТЗ, оформляются как недостатки Модуля СЦ - - Значение характеристики не может изменяться участником закупки

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

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

9. ТРЕБОВАНИЯ К ДОКУМЕНТИРОВАНИЮ - 9.1. Общие требования Документация на Модуль СЦ должна быть разработана в составе, указанном в разделах 5-8 данного ТЗ, и должна удовлетворять требованиям комплекса стандартов и руководящих документов на автоматизированные системы: – ГОСТ Р 2.105-2019 в части оформления текстовых документов; – ГОСТ 34.201-2020 в части наименования и обозначения документов. Документация на Модуль СЦ должны оформляться на листах формата А4. Допускается для размещения рисунков и таблиц использование листов формата А3 с подшивкой по короткой стороне листа. Документы объемом более 25 (двадцати пяти) листов должны содержать информационную часть, состоящую из аннотации и содержания. Исходные коды должны быть представлены в 1 (одном) экземпляре на электронном носителе, отчетные материалы должны быть представлены в 2 (двух) экземплярах на бумажном носителе (по одному экземпляру для Заказчика и Подрядчика) и в 1 (одном) экземпляре на электронном носителе в формате документов DOCX и PDF. При разработке документов на Модуль СЦ допускается отклонение от требований комплекса стандартов, описанных выше. Документам на Модуль СЦ должны в обязательном порядке присваиваться уникальные децимальные номера в соответствии с порядком, установленном в ГОСТ 34.201-2020. Документ «Программа и методика предварительных испытаний» должен включать приложения с формой протокола предварительных испытаний и формой акта приемки в опытную эксплуатацию. Документ «Программа опытной эксплуатации» должен включать приложение с формой журнала опытной эксплуатации. Документ «Программа и методика приемочных испытаний» должен включать приложения с формой протокола приемочных испытаний и формой акта приемки в эксплуатацию - - Значение характеристики не может изменяться участником закупки

10. ИСТОЧНИКИ РАЗРАБОТКИ - 10.1. Список литературы Специальная литература для разработки ТЗ не использовалась. 10.2. Нормативно-методические документы Список используемых нормативно-методических документов представлен в разделе 1.6 технического задания. ? Приложение А Эскизы визуального оформления компонента «Интерактивная карта» - - Значение характеристики не может изменяться участником закупки

Приложение Б Параметры оказания услуг - 1 Режим работы Системы Круглосуточно (24х7) 2 Режим доступности информационно-консультационной поддержки пользователей Системы 2.1 Прием и регистрация обращений (заявок) в СРО Регистрация обращений (заявок) производится круглосуточно в режиме 24х7, без праздников и выходных дней. Обработка заявок первой линией поддержки осуществляется в рабочие дни с 9 до 18 часов 2.2 Консультирование сотрудников Заказчика и пользователей Системы в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 3 Режим доступности по решению инцидентов, связанных с работой ППО: 3.1 - приоритет «Критический» Круглосуточно (24х7) 3.2 - приоритет «Высокий» Круглосуточно (24х7) 3.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 3.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4 Режим доступности услуг по адаптации, конфигурации и коррекционному сопровождению Системы 4.1 - приоритет «Критический» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.2 - приоритет «Высокий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 5 Режим доступности по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности 5.1 - приоритет «Критический» Круглосуточно (24х7) 5.2 - приоритет «Высокий» Круглосуточно (24х7) 5.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 5.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) - - Значение характеристики не может изменяться участником закупки

Таблица Б.1.2. Сроки предоставления отчетности, с момента получения запроса № п/п Параметр Значение 1 Предоставление отчета об оказанных услугах за произвольный период 10 рабочих дней 2 Предоставление подробной информации по инциденту с приоритетом «Критический» 16 рабочих часов 3 Предоставление актуализированной документации 10 рабочих дней

Б.2. Приоритеты и регламентные сроки решения обращений (заявок) В зависимости от уровня сбоя в работе Системы обращению (заявке) присваивается один из следующих приоритетов, а также в зависимости от приоритета обращения (заявки) устанавливаются следующие контрольные сроки решения в соответствии с таблицей ниже (Таблица Б.2.1). Таблица Б.2.1 – Приоритеты и регламентные сроки решения обращений (заявок) № п/п Приоритет Максимальное время реагирования Время решения (срок выполнения) Описание приоритета По информационно-консультационной поддержке сотрудников Заказчика и пользователей Системы 1 - не более 1 часа не более 10 часов - По решению инцидентов, связанных с работой ППО: 1 Критический не более 30 минут не более 4 часов - полная недоступность ППО; - недоступность ключевых функций - ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО; - невозможность информационного обмена с ППО для ИС более 4 часов 2 Высокий не более 1 часа не более 8 часов - ошибки/сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; - снижение быстродействия СПО (время отклика ППО на операции превышает 30 секунд); - недоступность управления правами и ролями пользователей 3 Средний не более 4 часов не более 24 часов - невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым -недоступность функции формирования отчетов 4 Низкий не более 8 часов не более 40 часов - отклонение в работе ППО, не влияющее на корректную работу функций; - другие сбои и ошибки, затрагивающие основные функции ППО

По адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) 1 Критический не более 40 минут не более 8 часов - изменения, необходимые при проведении аварийно-восстановительных работ для возобновления работоспособности Системы; - изменения, связанные с критичными ошибками, блокирующими возможность оказания государственных услуг и/или чтение и внесение данных в Систему 2 Высокий не более 1 часа не более 40 часов - изменения, относящиеся к обеспечению работоспособности основной функциональности Системы, устраняют выявленные дефекты в работе Системы, оказывающие существенное влияние на работу пользователей в Системе; - изменения, затрагивающие три и более подсистемы/модуля Системы для адаптации 3 Средний не более 4 часов не более 72 часов - изменения, связанные с развитием/улучшением/оптимизацией Системы и выводом новой функциональности в штатном режиме для одного-двух модулей/подсистем; - изменения, связанные с развитием интеграционных механизмов Системы, например обновление существующих и/или реализация новых видов сведений СМЭВ, обновление существующих и/или реализация новых API, адаптация и/или изменение механизмов импорта и экспорта данных Системы и т.д. 4 Низкий не более 8 часов не более 160 часов - изменения, связанные с ошибками/корректировкой/изменением в отображении информации в пользовательском графическом интерфейсе Системы (графика, текст, органы управления, элементы интерфейса)

По устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности 1 Критический не более 30 минут не более 24 часов - критические уязвимости, влияющие на возможную полную недоступность ППО, ключевых функций Системы, ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО без возможности восстановления работоспособности Системы. - Критический уровень CVSS > 8.0 2 Высокий не более 1 часа не более 84 часов - критические уязвимости, влияющие на ошибки и сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО. - Высокий уровень CVSS 5.0 - 8.0 3 Средний не более 4 часов не более 120 часов - уязвимости, влияющие на невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым - Средний уровень CVSS 2.0 - 4.9 4 Низкий не более 8 часов не более 160 часов - уязвимости, влияющие на отклонение в работе ППО, не влияющее на корректную работу функций; - другие сбои и ошибки, затрагивающие основные функции ППО - Низкий уровень CVSS < 2.0

Взаимодействие Заказчика и Подрядчика в части регистрации и контроля времени реагирования и решения обращения (заявки) осуществляется через СРО. Заказчик предоставляет Подрядчику доступ к СРО после заключения Контракта. Поступившие от разных пользователей заявки по поводу однотипных инцидентов или имеющие общую причину должны объединяться в одну заявку. Срок выполнения включает время диагностики инцидента, в ходе которого определяется причина инцидента (проблемы) и способ его устранения. Подрядчик должен обеспечить функционирование Модуля СЦ в соответствии с требованиями и параметрами, указанными в настоящем ТЗ и Регламенте оказании услуг. Основные параметры быстродействия типовых операций в Модуле СЦ указаны в таблице ниже (таблица Б.2.2). Таблица Б.2.2 - Параметры быстродействия Модуля СЦ № п/п Наименование параметра Значение (секунд) 1 Среднее время получения сообщения из очереди сообщений 10 2 Среднее время получения ответа от Системы 5 3 Среднее время открытия карточки реестра 5

Б.1. Базовые параметры оказания Услуг Базовые параметры оказания Услуг приведены ниже: – режимы оказания Услуг (таблица Б.1.1); – сроки предоставления отчетности (таблица Б.1.2). Таблица Б.1.1 - Режимы оказания Услуг № п/п Параметр Значение

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

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

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

Таблица 1 - Типы обращений (заявок) Тип обращения (заявки) Описание Запрос на обслуживание Подготовка SQL запроса к СУБД для решения прикладной задачи и д р. – запрос на любое действие, не являющееся запросом информации и несовершенный на основе происшествия, прямо или косвенно влияющего на работу Системы Консультация (входит в тип обращения (заявки) «Запрос на обслуживание») «Где взять / куда обратиться...?», «Как сделать / выполнить…», «Как это работает…?» - запрос, имеющий своей целью получение информационной поддержки Инцидент Разбор ошибок/сбоев и подготовка материалов (корректировочных релизов, инструкций) для Заказчика для устранения ошибок/сбоев, которые приводят к частичному и полному нарушению работоспособности всех или отдельных функций ППО. Подготовка изменения и материалов, необходимых для проведения аварийно-восстановительных работ для возобновления работоспособности Системы. ЗНИ Подготовка изменений, связанных с изменением, улучшением/оптимизацией Системы и выводом новой модифицированной функциональности в штатном режиме. Подготовка изменений, связанных с модификацией существующих и/или реализация новых интеграционных механизмов для получения/обработки данных внешних систем. Подготовка изменений графического интерфейса по требованиям Заказчика

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

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

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

4.3. Форма обращения (заявки) на оказание услуг по адаптационному конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) При подаче обращения (заявки) типа «ЗНИ» в СРО указывается (Таблица 7): Таблица 7 – Описание атрибутов формы обращения (заявки) на оказание услуг по адаптационному, конфигурационному и коррекционному сопровождению Системы Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 10) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 9) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 10) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 10) Категория обращения (заявки): запрос на изменение Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 7) Приоритет изменения Время, очередность решения обращения (заявки), ресурсы, привлекаемые для решения обращения (заявки), порядок/процедура действий при решении обращения (заявки) – поле СРО «Приоритет» (см. рисунок 7) Тип изменения Справочник, классифицирующий типовые запросы характерные для Системы – поле СРО «Предмет обращения» (см. рисунок 7) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 7) Текст запроса на оказание услуги по адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 7)

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

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

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

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

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

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

На рисунке 8 приведена форма обращения (заявки) типа «Инцидент» в СРО. Рисунок 8 - Форма обращения (заявки) типа «Инцидент» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуги по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности, заполненную в свободной форме

Приложение 1 к Регламенту Матрица ответственных за взаимодействия в рамках выполнения работ по техническому сопровождению Системы Таблица 1 – Ответственные за взаимодействия в рамках выполнения работ по техническому сопровождению Системы со стороны Исполнителя ФИО Должность Адрес электронной почты Телефон — — — Общий контакт

Приложение 2 к Регламенту Приоритеты и регламентные сроки решения обращений (заявок) Приоритеты и регламентные сроки решения обращений (заявок) приведены в таблице 1. Таблица 1 – Приоритеты и регламентные сроки решения обращений (заявок) № п/п Приоритет Максимальное время реагирования Время решения (срок выполнения) Описание приоритета

По информационно-консультационной поддержке сотрудников Заказчика и пользователей Системы 1 – не более 1 часа не более 10 часов –

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

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

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

3.4.1 Инцидент На рисунке 2 представлена функциональная схема регистрации и сопровождения обращений (заявок) типа «Инцидент». Рисунок 2 - Функциональная схема регистрации и сопровождения обращений (заявок) типа «Инцидент» 3.4.2 Запрос на обслуживание На рисунке 3 представлена функциональная схема регистрации и сопровождения обращения (заявки) типа «ЗНО». Рисунок 3 - Функциональная схема регистрации и сопровождения обращения (заявки) типа «ЗНО» 3.4.3 Запрос на изменение На рисунке 4 представлена функциональная схема регистрации и сопровождения обращений (заявок) типа «ЗНИ». Рисунок 4 - Функциональная схема регистрации и сопровождения обращений (заявок) типа «ЗНИ»

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

По решению инцидентов, связанных с работой ППО 1 Критический не более 30 минут не более 4 часов – полная недоступность ППО; – недоступность ключевых функций; – ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО; – невозможность информационного обмена с ППО для ИС более 4 часов 2 Высокий не более 1 часа не более 8 часов – ошибки/сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; – снижение быстродействия СПО (время отклика ППО на операции превышает 30 секунд); – невозможность управления правами и ролями пользователей 3 Средний не более 4 часов не более 24 часов – невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым недоступность функции формирования отчетов 4 Низкий не более 8 часов не более 40 часов – отклонение в работе ППО, не влияющее на корректную работу функций; – другие сбои и ошибки, затрагивающие основные функции ППО

По адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) 1 Критический не более 40 минут не более 8 часов – изменения необходимые при проведении аварийно-восстановительных работ для возобновления работоспособности Системы; – изменения, связанные с критичными ошибками, блокирующими возможность оказания государственных услуг и/или чтение и внесение данных в Систему 2 Высокий не более 1 часа не более 40 часов – изменения относящиеся к обеспечению работоспособности основной функциональности Системы, устраняют выявленные дефекты в работе Системы, оказывающие существенное влияние на процесс оказания государственных услуг и работу пользователей в Системе; – изменения, затрагивающие три и более подсистемы/модуля Системы для адаптации 3 Средний не более 4 часов не более 72 часов – изменения, связанные с развитием/улучшением/оптимизацией Системы и выводом новой функциональности в штатном режиме для одного-двух модулей/подсистем; – изменения, связанные с развитием интеграционных механизмов Системы, например, обновление существующих и/или реализация новых видов сведений СМЭВ, обновление существующих и/или реализация новых API, адаптация и/или изменение механизмов импорта и экспорта данных Системы и т.д. 4 Низкий не более 8 часов не более 160 часов – изменения, связанные с ошибками/ корректировкой/изменение в отображении информации в пользовательском графическом интерфейсе Системы (графика, текст, органы управления, элементы интерфейса)

По устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности 1 Критический не более 30 минут не более 24 часов – критические уязвимости, влияющие на возможную полную недоступность ППО, ключевых функций Системы, ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО без возможности восстановления работоспособности Системы; – Критический уровень CVSS > 8.0 2 Высокий не более 1 часа не более 84 часов – критические уязвимости, влияющие на ошибки и сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; – Высокий уровень CVSS 5.0 - 8.0 3 Средний не более 4 часов не более 120 часов – уязвимости, влияющие на невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым; – Средний уровень CVSS 2.0 - 4.9 4 Низкий не более 8 часов не более 160 часов – уязвимости, влияющие на отклонение в работе ППО, не влияющее на корректную работу функций; – другие сбои и ошибки, затрагивающие основные функции ППО; – Низкий уровень CVSS < 2.0

Уровень технической поддержки Организационно-структурная часть технической поддержки, имеющая определённые организационно-нормативными документами зоны ответственности, обязанности, а также временные нормативы, в течение которых эти обязательства должны выполняться либо эскалироваться на следующий уровень технической поддержки Услуги Услуги по технической поддержке Информационно-аналитической системы регулирования на транспорте АСУ ТК ФИО Фамилия, имя, отчество Эскалация Процедура повышения внимания к обращению (заявке) путем повышения его приоритета и/или передачи на следующий уровень технической поддержки, а также привлечение ролей, которые могут принимать решения без передачи на следующий уровень технической поддержки API Англ. Application Programming Interface — программный интерфейс приложения, интерфейс прикладного программирования — описание способов (набор классов, процедур, функций, структур или констант), которыми одна компьютерная программа может взаимодействовать с другой программой

CVSS Англ. Common Vulnerability Scoring System - открытый стандарт, используемый для расчета количественных оценок уязвимости в безопасности компьютерной системы, обычно с целью понять приоритет ее исправления. В современном инструментарии информационной безопасности используется версия 3.0 и выше с дополнительными метриками к базовым оценкам ID Англ. Identifier – идентификатор, уникальный признак объекта, позволяющий отличать его от других объектов, то есть, идентифицировать SLA Англ. Service Level Agreement - утвержденные условия по обработке обращения (заявки) с установленными метриками времени, которые определяют пороговые значения для эскалации в зависимости от статуса обращения (заявки) (например, время реакции – время от регистрации до осуществления первичной обработки, время решения – время от регистрации обращения (заявки) до его решения и т.д.) SQL Англ. Structured Query Language — «язык структурированных запросов», — декларативный язык программирования, применяемый для создания, модификации и управления данными в реляционной базе данных, управляемой соответствующей СУБД

1 Общие сведения 1.1 Полное наименование Услуг Оказание услуг по технической поддержке Модуля СЦ АСУ ТК в 2026 году. 1.2 Предмет Регламента оказания услуг Требования Технического задания

2 Общие положения 2.1 Цель и задачи оказания услуг Целью технической поддержки Системы является обеспечение ее стабильного и безопасного функционирования и эксплуатации, предупреждение, выявление и устранение сбоев в работе Системы и минимизация их неблагоприятного влияния. Для достижения поставленной цели требуется решение следующих задач: 1. Обеспечение информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы. 2. Поддержание параметров функционирования ППО Системы, удовлетворяющих требованиям производственных процессов, включая их непрерывность. 3. Обеспечение бесперебойного функционирования ППО и своевременное устранение сбоев и аварийных ситуаций в Системе. 4. Своевременное устранение уязвимостей при выявлении таковых, в соответствии с требованиями к обеспечению информационной безопасности. 5. Адаптация, конфигурирование, коррекция программного обеспечения в соответствии с изменениями нормативно-правовой базы и запросами уполномоченных сотрудников органов государственной власти, включая выполнение процедур тестирования и участие в обновлениях ППО на стендах Заказчика. 6. Обеспечение сохранения работоспособности ППО в изменяемой среде эксплуатации. 7. Ведение документации по настоящему контракту и инициирование актуализации документации на Систему по результатам обработки запросов Заказчика и внесения соответствующих изменений в ППО

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

4 Формы обращений (заявок) на оказание услуг по технической поддержке Системы, заполняемые в СРО 4.1. Форма обращения (заявки) на оказание услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы При подаче обращения (заявки) типа «ЗНО» в СРО указывается (Таблица 5): Таблица 5 – Описание атрибутов формы обращения (заявки) на оказание услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 5) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 5) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 5) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 5) Категория обращения: информационно-консультационная поддержка Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 5) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 5) Текст запроса на оказание услуги по информационно-консультационной поддержке сотрудников Заказчика Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 5)

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

Приложение Г Форма Отчета об оказанных услугах Отчет об оказанных услугах за этап «наименование этапа» в период с «__» _________ по «__» _________. № п/п Наименование услуги Общее количество Номер ОРС Краткое Описание Время реагирования по ТЗ Время реагирования фактическое Время решения по ТЗ Время решения фактическое Результат соблюдения времени реагирования Результат соблюдения времени решения Примечание 1 Услуги по информационно-консультационной поддержке работников Заказчика 2 546782 Консультация по работе Модуля СЦ 1 2 10 часов 11 часов Нет Нет 567123 Консультация по схеме БД 1 1 10 часов 1 час Да Да 2 … … Заказчик Подрядчик /Должность/ /Должность/ ____________________ /Ф.И.О/ ___________________ /Ф.И.О/ М.П. М.П. «_____»_______________________202_г. «_____»_______________________202_г

Приложение 1 к Отчету об оказанных услугах Журнал обращений (заявок) на оказание услуги по информационно-консультационной поддержке пользователей Системы (шаблон) Наименование Исполнителя в этапе «наименование этапа» в период с ________________ по _______________ оказал(о) Услугу по поддержке пользователей Системы в объеме, указанном в Таблице 1 Таблица 1 - Журнал обращений (заявок) пользователей Системы № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. ИТОГО зарегистрировано: Всего обращений (заявок): ________ ИТОГО решено: Всего обращений (заявок): ________

Приложение 2 к Отчету об оказанных услугах Журнал обращений (заявок) по решению инцидентов, связанных с работой ППО (шаблон) Наименование Исполнителя в этапе «наименование этапа» в период с ________________ по _______________ оказал(о) Услугу по решению инцидентов в объеме, указанном в Таблице 1. Таблица 1 - Журнал по решению инцидентов № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. ИТОГО зарегистрировано: Всего инцидентов: ________ ИТОГО решено: Всего инцидентов: ________

Приложение 3 к Отчету об оказанных услугах Журнал обращений (заявок) выполнения адаптационного, конфигурационного и коррекционного сопровождения Системы (шаблон) Журнал выполнения адаптации, конфигурации и коррекции Системы сформирован за этап «наименование этапа» в период с «__» _________ по «__» ____________ и представлен в таблице ниже (Таблица 1). Таблица 1 - Журнал выполнения адаптации, конфигурации и коррекции сопровождения Системы № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. Количество выполненных заявок за этап: ________

Приложение 4 к Отчету об оказанных услугах Журнал обращений (заявок) по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности (шаблон) Журнал обращений (заявок) по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности сформирован за этап «наименование этапа» в период с «__» _________ по «__» ____________ и представлен в таблице ниже (Таблица 1). Таблица 1 - Журнал выполнения заявок по устранению уязвимостей в ППО № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. Количество выполненных заявок за этап: ________

4.2. Форма обращения (заявки) на оказание услуги по решению инцидентов, связанных с работой ППО При подаче обращения (заявки) типа «Инцидент» в СРО указывается (Таблица 6): Таблица 6 – Описание атрибутов формы обращения (заявки) на оказание услуги по решению инцидентов, связанных с работой ППО Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 6) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 6) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 6,) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 6) Категория обращения (заявки): инцидент Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 6) Приоритет изменения Время - одно из значений: Низкий, Средний, Высокий или Критический. Определяет, очередность решения обращения (заявки), ресурсы, привлекаемые для решения обращения (заявки), порядок/процедура действий при решении обращения (заявки) – поле СРО «Приоритет» (см. рисунок 6,)

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

На рисунке 6 приведена форма обращения (заявки) типа «Инцидент» в СРО. Рисунок 6 - Форма обращения (заявки) типа «Инцидент» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуги по решению инцидентов, связанных с работой ППО, заполненную в свободной форме

Приложение Д Форма Протокола проверки результатов организационно-штатных и подготовительных мероприятий (шаблон) Протокол проверки результатов организационно-штатных и подготовительных мероприятий Настоящий Протокол содержит результаты проверки организационно-штатных и подготовительных мероприятий, проведенных Исполнителем (Таблица Д.1). Таблица Д.1. Протокол проверки результатов № Мероприятия Подготовительного этапа Результат проверки 1. Определить и направить Заказчику документ «Ответственные за взаимодействия в рамках выполнения работ по техническому сопровождению Системы со стороны Исполнителя». Документ содержит контактную информацию (ФИО, должность, адрес электронной рабочей почты, номер телефона) не менее чем о 2 лицах, ответственных за оказание услуг со стороны Подрядчика Выполнено/Не выполнено 2. Обеспечить подключение специалистов Подрядчика к Системе Выполнено/Не выполнено 3. Обеспечить подключение специалистов Подрядчика к СРО Выполнено/Не выполнено Заказчик Подрядчик /Должность/ /Должность/ ____________________ /Ф.И.О/ ___________________ /Ф.И.О/ М.П. М.П. «_____»_______________________202_г. «_____»_______________________202_г

- 62.01.11.000 - Этап№6: Опытная эксплуатация (1 очередь) ОКПД2: 62.01.11.000 ОПРЕДЕЛЕНИЯ, ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ Модуль iМинтранс Модуль сбора данных и представления показателей деятельности Министерства транспорта Российской Федерации iМинтранс АСУ ТК Модуль СЦ Модуль сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК НС Нештатная ситуация НСИ Нормативно-справочная информация ОТИ Объект транспортной инфраструктуры П-ГИС Геоинформационная подсистема П-ИВ Подсистема информационного взаимодействия П-НСИ Подсистема ведения нормативно-справочной информации и метаданных ПО Программное обеспечение Подрядчик, Исполнитель Организация, с которой будет заключен контракт на выполнение работ по развитию Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК П-СД Подсистема сбора данных Работы Работы по развитию Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК СЗИ Средство защиты информации СМЭВ Система межведомственного электронного взаимодействия СУБД Система управления базами данных ТЗ Техническое задание (настоящий документ) ТС Транспортное средство ТК Транспортный комплекс Учреждение Учреждения в области информационной безопасности ... 1. ОБЩИЕ СВЕДЕНИЯ 1.1. Наименование Системы Полное наименование системы: Информационно-аналитическая система регулирования на транспорте. Условное обозначение системы: АСУ ТК. Полное наименование модуля: Модуль сбора, ведения и анализа информации о нештатных ситуациях на транспорте. Условное обозначение модуля: Модуль СЦ. Модуль СЦ создан в рамках контракта от 05.08.2024 № ОК/24_04 на выполнение работ по развитию АСУ ТК в части создания модуля «Сбора, ведения и анализа информации о нештатных ситуациях на транспорте». Развитие Модуля СЦ осуществлено в рамках контракта от 19.05.2025 № ОК/25_09 на выполнение работ по развитию Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК ... 2. ЦЕЛИ И НАЗНАЧЕНИЕ ВЫПОЛНЕНИЯ РАБОТ 2.1. Назначение АСУ ТК АСУ ТК предназначена для автоматизации и информационно-аналитического обеспечения процессов управления развитием транспортного комплекса Российской Федерации, обеспечения публичности деятельности органов государственного управления транспортным комплексом. Основными целями АСУ ТК являются: – повышение эффективности процессов управления функционированием и развитием транспортного комплекса на основе создания единой информационной среды и комплекса информационно-аналитических услуг на уровне органов государственного управления ТК; – повышение уровня безопасности ТК на базе получения полной, достоверной и оперативной информации о происходящих изменениях, своевременного выявления негативных тенденций и для принятия соответствующих мер по их устранению и ликвидации последствий ... - Условная единица - 1,00 - 2 024 974,30 - 2 024 974,30

- Наименование характеристики Значение характеристики Единица измерения характеристики Инструкция по заполнению характеристик в заявке ОПРЕДЕЛЕНИЯ, ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ Модуль iМинтранс Модуль сбора данных и представления показателей деятельности Министерства транспорта Российской Федерации iМинтранс АСУ ТК Модуль СЦ Модуль сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК НС Нештатная ситуация НСИ Нормативно-справочная информация ОТИ Объект транспортной инфраструктуры П-ГИС Геоинформационная подсистема П-ИВ Подсистема информационного взаимодействия П-НСИ Подсистема ведения нормативно-справочной информации и метаданных ПО Программное обеспечение Подрядчик, Исполнитель Организация, с которой будет заключен контракт на выполнение работ по развитию Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК П-СД Подсистема сбора данных Работы Работы по развитию Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК СЗИ Средство защиты информации СМЭВ Система межведомственного электронного взаимодействия СУБД Система управления базами данных ТЗ Техническое задание (настоящий документ) ТС Транспортное средство ТК Транспортный комплекс Учреждение Учреждения в области информационной безопасности Значение характеристики не может изменяться участником закупки ФГБУ «СИЦ Минтранса России» Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации», Заказчик Федеральный закон № 44-ФЗ Федеральный закон от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» ФЗ Функциональная задача ФЗ «Реестр объектов» Функциональная задача «Формирование и ведение единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации» ФСБ России Федеральная служба безопасности Российской Федерации ФСТЭК России Федеральная служба по техническому и экспортному контролю ЧС Чрезвычайная ситуация ЭВМ Электронно-вычислительная машина API От англ. Application Programming Interface – интерфейс прикладного программирования – совокупность инструментов и функций в виде интерфейса для взаимодействия с программой CSS От англ. Cascading Style Sheets — каскадные таблицы стилей FPS От англ. frame per second - количество кадров в секунду HTML От англ. HyperText Markup Language - стандартный язык разметки документов, создающий основу и структуру всех веб-страниц JSON От англ. JavaScript Object Notation – текстовый формат обмена данными, основанный на JavaScript WebAssembly (Wasm) Открытый стандарт, представляющий собой низкоуровневый бинарный формат инструкций, который позволяет выполнять код, написанный на языках C++, Rust или Go, в браузерах с производительностью, близкой к нативной Автоматизированная система (АС) Система, состоящая из комплекса средств автоматизации, реализующего информационную технологию выполнения установленных функций, и персонала, обеспечивающего его функционирование (ГОСТ Р 59853-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения») АРМ Автоматизированное рабочее место АСУ ТК, Система Информационно-аналитическая система регулирования на транспорте АТС Автоматическая телефонная станция БД База данных ГИС Государственная информационная система ГОСТ Государственный стандарт ГЦОД СИЦ Минтранса России, ГЦОД Головной центр обработки данных ФГБУ «СИЦ Минтранса России» Дашборд Интерактивная аналитическая панель, графический интерфейс. ЕИС Единая информационная система в сфере закупок ЕСИА Единая система идентификации и аутентификации Заказчик Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» КИИ Критическая информационная инфраструктура Кластер Кла?стер (англ. cluster) – объединение нескольких однородных элементов, которое может рассматриваться как самостоятельная единица, обладающая определёнными свойствами Компонент Часть АС, выделенная по определенному признаку или совокупности признаков и рассматриваемая как единое целое (ГОСТ Р 59853-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения») Контракт Контракт на выполнение работ по развитию и оказанию услуг по технической поддержке Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК в 2026 году, заключаемый по результатам проведения конкурентной процедуры закупки в соответствии с требованиями Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» 1. ОБЩИЕ СВЕДЕНИЯ 1.1. Наименование Системы Полное наименование системы: Информационно-аналитическая система регулирования на транспорте. Условное обозначение системы: АСУ ТК. Полное наименование модуля: Модуль сбора, ведения и анализа информации о нештатных ситуациях на транспорте. Условное обозначение модуля: Модуль СЦ. Модуль СЦ создан в рамках контракта от 05.08.2024 № ОК/24_04 на выполнение работ по развитию АСУ ТК в части создания модуля «Сбора, ведения и анализа информации о нештатных ситуациях на транспорте». Развитие Модуля СЦ осуществлено в рамках контракта от 19.05.2025 № ОК/25_09 на выполнение работ по развитию Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК Значение характеристики не может изменяться участником закупки – ГОСТ Р 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.7. Сроки начала и окончания работ Начало работ: с даты заключения Контракта. Окончание работ: не позднее 15.12.2026. Работы выполняются в соответствии с этапами. Сроки выполнения этапов работ по развитию и технической поддержке Модуля СЦ определяются Календарным планом. Календарный план, приведен в разделе 5 настоящего ТЗ 1.2. Шифр темы или номер контракта Присваивается Заказчиком по результатам организации закупочных процедур. 1.2.1. Предмет контракта Выполнение работ по развитию Модуля СЦ. Код по ОКПД2: 62.01.11.000 – услуги по проектированию и разработке информационных технологий для прикладных задач и тестированию программного обеспечения. Оказание услуг по технической поддержке Модуля СЦ. Код по ОКПД2: 62.02.30.000 – услуги по технической поддержке информационных технологий. Выполнение работ по развитию Модуля СЦ предусмотрено с учетом ключевых результатов (ОКР) Ведомственной программы цифровой трансформации Минтранса России на 2026-2028 (далее - ВПЦТ Минтранса России) в составе мероприятия № 103.002 «АСУ ТК» ИТ расхода 103.26.000005 «Развитие Информационно-аналитической системы регулирования на транспорте (АСУ ТК)»: · «Обеспечено информационное взаимодействие с Минобороны о происшествиях на транспортных объектах»; · «Обеспечена автоматизация формирования отчетов о нештатных ситуациях на транспорте, в том числе по данным внешних систем». Выполнение работ по технической поддержке АСУ ТК предусмотрено ВПЦТ Минтранса России в составе мероприятия № 103.002 «АСУ ТК» ИТ расхода 103.26.000021 «Эксплуатация Информационно-аналитической системы регулирования на транспорте (АСУ ТК)» 1.3. Заказчик Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» (ФГБУ «СИЦ Минтранса России»). Адрес: 107078, Москва, Садовая-Спасская ул., д.18, стр. 1. Оператором Системы является Заказчик - Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» (ФГБУ «СИЦ Минтранса России) 1.4. Подрядчик Определяется по результатам проведения конкурентной процедуры закупки в соответствии с требованиями Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (далее – Федеральный закон № 44-ФЗ) 1.5. Основания для выполнения работ Работы осуществляются на основании следующих документов: – постановление Правительства Российской Федерации от 30.12.2003 № 794 «О единой государственной системе предупреждения и ликвидации чрезвычайных ситуаций»; – постановление Правительства Российской Федерации от 08.11.2013 № 1007 «О силах и средствах единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций»; – распоряжение Правительства Российской Федерации от 27.11.2021 № 3363-р «О Транспортной стратегии Российской Федерации до 2030 года с прогнозом на период до 2035 года»; – Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 26.08.2025 №ЕФ-3; – Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 27.11.2025 №ЕФ-23; 1.8. Общие сведения об источниках и порядке финансирования работ Источником финансирования являются средства субсидии федерального бюджета Российской Федерации, предоставленной в соответствии с абзацем вторым пункта 1 статьи 78.1 Бюджетного кодекса Российской Федерации (код цели 08-01) 1.9. Порядок оформления и предъявления результатов работ Подрядчик должен передать Заказчику результаты работ в порядке, определенном Контрактом в сроки, установленные п. 5 настоящего ТЗ, в соответствии с Календарным планом 1.10. Место выполнения Работ Работы выполняются удаленно на комплексе технических средств Заказчика. Адрес размещения комплекса технических средств Заказчика: Московская обл., Богородский район, пос. Горбуша, Радиоцентр. Техническая возможность удаленного подключения обеспечивается Заказчиком (в части предоставления параметров доступа). Оплата телематических и иных услуг, технических и программных средств, необходимых Подрядчику для удаленного подключения и для выполнения требований по информационной безопасности, осуществляется Подрядчиком самостоятельно за свой счет – Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 19.02.2026 №ЕФ-1; – План мероприятий по профилактике случаев непроизводственного травматизма граждан на железнодорожном транспорте, являющийся приложением к постановлению коллегии Министерства транспорта Российской Федерации от 11.03.2026 № 2 1.6. Перечень документов, требования которых должны быть учтены при выполнении работ – Федеральный закон Российской Федерации от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации»; – Федеральный закон Российской Федерации от 27.07.2006 № 152-ФЗ «О персональных данных»; – Федеральный закон Российской Федерации от 06.04.2011 № 63-ФЗ «Об электронной подписи»; – Федеральный закон Российской Федерации от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации»; – Указ Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации»; – Указ Президента Российской Федерации от 01.05.2022 № 250 «О дополнительных мерах по обеспечению информационной безопасности Российской Федерации»; – Указ Президента Российской Федерации от 31.03.2010 № 403 «О создании комплексной системы обеспечения безопасности населения на транспорте»; – постановление Правительства Российской Федерации от 30.07.2004 № 395 «Об утверждении Положения о Министерстве транспорта Российской Федерации»; – постановление Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации»; – постановление Правительства Российской Федерации от 16.11.2015 № 1236 «Об установлении запрета на допуск программного обеспечения, происходящего из иностранных государств, для целей осуществления закупок для обеспечения государственных и муниципальных нужд»; – постановление Правительства Российской Федерации от 23.12.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 Федерального закона «Об электронной подписи»; – постановление Правительства Российской Федерации от 08.06.2011 № 451 «Об инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг и исполнения государственных и муниципальных функций в электронной форме»; – постановление Правительства Российской Федерации от 30.01.2013 № 62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин»; – приказ ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации»; – приказ ФСТЭК России от 11.04.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений»; – приказ ФСБ России от 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 «Национальный стандарт Российской Федерации. Интеллектуальная собственность. Патентные исследования. Содержание и порядок проведения»; 2. ЦЕЛИ И НАЗНАЧЕНИЕ ВЫПОЛНЕНИЯ РАБОТ 2.1. Назначение АСУ ТК АСУ ТК предназначена для автоматизации и информационно-аналитического обеспечения процессов управления развитием транспортного комплекса Российской Федерации, обеспечения публичности деятельности органов государственного управления транспортным комплексом. Основными целями АСУ ТК являются: – повышение эффективности процессов управления функционированием и развитием транспортного комплекса на основе создания единой информационной среды и комплекса информационно-аналитических услуг на уровне органов государственного управления ТК; – повышение уровня безопасности ТК на базе получения полной, достоверной и оперативной информации о происходящих изменениях, своевременного выявления негативных тенденций и для принятия соответствующих мер по их устранению и ликвидации последствий Значение характеристики не может изменяться участником закупки Основными задачами АСУ ТК являются: – автоматизация процессов прогнозирования развития транспортного комплекса и поддержки принятия управленческих решений; – автоматизация процессов мониторинга безопасности и устойчивости транспортного комплекса, управления в чрезвычайных и нештатных ситуациях; – автоматизация процессов управления программами и проектами развития и модернизации транспортного комплекса; – автоматизация процессов мониторинга состояния транспортного комплекса, в том числе с использованием набора ключевых показателей эффективности деятельности транспортного комплекса; – информационно-технологическая поддержка взаимодействия субъектов транспортного комплекса Российской Федерации, органов государственного управления и контроля, международных организаций на основе создания единой технологической среды взаимодействия и управления движением данных (и связанных с ними документов) в транспортном комплексе; – использование в процессах управления транспортным комплексом РФ современных технологий электронного документооборота и электронного обмена данными; – организация межведомственного электронного взаимодействия подразделений Министерства транспорта Российской Федерации, подведомственных агентств и службы с другими организациями 2.2. Назначение и цели развития и технической поддержки Модуля СЦ Назначение Модуля СЦ: – оперативный мониторинг нештатных и чрезвычайных ситуаций на транспорте ; – оповещение заинтересованных лиц и структур о нештатных и чрезвычайных ситуациях; – сбор, обработка и хранение данных о нештатных и чрезвычайных ситуациях. Целями развития Модуля СЦ являются: – расширение состава данных об оперативной обстановке на транспорте; – оптимизация процесса сбора данных об оперативной обстановке на транспорте; – повышение информированности пользователей за счет визуализация данных Модуля СЦ; – автоматизация процесса формирования отчетов о ЧС и нештатной ситуации на транспорте; – обеспечение информационного взаимодействия с заинтересованными организациями по вопросам ведения. Целями оказания услуг по технической поддержке являются: – обеспечение информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы; – поддержание параметров функционирования ППО Системы, удовлетворяющих требованиям производственных процессов, включая их непрерывность; – обеспечение бесперебойного функционирования ППО и своевременное устранение сбоев и аварийных ситуаций в Системе; – своевременное устранение уязвимостей при выявлении таковых, в соответствии с требованиями к обеспечению информационной безопасности; – адаптация, конфигурирование, коррекция программного обеспечения в соответствии с изменениями нормативно-правовой базы и запросами уполномоченных сотрудников органов государственной власти, включая выполнение процедур тестирования и участие в обновлениях ППО на стендах Заказчика; – обеспечение сохранения работоспособности ППО в изменяемой среде эксплуатации; – ведение документации по настоящему ТЗ, инициирование и актуализация документации на Систему по результатам обработки запросов Заказчика и внесении соответствующих изменений в ППО. Модуль СЦ применяется в деятельности Министерства транспорта Российской Федерации, подведомственных агентств и службы и другими организациями в соответствии с соглашениями об информационном обмене 3. ХАРАКТЕРИСТИКА ОБЪЕКТА АВТОМАТИЗАЦИИ 3.3. Состав используемого ПО Модуля СЦ Программная архитектура Модуля СЦ разработана как трехуровневая клиент-серверная архитектура. Архитектура включает в себя следующие уровни: • уровень представления – презентационный уровень, обеспечивающий взаимодействие с пользователя с клиентскими приложениями с использованием веб-браузера («тонкий» клиент); • уровень приложений – реализован в виде сервисов, обеспечивает обработку запросов, поступающих от клиентских приложений, формирование ответов на запрос в доступном пользователю виде (формирование пользовательских интерфейсов); • уровень хранения данных – реализуется как сервер БД и обеспечивает хранение и целостность хранимых данных, создание резервных копий, ведение журнала транзакций, восстановление данных после сбоев. Программная архитектура Модуля СЦ включает в себя сервисы и интерфейсы, указанные в Таблице 3. Таблица 3. Программная архитектура Модуля СЦ Программный сервис/интерфейс Технологии реализации Уровень представления Интерфейс пользователя и администратора (front-end) Javascript Уровень приложений Сервис (GateWay) Kotlin Сервис геокодирования (geocoding-service) Kotlin Сервис уведомлений (notifiсation-service) Kotlin Сервис работы с файлами (file-service) Kotlin Сервис отчетности (report-service) Kotlin Сервис управления событиями (event-service) Kotlin Сервис информирования через мессенджер (messenger-notifier) Python Сервис внешних интеграций (integration-service) Сбор информации из внешних систем и сервисов Брокер сообщений Kafka Уровень хранения данных Файловое хранилище MinIO S3 СУБД Postgres Pro Enterprise Значение характеристики не может изменяться участником закупки 3.4. Информационное взаимодействие программных сервисов и интерфейсов Модуля СЦ Объект автоматизации функционирует в распределенной информационной среде. Обмен данными осуществляется по защищенным каналам связи (в том числе ведомственным сетям передачи данных). Источники информации включают: · внешние автоматизированные системы (органов государственной власти); · внутренние базы данных (реестры объектов транспортной инфраструктуры, паспорта регионов и пр.); · оперативная информация от персонала, поступающая через автоматизированные рабочие места (АРМ) и мобильные устройства. 3.4.1. Взаимодействие Модуля СЦ со смежными подсистемами АСУ ТК Модуль СЦ входит в состав АСУ ТК и взаимодействует со следующими ее функциональными задачами и подсистемами: · Функциональной задачей «Формирование и ведение единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации» (ФЗ «Реестр объектов»); · Геоинформационной подсистемой АСУ ТК (П-ГИС); · Подсистемой ведения нормативно-справочной информации и метаданных (П-НСИ); · Подсистемой сбора данных и централизованное хранилище данных (П-СД); · Подсистемой информационного взаимодействия (П-ИВ). 3.4.2. Взаимодействие с внешними информационными системами Список внешних информационных систем, с которыми осуществляется взаимодействие Модуля СЦ: · ЕСИА; · мессенджер; · Яндекс Геокодер; · Информационная система «Централизованная система сбора информации систем-112»; · ПВК «Поиск-Море», АИС РПТ; · облачная АТС 3.5. Требования к эксплуатации Применяемое в Системе программное обеспечение, программно-аппаратные и аппаратные комплексы должны соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации» 3.1. Описание объекта автоматизации АСУ ТК Объектом автоматизации являются процессы основной и обеспечивающей деятельности, направленные на управление транспортным комплексом, в том числе, процессы информационного взаимодействия с другими организациями и субъектами транспортного комплекса. АСУ ТК относится к государственным информационным системам, а также к информационным системам персональных данных и значимым объектам критической информационной инфраструктуры Российской Федерации. АСУ ТК соответствует требованиям, предъявляемым к: – ГИС второго класса защищенности в соответствии с приказом ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах»; – ИС персональных данных при обеспечении третьего уровня защищенности персональных данных в соответствии с требованиями постановления Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»; – значимым объектам КИИ Российской Федерации второй категории значимости с постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении Правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений». Модуль СЦ является подсистемой АСУ ТК. Перечень платформенных решений и функциональных задач АСУ ТК представлен в Таблице 1 Таблица 1 – Перечень платформенных решений и функциональных задач АСУ ТК № Наименование подсистемы/ функциональной задачи/ модуля Назначение 1 Подсистема сбора данных и централизованного хранилища данных Подсистема обеспечивает выполнение сбора данных в АСУ ТК, и в т. ч., в рамках функциональных задач «Формирование и ведение межрегионального транспортного баланса пассажирских перевозок в дальнем (межрегиональном) сообщении» и «Формирование и ведение транспортного паспорта региона» 2 Подсистема информационного взаимодействия Подсистема информационного предназначена для обеспечения информационного взаимодействия подсистем АСУ ТК, а также, взаимодействия АСУ ТК с АС федеральных органов исполнительной власти 3 Подсистема ведения нормативно-справочной информации и метаданных Подсистема предназначена для автоматизации функций формирования и актуализации справочников, классификаторов, реестров и регистров, необходимых для обеспечения информационной поддержки пользователей НСИ и интеграции подсистем АСУ ТК в части применения НСИ 4 Модуль СМЭВ Модуль взаимодействия со СМЭВ представляет собой набор сервисов взаимодействия: сервис синхронного взаимодействия и сервис отправки, осуществляющих дополнительную обработку сообщений, отправляемых в СМЭВ и принимаемых из СМЭВ 5 Геоинформационная подсистема Программное обеспечение геоинформационной подсистемы предназначено для обеспечения смежных подсистем АСУ ТК возможностью работы с картографической информацией, в том числе, отображения на электронных картах объектов транспортной инфраструктуры и получения информации о местоположении, характеристиках контролируемых транспортных объектов 6 Подсистема информационного портала АСУ ТК Подсистема информационного портала предназначена для отображения и входа в функциональные задачи АСУ ТК 7 Подсистема технического портала АСУ ТК Подсистема технического портала АСУ ТК предназначена для управления заявками пользователей и технологического документооборота заявок 8 Подсистема проектного архива АСУ ТК Подсистема проектного архива АСУ ТК предназначена для автоматизации деловых процессов должностных лиц Министерства транспорта Российской Федерации, подведомственных агентств и службы, в том числе, и процессов информационного взаимодействия внутреннего и внешнего характера 9 ФЗ «Реестр объектов» Функциональная задача предназначена для формирования и ведения единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации 10 ФЗ «СТП» Функциональная задача предназначена для организации информационно-аналитической поддержки процессов территориального планирования Российской Федерации в области федерального транспорта 11 ФЗ «МРТБ ПП» Функциональная задача предназначена для формирования и ведения межрегионального транспортного баланса пассажирских перевозок в дальнем (межрегиональном) сообщении 12 ФЗ «МДД» Функциональная задача предназначена для осуществления мониторинга дорожного движения 13 ФЗ «ТПР» Функциональная задача предназначена для формирования и ведения транспортного паспорта региона 14 ФЗ «Данные по грузообороту» Функциональная задача предназначена для обеспечения подсистем и пользователей АСУ ТК данными по грузообороту между Российской Федерацией и зарубежными странами 15 ФЗ «МЖТ» Функциональная задача предназначена для осуществления мониторинга железнодорожного транспорта 16 ФЗ «МГМП» Функциональная задача предназначена для осуществления мониторинга грузопотоков в морских портах с целью формирования единой цифровой среды мониторинга и планирования перевозок в/из портов Дальнего Востока 17 Модуль ГЭТ Модуль предназначен для получения, хранения данных инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по отдельно взятому предприятию-перевозчику. Формирования отчетов об инвентаризации с детальными данными по каждому разделу инвентаризации с маршрутизацией в муниципалитет / регион / Минтранс. Содержит агрегированные данные инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по всем перевозчикам, относящихся к данному муниципалитету. Формирует сводный отчет по муниципалитету по каждому разделу инвентаризации с маршрутизацией в регион / Минтранс. Формирует агрегированные данные инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по всем перевозчикам, относящиеся к данному региону и по всем муниципалитетам, относящимся к данному региону. Аналитические и статистические данные о состоянии ГЭТ региона. Содержит данные о видах транспорта, цифровых транспортных сервисах и платежных инструментах Региона. Формирует сводный отчет по каждому разделу инвентаризации с маршрутизацией в Минтранс. Формирует агрегированную статистику и аналитику по всем регионам страны в разрезе транспортных средств, маршрутов, пассажиропотоков, инфраструктуры ГЭТ. Данные о рейтинге регионов и перевозчиков на основании выбранных параметров, документооборот с участниками Системы: получение подписанных печатных форм, их утверждение, возврат на доработку. 18 Модуль iМинтранс Модуль создан для отчета по ключевым показателям транспортного комплекса России (Отраслевые и статистические показатели, исполнение бюджета, исполнение поручений, аналитика СМИ, происшествия по видам транспорта). 19 Модуль СЦ Модуль СЦ предназначен для оперативного мониторинга нештатных ситуаций транспортной отрасли, оповещения заинтересованных лиц и структур и предоставления данных о нештатных ситуациях АСУ ТК осуществляет идентификацию и авторизацию посредством Единой системы идентификации и аутентификации (ЕСИА). Информационный обмен с внешними информационными системами осуществляется посредством СМЭВ 3 и СМЭВ 4. АСУ ТК развернута на вычислительных мощностях ГЦОД СИЦ Минтранса России 3.2. Описание и текущее состояние объекта автоматизации Модуля СЦ Объектом автоматизации является процесс организации мониторинга информации о НС и ЧС на транспорте. Предметом деятельности Учреждения являются следующие функции: – информационное обеспечение в области транспортной безопасности, защиты населения и территорий от чрезвычайных ситуаций природного и техногенного характера в транспортном комплексе; – подготовка справочных материалов при угрозе возникновения и возникновении чрезвычайных ситуаций и иных происшествий в транспортном комплексе; – взаимодействие и обмен оперативной информацией с органами управления Единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций; – организация оперативного мониторинга обстановки на объектах транспорта при угрозе и возникновении чрезвычайных ситуаций и иных происшествий. Перечень компонентов Модуля СЦ и выполняемые ими функции представлены в Таблице 2 Таблица 2. Перечень компонентов Модуля СЦ и их функции № п/п Компонент Выполняемые функции 1 Регистрация событий – ведение карточки события; – удаление комментария; – динамическое отображение существующих событий в заданном радиусе и за заданный период; – возможность автоматической проверки вводимых данных в части количества пострадавших; – отображение карточки ОТИ, ТС в соответствии с ФЗ Реестр объектов; – сохранение и отображение версии карточки события; – привязка события к координатам по картографической основе; – указание признака выполнения действия по отработке события; – перевод статуса события; – закрытие карточки события; – публикация информации о событии в канале мессенджера; – возможность перехода из карточки события на картографическую основу для просмотра местоположения события 2 Визуализация – отображение событий на картографической основе в виде пиктограмм; – масштабирование карты; – отображение краткой карточки события при выборе события на картографической основе; – отображение списка событий; – отображение карточки события; – отображение журнала действий пользователя; – отображение дополнительной информации (текстовая информация и приложенные файлы); – отображение справки о событиях и отчета о событиях; – отображение фильтров и количества отфильтрованных объектов; – отображение результатов поиска; – отображение статистики по событиям на экране; – возможность создания события с картографической основы; – отображения картографических слоев в зависимости от примененных фильтров; – возможность настройки шага картографической сети; – возможность настройки географической точки центра карты; – отображение количества непрочитанных сообщений; – возможность перехода к детальной карточке события из краткой карточки события при выборе события на картографической основе 3 Информирование – ведение справочника способов оповещения (веб-интерфейс, мессенджер); – формирование сценария выполнения оповещения (настройка условий, способа, параметров оповещения); – выполнение оповещений пользователей 4 Отчетность – формирование отчета и справки о событиях; – фильтрация событий для выгрузки в справку о событиях или в отчет о событиях 5 Администрирование – ведение ролей пользователей; – ведение учетных данных пользователей; – ведение справочника организаций; – ведение справочника групп системы мгновенного обмена сообщениями; – выполнение исходящего звонка на контактный телефонный номер организации; – формирование матрицы эскалации событий Архитектура Модуля СЦ представлена на рисунке 1. Рисунок 1. Архитектура Модуля СЦ 4. ТРЕБОВАНИЯ К МОДУЛЮ СЦ 4.2.6. Взаимосвязи с внешними автоматизированными системами (1 очередь) Способы взаимодействия с внешними информационными системами должны быть определены на этапе технического проектирования. Должны быть выполнены следующие доработки: – интеграции с информационными ресурсами в целях получения данных о движении подвижных ТС (воздушные суда, суда водного транспорта); – интеграция с информационным ресурсом в целях получения данных о событиях на железнодорожном транспорте. Реализация интеграций должна включать проектирование и реализацию интеграционных механизмов обмена данными с учетом доступных вариантов реализации, обеспечение защищенных способов взаимодействия, настройку отображения отдельных данных на карте (настройка слоев). Взаимодействия, имеющие каналы связи, выходящие за пределы контролируемой зоны взаимодействующих систем, считаются защищенными, если для их защиты используются программные и/или программно-аппаратные шифровальные (криптографические) средства, сертифицированные ФСБ России (далее – СКЗИ). Выбор СКЗИ, схемы подключения и требуемого класса криптостойкости должен производиться в соответствии с Техническими условиями на подключение к информационным ресурсам ФГБУ «СИЦ Минтранса России» и инструкциями по подключению пользователей к ресурсам инфраструктуры Головного центра обработки данных, утвержденных приказом директора ФБГУ «СИЦ Минтранса России» от 24.05.2024 № 21-ОД Значение характеристики не может изменяться участником закупки 4.3. Требования к оказанию услуг по технической поддержке Модуля СЦ 4.3.1. Общие требования к оказанию Услуг Техническая поддержка Модуля СЦ должна осуществляться с учетом требований постановления Правительства Российской Федерации от 06.07.2015 N 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации». Подрядчик обязан выполнять требования законодательства в сфере защиты информации, требования по защите информации, информационной безопасности, указанные в локальных нормативных актах ФГБУ «СИЦ Минтранса России», регламентирующих условия информационного взаимодействия, защиты информации и подключения к информационным ресурсам ФГБУ «СИЦ Минтранса России», участвующих в информационном взаимодействии в рамках оказания услуг по технической поддержке АСУ ТК в 2026 году 4.3.1.1. Требования к составу и содержанию услуг третьего уровня технической поддержки Оказание услуг по технической поддержке Системы осуществляется в рамках этапов в соответствии с календарным планом. Подрядчик в течение 5 рабочих дней с даты заключения Контракта должен предоставить со своей стороны, а Заказчик со своей стороны Матрицу ответственных за взаимодействия в соответствии с Приложением 1 к Регламенту оказания услуг по третьему уровню технической поддержки Модуля СЦ (далее – Регламент, Приложение В). Подрядчик в течение 10 рабочих дней с даты заключения Контракта должен провести мероприятия по организации третьего уровня технической поддержки в соответствии с Регламентом. Услуги по третьему уровню технической поддержки Модуля СЦ должны включать: – организацию Подрядчиком третьего уровня технической поддержки; – информационно-консультационную поддержку работников Заказчика; – решение инцидентов, связанных с работой ППО; – адаптационное, конфигурационное и коррекционное сопровождение Модуля СЦ (в рамках действующих программных модулей и функциональности); – устранение уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности Таблица 6. Категории обращений и заявок Категория Примеры Запрос на обслуживание Подготовка SQL запроса к СУБД для решения прикладной задачи и д.р. – запрос на любое действие, не являющееся запросом информации и несовершенный на основе происшествия, прямо или косвенно влияющего на работу Модуля СЦ Консультация «Где взять / куда обратиться...?», «Как сделать / выполнить…», «Как это работает…?» - запрос, имеющий своей целью получение информационной поддержки Инцидент Разбор ошибок/сбоев и подготовка материалов (корректировочных релизов, инструкций) для Заказчика для устранения ошибок/сбоев, которые приводят к частичному и полному нарушению работоспособности всех или отдельных функций ППО. Подготовка изменения и материалов, необходимых для проведения аварийно-восстановительных работ для возобновления работоспособности Модуля СЦ ЗНИ Подготовка изменений, связанных с изменением, улучшением/оптимизацией Модуля СЦ и выводом новой модифицированной функциональности в штатном режиме. Подготовка изменений, связанных с модификацией существующих и/или реализация новых интеграционных механизмов для получения/обработки данных внешних систем. Подготовка изменений графического интерфейса по требованиям Заказчика. Перечень статусов обращений (заявок) приведен в пункте 3.3. Регламента оказания Услуг. Назначение обращению (заявке) статуса «Закрыто» осуществляется Заказчиком только после получения от инициатора обращения (заявки) подтверждения о его исполнении или нахождения обращения (заявки) в статусе «Выполнено» и отсутствия повторных вопросов/запросов по данному обращению (заявки) в течение 5 рабочих дней. Категории и статусы обращений (заявок) могут быть скорректированы в процессе оказания услуг исключительно по согласованию с Заказчиком 4.3.6. Требования к услугам технической поддержки 4.3.6.1. Требования к организации третьего уровня технической поддержки Основными задачами организации третьего уровня технической поддержки в рамках оказания услуг по технической поддержке Модуля СЦ являются организация эксплуатационной службы Подрядчика, проверка готовности технических и программных средств для обеспечения непрерывного функционирования ППО Модуля СЦ. Подрядчиком должны быть проведены организационно-штатные и подготовительные мероприятия (в т. ч. технические) в рамках организации технической поддержки Модуля СЦ. Подрядчик в течение 5 (пяти) рабочих дней с даты заключения Контракта должен: – определить и направить Заказчику документ «Перечень уполномоченных специалистов», содержащий контактную информацию (ФИО, должность, адрес рабочей электронной почты) лиц, ответственных за оказание услуг со стороны Подрядчика; – обеспечить подключение специалистов Подрядчика к Системе регистрации обращений (заявок) (СРО предоставляется Заказчиком) для оказания услуг; – согласовать с Заказчиком способ доступа Подрядчика к Модулю СЦ. Результат выполнения мероприятий фиксируется в Протоколе проверки результатов организационно-штатных и подготовительных мероприятий (см. Приложение Д к настоящему ТЗ) 4.1. Требования к структуре Модуля СЦ В процессе работ по развитию Системы должны сохраниться основные требования к построению архитектуры Системы в соответствии с принципами трехуровневой архитектуры: 1. уровень хранения данных или уровень базы данных (сервер СУБД); 2. уровень сервера приложений (сервер аналитической обработки); 3. презентационный уровень, обеспечивающий взаимодействие с клиентскими приложениями. В состав Системы должны входить следующие основные компоненты: 4. сервер баз данных; 5. сервер приложений; 6. веб-сервер. Сервер баз данных должен обеспечивать хранение и целостность хранимых данных, создание резервных копий, ведение журнала транзакций, восстановление данных после сбоев. Сервер приложений должен обеспечивать обработку запросов, поступающих от клиентских приложений (через веб-сервер), формирование ответов на запрос в доступном пользователю виде (формирование пользовательских интерфейсов). Веб-сервер должен обеспечивать взаимодействие с оператором и внешними системами по HTTP / HTTPS протоколу в режиме «запрос-ответ» (получения запросов от пользователя и передачи ответа в виде соответствующей информации, обработанной серверами приложений). Взаимодействие Системы с пользователем должно отвечать требованиям модели «тонкого клиента» (т.е. представлять на стороне клиента (пользователя) лишь графический пользовательский интерфейс). Все составляющие Системы должны использовать единую методологию и отвечать единым принципам взаимодействия, надежности и управления. Перечень компонентов Модуля СЦ представлен в Таблице 4. Таблица 4. Перечень компонентов Модуля СЦ, в отношении которых выполняются работы по развитию № п.п. Наименование компонента Модуля СЦ Раздел ТЗ 1 Компонент регистрации событий 4.2.1. 2 Компонент отчетности 4.2.2 3 Компонент визуализации 4.2.3 4 «Интерактивная карта» (компонент создается) 4.2.4 5 Компонент администрирования 4.2.5 4.2. Требования к дорабатываемым функциям модуля СЦ 4.2.1. Развитие компонента регистрации событий (1 очередь) Должны быть выполнены следующие доработки: – обеспечение логирования действий пользователя, связанных с карточкой события; – доработка объектной модели в части создания новых типов сущностей (карточек) с учетом реализуемых интеграций с информационными ресурсами (силы и средства предупреждения и ликвидации ЧС и нештатных ситуаций на транспорте, ТС, ограничения воздушного пространства, неблагоприятные и опасные природные явления); – реализация механизма установления связи между сущностями в Модуле СЦ автоматизированным и ручным способами (события, природные явления, силы и средства предупреждения и ликвидации ЧС и нештатных ситуаций на транспорте, ограничения воздушного пространства, ОТИ, ТС и др.); – отображение в карточке установленных связей между сущностями. 4.3.1.2. Требования к общему порядку оказания услуг Техническая поддержка Модуля СЦ должна быть организована на трех уровнях: – первый и второй уровни технической поддержки организуется Заказчиком; – третий уровень технической поддержки организуется Подрядчиком. Перечень действий на каждом уровне технической поддержки указан в Таблице 5: Таблица 5 – Перечень действий на каждом уровне технической поддержки Уровень технической поддержки Доступные действия Условия передачи задачи на следующий уровень Первый уровень технической поддержки (далее – 1-й уровень) – принимает обращения (заявки) пользователей Модуля СЦ и работников Заказчика; – регистрирует обращения в Модуле СЦ регистрации обращений; – присваивает уникальный идентификационный номер, классифицирует обращения; – самостоятельно решает обращения, которые связаны с недостаточной квалификацией пользователей или настройками в рамках своей компетенции; – взаимодействует с пользователями Модуля СЦ при решении проблемы Передает обращение на второй уровень поддержки в случае невозможности решения на своем уровне Второй уровень технической поддержки (далее – 2-й уровень) – принимает обращения от 1-го уровня; – уточняет классификацию обращения в результате дополнительного анализа; – самостоятельно решает обращения в рамках своей компетенции; – осуществляет техническую и консультационную поддержку Модуля СЦ; – взаимодействует с сотрудниками 1-го и 3-го уровня и пользователями Модуля СЦ; – формирует заявки для 3-го уровня и контролирует исполнение Передает обращение на третий уровень поддержки в случае невозможности решения на своем уровне Третий уровень технической поддержки (далее – 3-й уровень) – принимает обращения от 2-го уровня; – обеспечивает выполнение требований, предъявляемых Контрактом и настоящим Техническим заданием к Услугам, оказываемым Подрядчиком Все поступающие обращения должны быть исполнены Подрядчиком Для обеспечения взаимодействия с Заказчиком Подрядчик со своей стороны определяет ответственных лиц, уполномоченных в структуре Подрядчика за своевременное и качественное оказание Услуг в рамках настоящего ТЗ, а также контактную информацию ответственных лиц (телефон, электронную почту). Подрядчик должен предоставить Заказчику единый адрес электронной почты для приема обращений (заявок) в течение 3 (трех) рабочих дней после заключения Контракта. Указанный в настоящем пункте адрес электронной почты (способ направления обращений (заявок) применяется в случае сбоя в работе СРО Заказчика. Со своей стороны, Заказчик предоставляет Подрядчику перечень и контактную информацию (телефон, электронную почту) уполномоченных лиц для осуществления взаимодействия с указанием зон ответственности. О любых изменениях в контактной информации ответственных лиц Стороны должны уведомить друг друга в течение 1 (одного) рабочего дня с момента возникновения таких изменений посредством уведомления на электронную почту ответственных лиц и/или в письменной форме. В результате оказания услуг по настоящему ТЗ не должны быть изменены исходные коды, дистрибутивы и иные компоненты Модуля СЦ вне согласованных с Заказчиком изменений. Любые изменения исходных кодов, дистрибутивов и иных компонентов Модуля СЦ должны производиться только после согласования с Заказчиком уполномоченными лицами по электронной почте или иным заранее согласованным способом. Не должна быть ухудшена надежность и производительность Модуля СЦ. Оказание услуг по Контракту не должно нарушать требования к информационной безопасности, описанной в документации на Модуль СЦ 4.3.6.2. Требования к услугам информационно-консультационной поддержки работников Заказчика и пользователей Модуля СЦ Услуги информационно-консультационной поддержки сотрудников Заказчика включают: – обработку обращений и заявок, поступивших от сотрудников Заказчика; – консультирование сотрудников Заказчика и пользователей Модуля СЦ; – актуализацию документации, и других материалов по работе с Модулем СЦ при необходимости. – консультирование и разработку рекомендаций по настройке Модуля СЦ (без изменения программного кода), включая изменение настроек функционирования; – консультации по вопросам использования, настройки и возможностям Модуля СЦ; – консультации по проведению превентивных мер для недопущения аварийных ситуаций в Модуле СЦ; – консультации по предварительной диагностике и локализации возникшей неисправности Модуля СЦ; – консультации по вопросам обеспечения информационной безопасности Модуля СЦ и настройки функций, обеспечивающих корректную работу программного обеспечения для совершения юридически значимых действий в Модуле СЦ; – другие вопросы, связанные с работой Модуля СЦ. 4.3.6.2.1. Требования к порядку оказания услуг информационно-консультационной поддержки работников Заказчика и пользователей Модуля СЦ Подрядчик выполняет консультирование сотрудников Заказчика и пользователей Модуля СЦ. Консультация может быть предоставлена по согласованным с представителем Заказчика каналам коммуникации с регистрацией результата консультации в СРО Подрядчиком. Детальный порядок оказания консультационных услуг определен в Регламенте оказания Услуг 4.3.6.3. Требования к услугам по решению инцидентов, связанных с работой ППО Подрядчик устраняет неисправности Модуля СЦ, связанные с работой ППО, выявленные в рамках оказания услуг согласно настоящему Техническому заданию, при этом в зону ответственности Подрядчика не входит устранение неисправностей, выявленных на стороне Заказчика и на стороне третьих лиц (провайдера связи, поставщика электропитания и т.д.). Первичная диагностика выявленной неисправности проводится на 1 и 2 уровнях технической поддержки и не входит в зону ответственности Подрядчика. Если при проведении первичной диагностики и попытке устранить неисправности на 1 и 2 уровнях технической поддержки, данную неисправность устранить не удалось и в процессе диагностики было выявлено, что проблема связана с работоспособностью ППО, обращение (заявка) назначается сотруднику Подрядчика, ответственному за оказание услуг технической поддержки 3 уровня. Инцидентами вне зоны ответственности Подрядчика являются: – работоспособность функциональности, выходящая за рамки текущей реализации функций в Модуле СЦ и/или являющаяся расширением требований Заказчика к функциям Модуля СЦ; – проведение профилактических и плановых работ, согласованных с Заказчиком; – нарушение работоспособности функций Модуля СЦ, вызванное проведением работ на стороне Заказчика 4.3.6.4.2. Требования к изменению настроек функционирования Изменение настроек функционирования может проводиться в рамках допустимых пределов изменения функционирования, заложенных в архитектуру Модуля СЦ. Изменение настроек функционирования включает в себя изменение данных и справочников, изменение форм документов, формируемых Модулем СЦ, изменение и настройку форматов и версий передачи данных в смежные системы. Доработка программного кода Модуля СЦ может допускаться (в случае необходимости) при выполнении работ по адаптации функций Модуля СЦ в части изменения формата передачи данных в смежные информационные системы при условии соблюдения требований пункта 29.3 приказа ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации» 4.3.6.5. Требования к услугам по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности По запросу Заказчика Подрядчик должен провести работу по приведению ППО в соответствие с требованиями по обеспечению информационной безопасности. Критичность уязвимости оценивается в соответствии в соответствии с Методическим документом ФСТЭК России «Методика оценки уровня критичности уязвимостей программных, программно-аппаратных средств» (утвержден ФСТЭК России 30.06.2025), а также с учетом ГОСТ 56545-2015 и международными стандартами (CVSS 3.0 и выше), и задает необходимый срок устранения. В процессе проведения Заказчиком обследования Модуля СЦ и выявления уязвимостей в ППО, связанных с исходным кодом Модуля СЦ и/или используемыми компонентами (библиотеками), Заказчик направляет Подрядчику обращение (заявку) на устранение, с указанием критичности и срочности принятия мер по устранению в СРО. Подрядчик при оказании услуг по обновлению или устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности должен: – провести анализ уязвимостей и связанных с ними исходным кодом и/или используемыми компонентами (библиотеками); – выработать варианты устранения указанных уязвимостей и согласовать с Заказчиком их реализацию; – своевременно внести изменения в исходный код Модуля СЦ и/или используемые компоненты (библиотеки) и подготовить соответствующее обновление; – провести обновление Модуля СЦ в тестовом контуре Заказчика и проинформировать Заказчика о готовности проведения тестирования; – протестировать успешность обновления или устранения уязвимостей в ППО и корректность функционирования Модуля СЦ на тестовом контуре, совместно с Заказчиком; – при невозможности незамедлительного устранения уязвимости приоритетов «Критический» и «Высокий» Подрядчик обязан предоставить исчерпывающий список причин и согласовать план достаточных компенсирующих мер с ответственными сотрудниками Заказчика. Результат внесения изменений отображается в соответствующей записи в СРО и в составе Отчета об оказанных услугах 4.3.6.5.1. Требования к порядку оказания услуг по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности Подрядчик в соответствии с приоритетами обращений и контрольными сроками исполнения (см. Приложение Б к ТЗ) оценивает техническую возможность и сроки устранения уязвимостей, и реализацию обновления Модуля СЦ. По итогу проведения оценки Подрядчик направляет в заявке СРО Заказчику заключение о возможности устранения уязвимостей и/или обновления в ППО и согласует с Заказчиком проведение данных работ Технические меры по обеспечению надежности должны предусматривать: – резервирование критически важных компонентов и данных Системы и отсутствие единой точки отказа; – использование программного резервирования (программной избыточности); – изменение конфигурации используемых средств и применение специализированного ПО, обеспечивающего высокую надёжность. Организационные меры по обеспечению надежности должны быть направлены на минимизацию ошибок пользователей (а также обслуживающего персонала при эксплуатации и проведении работ по обслуживанию), минимизацию времени ремонта или замены вышедших из строя компонентов за счёт: – обеспечения для обслуживающего персонала требуемого уровня квалификации; – регламентации и нормативного обеспечения выполнения работ обслуживающим персоналом; – своевременной диагностики неисправностей. Расчетное значение коэффициента доступности Модуля СЦ должно составлять не менее 0,95. 4.5.3. Требования по диагностированию Модуля СЦ Диагностирование Модуля СЦ должно осуществляться путем анализа записей в системных журналах СУБД, операционных систем серверов, а также с помощью встроенных средств диагностирования общего программного обеспечения Модуля СЦ. Диагностированию подлежат: – сбои и нарушения функционирования технического обеспечения (серверов) Модуля СЦ; – сбои и нарушения функционирования системного программного обеспечения серверов, используемых для работы Модуля СЦ; – сбои и нарушения функционирования прикладного программного обеспечения серверов, используемых для работы Модуля СЦ; – случаи недоступности (отсутствия ответа) или некорректные ответы внешних систем; – сбои и нарушения функционирования СУБД; – сбои при выполнении регламентных операций резервного копирования. При возникновении аварийных ситуаций либо ошибок в программном обеспечении диагностические инструменты должны позволять сохранять набор информации, необходимой для идентификации и устранения проблемы. Модуль СЦ и ее компоненты должны обеспечивать возможность диагностики своей работоспособности с возможностью интеграции с модулем мониторинга АСУ ТК. Набор передаваемых журналов и метрик должен быть определен на этапе технического проектирования 4.5.4. Требования к надежности Должно быть предусмотрено сохранение работоспособности Модуля СЦ при некорректных действиях пользователя и сохранение целостности данных при нештатном завершении работы Модуля СЦ (отказ рабочей станции, потеря сетевого доступа и т.п.). Модуль СЦ должен предоставлять механизмы обеспечения сохранности данных через применение процедур резервного копирования и восстановления, описанных в документации на Систему. Ключевые показатели надежности информационной системы — допустимое время на восстановление работоспособности Модуля СЦ (RTO - recovery time objective) и/или допустимый интервал времени потери изменений в данных при сбоях/отказах (RPO – recovery point objective) должны быть определены Подрядчиком и согласованы с Заказчиком на этапе технического проектирования Оказание услуг в рамках данного технического задания осуществляется Подрядчиком по обращению (заявке) Заказчика, направляемой посредством СРО Заказчика. Регистрация обращений, поступивших непосредственно в Модуль СЦ регистрации обращений Заказчика, производится сотрудниками Заказчика, которые обеспечивают первый уровень технической поддержки Модуля СЦ. В случае назначения приоритета «Критический» или «Высокий», информация о назначении также дублируется оповещением ответственных представителей Подрядчика посредством звонка на предоставленные номера телефонов. Обращение (заявка) должна содержать следующую информацию: – контакты пользователя/организации; – приоритет обращения, соответствующий Приложению 2 к Регламенту; – время обнаружения; – наименование компонента АСУ ТК - Модуль СЦ; Информация может быть расширена по согласованию с Заказчиком. Обращения (заявки) сотрудников Заказчика должны приниматься Подрядчиком через веб-интерфейс СРО. В процессе обработки обращений (заявок) Подрядчик должен обеспечить выполнение следующих процедур: – прием обращений(заявок) от сотрудников Заказчика; – оказание информационно-консультационной поддержки в соответствии с требованиями настоящего Технического задания; – информирование сотрудников Заказчика о статусе обработки и результатах обработки обращений(заявок). Подрядчик осуществляет обязательную регистрацию и учет всех обращений и заявок, поступивших к Подрядчику от представителей Заказчика в рамках оказания настоящих услуг Примечание: в случае приостановки работы по обращению или заявке (обращение или заявка находится в статусе «Приостановлено»), указываются причины, по которым работы по обращению или заявке приостановлены с указанием перечня действий/информации, запрошенных у инициатора обращения, а также даты, формы и адресата такого запроса. В случае отклонения обращения или заявки (заполняется в случае, если обращению или заявке присваивается статус «Отклонено»), указываются подробно причины такого отклонения, а также фиксируется дата и время перехода в статус «Отклонено». В случае, если обращение или заявка отклонены (отменены) самим Инициатором, то указывается дата и способ, которым от инициатора получено соответствующее уведомление. В случае невыполнения Подрядчиком регламентного времени реагирования или решения обращения (заявки) Заказчик вправе отозвать обращение и направить его Подрядчику повторно. При этом каждое отозванное обращение учитывается в Отчёте об оказанных услугах, как обращение с превышением времени реагирования или решения, но оплате не подлежит. В случае, если обращение (заявка) связано с некачественным выполнением Подрядчиком другой задачи, такое обращение решается в регламентное время, установленное Техническим заданием, при этом оплате такие обращения не подлежат, о чем указывается в Отчете об оказанных услугах в графе «Примечание» Работы по устранению неисправности приостанавливаются (по согласованию с Заказчиком) в следующих случаях: – если Подрядчиком в результате диагностики выявлено, что неисправность находится в зоне ответственности Заказчика. Подрядчик информирует Заказчика о выявленной неисправности в зоне его ответственности по согласованным каналам связи; – требуется действие со стороны Заказчика – до момента выполнения данного действия Заказчика. Заказчик информируется о необходимых действиях по согласованным каналам связи; – отсутствие возможности связаться со специалистами Заказчика, участие которых необходимо для устранения неисправности; – требуется доставить оборудование на объект – до момента доставки и установки оборудования. В случаях, представленных выше, время приостановки работ не входит в учет продолжительности устранения неисправности. Учет времени устранения неисправности Подрядчиком считается с момента назначения Инцидента специалисту Подрядчика, ответственному за оказание услуг технической поддержки 3 уровня. Подтверждение необходимости приостановления работ находится в зоне ответственности Подрядчика. Приостановление сроков выполнения задач в соответствии с настоящим пунктом подтверждается Заказчиком по мотивированному обращению Подрядчика в СРО, основанному на данных диагностики или на иных фактических обстоятельствах В случае непринятия Подрядчиком необходимых мер по информированию Заказчика (отсутствие надлежащего обращения от Подрядчика или отсутствие уведомления о необходимости осуществления каких-либо действий Заказчиком) не может являться основанием для приостановления работ по устранению неисправности. В отдельных случаях Подрядчику может потребоваться выполнение технологических работ для устранения причин неисправности или недопущения повторения их в будущем. Для обеспечения устранения неисправности Модуля СЦ Заказчиком проводится классификация в соответствии с приоритетами по степени срочности их устранения. Продолжительность устранения неисправности, а также периодичность информирования Подрядчиком Заказчика о ходе устранения неисправности, определены в Регламенте оказания услуг. При подаче обращения (заявки) наивысшего приоритета через СРО Заказчик должен дополнительно проинформировать службу поддержки Подрядчика о созданном обращении (заявки) по телефону уполномоченного сотрудника Подрядчика. При этом временем подачи обращения (заявки) считается время подачи обращения (заявки) через СРО При проведении работ по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности необходимо выполнить следующее: – Заказчику сформировать заявку на устранение (обновление) в СРО с полным списком обнаруженных уязвимостей и планируемыми работами; – согласовать в рабочем порядке время начала и завершения работ, перечень работ, выполняемых в рамках обновления или устранения уязвимостей в ППО с Заказчиком; – оповестить Заказчика о начале проведения работ на тестовом контуре; – провести работы по обновлению или устранению уязвимостей в ППО на тестовом контуре Модуля СЦ в установленные сроки; – протестировать выполнение работ в тестовом контуре и проинформировать Заказчика о готовности переноса ППО на продуктивный контур; – силами Заказчика обновить продуктивный контур Модуля СЦ, в соответствии с планом устранения и выполненными работами; – совместно с Заказчиком проверить корректность функционирования Модуля СЦ и устранения уязвимостей в продуктивном контуре Модуля СЦ по результатам обновления; – при необходимости актуализировать документацию (описание архитектуры, анкеты постановки на мониторинг и иные документы). Любые изменения в части обновления или устранения уязвимостей в ППО на промышленном контуре Модуля СЦ должны применяться только в случае успешного проведения аналогичных работ на тестовом контуре. Детальный порядок оказания услуги по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности определен в Регламенте оказания Услуг 4.4. Требования к видам обеспечения 4.4.1. Требования к лингвистическому обеспечению Документация на Модуль СЦ должна разрабатываться на русском языке. Взаимодействие пользователей с Модулем СЦ посредством графического интерфейса должно происходить на русском языке за исключением сообщений, зависящих от настроек системного программного обеспечения, установленного на рабочих местах пользователей. При разработке программных решений Модуля СЦ должно быть предусмотрено использование языков программирования высокого уровня, приведенных в Таблице 7. Таблица 7. Языки и средства разработки, специального программного обеспечения Модуля СЦ Категория Наименование Назначение Языки программирования Kotlin Разработка серверной логики и сервисов (backend) JavaScript / TypeScript Разработка клиентской части (frontend) Python Разработка скриптов интеграции, обработки данных и автоматизации Фреймворки и библиотеки Vue.JS Разработка пользовательских интерфейсов (веб-интерфейсы компонентов визуализации и отчетности) React Разработка пользовательских интерфейсов (при необходимости создания сложных интерактивных компонентов) Решения по лингвистическому обеспечению, включая перечень используемых языков программирования, должны быть согласованы с Заказчиком на этапе технического проектирования 4.4.2. Требования к математическому обеспечению Требования к математическому обеспечению не предъявляются. 4.4.3. Требования к метрологическому обеспечению Требования к метрологическому обеспечению не предъявляются. 4.4.4. Требования к организационному обеспечению Требования к организационному обеспечению не предъявляются. 4.4.5. Требования к методическому обеспечению Задачи методического обеспечения Модуля СЦ должны быть обеспечены за счет использования технологических и методических документов касающихся вопросов функционирования транспортного комплекса и разработки и эксплуатации ПО. 4.4.6. Требования к информационному обеспечению Состав, структура и способы организации информационного обеспечения в Модуле СЦ должны быть определены на этапе технического проектирования. Факты информационного обмена с внешними системами должны фиксироваться в соответствующем журнале 4.5.5. Требования к информационной безопасности Работы по защите информации/информационной безопасности, не включенные в состав настоящего раздела, требуемые в соответствии с требованиями постановления Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации», а также нормативно правовых актов в области защиты персональных данных и обеспечения безопасности объектов критической информационной инфраструктуры, будут проведены в рамках исполнения отдельного контракта, заключенного по результатам отдельной закупочной процедуры (не является частью данного ТЗ), включающего: – определение актуальных угроз безопасности информации и актуализация модели угроз безопасности информации (при необходимости); – выполнение требований о согласовании технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России в установленном порядке; – выполнение требований по устранению Подрядчиком замечаний и недостатков, в случае их выявления при согласовании Заказчиком технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России; – выполнение требований к классу защищенности ГИС, уровню защищенности персональных данных и категории значимости объекта КИИ РФ, установленных для Головного центра обработки данных ФГБУ «СИЦ Минтранса России» (далее – ГЦОД); – определение перечня объектов защиты информационной системы; – описание (актуализированных) требований к системе защиты информации, а также к мерам защиты информации информационной системы в зависимости от установленных классов защищенности, уровня защищенности персональных данных и категории значимости объектов КИИ РФ (приказы ФСТЭК России № 21, 117, 239); – выполнение требований к мерам по защите ГИС от атак, направленных на отказ в обслуживании, в соответствии с пунктами 30, 34, 59, 63 Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений, утвержденных приказом ФСТЭК России от 11.04.2025 № 117; – описание (актуализированных) требований по защите информации, подлежащих реализации в информационно телекоммуникационной инфраструктуре ГЦОД; – выполнение требований о применении сертифицированных средств защиты информации, включая их классы защиты и уровни доверия; – выполнение требований о запрете использования с 01.01.2025 органами (организациями) средств защиты информации странами происхождения, которых являются иностранные государства в соответствии с пунктом 6 Указа Президента Российской Федерации от 01.05.2022 № 250; – выполнение требований по обеспечению непрерывного взаимодействия с ГосСОПКА в установленном порядке; 4.5.7. Требования по сохранности информации при авариях В случае возникновения аварии или сбоя в процессе выполнения пользовательских задач должно быть обеспечено восстановление баз данных до состояния на момент последней завершенной Модулем СЦ транзакции, и структуры файлового хранилища. Все аварийные ситуации должны обрабатываться программно с выдачей соответствующих сообщений, с корректной обработкой ситуации (завершение транзакций, закрытие файлов и т.п.), без потери обрабатываемой информации. В Модуле СЦ должны быть предусмотрены меры, обеспечивающие целостность данных в случае отказа программного обеспечения или аппаратных средств, исключая случаи физического уничтожения носителя или нарушения функциональности носителя, операционной системы или СУБД по вине их производителя либо обслуживающего персонала. Используемые аппаратные и системные платформы должны обеспечивать сохранность и целостность информации в Модуле СЦ при полном или частичном отключении электропитания, аварии сетей телекоммуникации, полном или частичном отказе технических средств Модуля СЦ. Технические решения должны обеспечивать сохранность информации в случае возникновения следующих событий (аварий, отказов и т.п.): – отказ аппаратного обеспечения на сервере; – отключение питания на сервере; – отказ аппаратного обеспечения на рабочей станции; – отключение питания на рабочей станции администратора; – отказ линий связи, в том числе при осуществлении обмена данными 4.5.8. Требования к защите от влияния внешних воздействий Требования к защите от влияния внешних воздействий не предъявляются 4.5.9. Требования к патентной чистоте и патентоспособности 4.5.9.1. Исключительные права на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, базы данных, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, принадлежат Российской Федерации в лице Заказчика. Право собственности на результаты работ, отчетные документы и материалы, полученные в ходе выполнения работ по Контракту, принадлежат Российской Федерации в лице Заказчика и считаются переданными с момента подписания Сторонами Акта сдачи-приемки выполненных работ. Разработанное программное обеспечение поставляется вместе с исходными кодами. 4.5.9.2. Все проектные и технические решения должны отвечать требованиям четвертой части Гражданского кодекса Российской Федерации. Результаты Работ должны быть свободными от возможности предъявления любых прав и притязаний третьих лиц, основанных на промышленной, интеллектуальной или другой собственности. 4.5.9.3 Результаты выполненных Работ не должны повлечь необходимость осуществления Заказчиком закупок программного обеспечения (как исключительных, так и неисключительных прав) для обеспечения функциональности Системы в соответствии с Техническим заданием. При выполнении работ Подрядчик должен использовать только объекты интеллектуальной собственности, права на которые приобретены (получены) и используются без нарушений прав на интеллектуальную собственность третьих лиц или предоставлены Заказчиком 4.4.7. Требования к программному обеспечению Общесистемное ПО, используемое в составе Модуля СЦ, должно быть зарегистрировано в Едином реестре российских программ для электронных вычислительных машин и баз данных и соответствовать рекомендованным показателям эффективности и соответствующим им значениям индикаторов эффективности перехода подведомственных организаций на использование российского ПО, заданных Приказом Минцифры России от 18.01.2023 № 21 «Об утверждении методических рекомендаций по переходу на использование российского программного обеспечения, в том числе на значимых объектах критической информационной инфраструктуры Российской Федерации, и о реализации мер, направленных на ускоренный переход органов государственной власти и организаций на использование российского программного обеспечения в Российской Федерации». Применяемое в системе программное обеспечение должно соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации, постановления Правительства Российской Федерации от 23 декабря 2024 г. № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц» Прикладное программное обеспечение должно отвечать следующим требованиям: – совместимость программных продуктов в части используемых технических средств, системного программного обеспечения и общесистемной инфраструктуры в пределах требований к техническому обеспечению, а также их информационная совместимость в пределах требований к информационному обмену; – обеспечение трехуровневой архитектуры с разделением на уровень хранения данных (сервер БД), уровень бизнес-логики (сервер приложений) и уровень представления ( 4.4.7.1. Требования к инструментам разработки и процессу контроля версий программного обеспечения 4.4.7.1.1. Система контроля версий Для управления исходным кодом должна использоваться система контроля версий кода, развернутая в инфраструктуре Заказчика. 4.4.7.1.2. Правила именования веток Имя ветки должно соответствовать следующему формату: / / Категории веток: ? feature/ — разработка новой функциональности, а также рефакторинг или удаление существующей; ? fix/ — исправление ошибок; ? hotfix/ — срочные исправления, применяемые в обход стандартного процесса разработки; ? test/ — для проведения экспериментов, не влияющих на основную разработку. Идентификатор задачи: после категории указывается ссылка на задачу (issue) в системе контроля версий кода. Описание: добавляется краткое описание решаемой задачи в формате kebab-case (слова разделяются дефисами, например, add-user-auth). Примеры именования веток: ? feature/#123/add-payment-integration; ? fix/#45/correct-calculation-logic; ? hotfix/#67/urgent-database-connection-patch. 4.4.7.1.3. Правила именования коммитов Сообщение коммита должно соответствовать соглашению Conventional Commits и состоять из категории и описания: : ? fix — исправление ошибки. Примеры сообщений коммитов: ? feat: добавление формы регистрации пользователя; ? fix: исправление ошибки валидации email-адреса; ? refactor: оптимизация алгоритма сортировки данных; ? chore: обновление версий в файле dependencies. 4.4.7.1.4. Модель ветвления В процессе разработки используются следующие основные ветви: ? main / master — стабильная ветка, содержит только код, прошедший полное тестирование и развернутый в продуктивных контурах; ? dev — ветка для интеграции завершенных задач, предназначенная для сборки и тестирования в тестовых средах. Попадание кода в main осуществляется только через Merge Request (MR) из dev – выполнение требований по обеспечению в автоматизированном режиме с Национальной системой противодействия DDoS-атакам (НСПА) Центра мониторинга и управления сетью связи общего пользования ФГУП «ГРЧЦ» в рамках реализации мер по защите ГИС от атак, направленных на отказ в обслуживании; – детализированные требования к составу и содержанию работ по аттестации, а также к их результатам в соответствии с пунктами 13, 15 и 16 требований приказа ФСТЭК России от 29.04.2021 № 77 «Об утверждении Порядка организации и проведения работ по аттестации объектов информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну» 4.5.5.1. Требования к безопасности исходного кода Процесс разработки исходного кода должен соответствовать требованиям законодательства, нормативным правовым актам Российской Федерации, приказу ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по безопасности значимых объектов критической информационной инфраструктуры Российской Федерации», а также учитывать отраслевые практики безопасной разработки. Подрядчик должен предоставить Заказчику Руководство по безопасной разработке программного обеспечения (далее – Руководство), применяемое при разработке исходного кода Модуля СЦ. Руководство должно содержать: · описание процесса безопасной разработки и ролевой модели, отражающей зоны ответственности сотрудников Подрядчика; · описание процессов моделирования, оценки и формирования мер предотвращения угроз, применяемых Подрядчиком; · описание методик, применяемых Подрядчиком при разработке исходного кода (правила написания кода); · описание методик, периодичности проведения и инструментария статического, динамического, композитного и фаззинг тестирования исходного кода, включающего критерии отбора релизных версий ПО, применяемые Подрядчиком в процессе разработки; · описание механизмов безопасности в процессе сборки и доставки (безопасность образов, безопасность секретов, безопасность окружения и сборочной среды), применяемые Подрядчиком; · утвержденные шаблоны отчетной документации (в том числе акты), в соответствии с которыми Заказчик принимает результаты проверок (артефакты сборочного процесса), проведенных Подрядчиком; · описание процедур отслеживания и исправления обнаруженных ошибок и уязвимостей программного обеспечения; · описание способов и сроков доведения Подрядчиком до Заказчика информации об уязвимостях программного обеспечения, о компенсирующих мерах по защите информации или ограничениях по применению программного обеспечения, способов получения пользователями программного обеспечения его обновлений, проверки их целостности и подлинности Подрядчик должен обеспечить реализацию и проведение внутренних проверок мер по разработке безопасного ПО, приведенных в Руководстве. Подрядчик должен провести анализ угроз безопасности информации программного обеспечения в соответствии с ГОСТ 58412-2019 «Защита информации. Разработка безопасного программного обеспечения. Угрозы безопасности информации при разработке программного обеспечения». Подрядчик должен провести испытания по выявлению уязвимостей в программном обеспечении Системы: · проведение статического анализа исходного кода программы; · проведение динамического анализа исходного кода программы; · проведение композитного анализа исходного кода и образов программы; · проведение фаззинг-тестирования программы, направленного на выявление в ней уязвимостей. Испытания по выявлению уязвимостей в программном обеспечении Системы должны быть проведены в рамках: · предварительных испытаний; · опытной эксплуатации; · приемочных испытаний 4.5.9.4. Подрядчик подтверждает, что обладает всеми правами на передачу Заказчику исключительных прав в соответствии с требованиями настоящего раздела Технического задания. В случае, если к Заказчику по вине Подрядчика будут предъявлены претензии в этой части, иски третьих лиц, связанные с нарушением их прав, Подрядчик принимает на себя такие претензии и иски и возмещает Заказчику все расходы и весь ущерб, понесенный в связи с ними. 4.5.9.5. Подрядчик обязан согласовать с Заказчиком необходимость использования при выполнении работ охраняемых результатов интеллектуальной деятельности, права на которые принадлежат Подрядчику или третьим лицам. 4.5.9.6. В случае, если при выполнении Работ используется готовое программное обеспечение (платформа, подсистема, СУБД и т.д.), которое становится частью (компонентом) Системы, Заказчику передаются полные исключительные права, или неисключительные права (путем заключения лицензионного/сублицензионного договора/соглашения) на такое программное обеспечение со следующими возможностями: – права передаются бессрочно (на весь срок действия исключительных прав); – территория действия Российская Федерация; – должно быть обеспечено право Российской Федерации (в лице Заказчика) передавать, дорабатывать, распространять, развивать результаты работ, созданные в процессе исполнения Контракта, а также перерабатывать такое программное обеспечение. Лицензионное (сублицензионное) соглашение (договор), Акт передачи прав, подписанные Подрядчиком, согласие правообладателя, оформленное в соответствии с положениями Гражданского кодекса Российской Федерации (в случае, если Подрядчик не является правообладателем такого программного обеспечения), инструкция по инсталляции, руководство администратора, руководство пользователя передаются Заказчику в сроки, установленные Техническим заданием для соответствующего функционала Системы Лицензионное (сублицензионное) соглашение (договор) не может возлагать на Заказчика какие-либо обязанности (в т.ч. в части конфиденциальности, предоставления отчетности), не предусмотренные Контрактом. 4.5.9.7. Передача Заказчику исключительных прав, или простых (неисключительных) прав не может повлечь увеличение стоимости Контракта и/или изменение иных существенных условий Контракта. 4.5.9.8. Функциональность Модуля СЦ передается в объеме и в сроки, установленные Техническим заданием. 4.5.9.9. Нарушение условий настоящего раздела Технического задания, в т.ч. отсутствие соответствующего лицензионного (сублицензионного) соглашения (или договора), либо предоставление лицензионного (сублицензионного) соглашения (или договора), не соответствующего требованиям действующего законодательства Российской Федерации или требованиям Контракта, является нарушением существенных условий Контракта. 4.5.9.10. В случае, если в соответствии с пунктом 4.5.9.6 Заказчику передается исключительное право, такая передача осуществляется в порядке, установленном Гражданским кодексом Российской Федерации. 4.5.9.11. В случае, если при выполнении Работ положения пунктов 4.5.9.5-4.5.9.6 не применялись, Подрядчик в составе отчетной документации предоставляет об этом декларацию в свободной форме. Декларация должна содержать сведения о полном соответствии результата Работ требованиям Контракта, а также о неприменении при выполнении работ готового программного обеспечения (платформ, подсистем, СУБД и т.д.), которое стало частью (компонентом) Системы 4.5.9.12. Передача Заказчику комплекта документов, материалов и сведений, предусмотренных нормативными правовыми актами Российской Федерации в сфере информационных технологий, защиты информации, правовой защиты интересов государства в области интеллектуальной собственности, включая документы, подтверждающие отказ авторов (разработчиков) от исключительных прав на передаваемые объекты интеллектуальной собственности в пользу Подрядчика, с проектами заявок на государственную регистрацию в установленном порядке прав Заказчика на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, базы данных, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, осуществляется Подрядчиком в составе отчетной документации, предусмотренной условиями Контракта. 4.5.9.13. По результатам выполнения работ по развитию системы должны быть подготовлены материалы для регистрации доработанной версии Системы (объекта учета) в НФАП в соответствии с требованиями постановления Правительства Российской Федерации от 30 января 2013?г. №?62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин» (с изменениями и дополнениями) в части обязательности размещения результатов работ в национальном фонде алгоритмов и программ для электронных вычислительных машин 4.5.10. Требования по стандартизации и унификации К Модулю СЦ предъявляются следующие требования в части стандартизации и унификации: – работы по развитию Модуля СЦ должны производиться в соответствии с действующими стандартами и нормами Российской Федерации; – при создании и модернизации элементов Модуля СЦ следует руководствоваться действующими в Российской Федерации национальными стандартами и другими нормативно-техническими документами; – используемые оборудование и материалы, подлежащие обязательной сертификации, должны иметь соответствующие сертификаты; – ПО Модуля СЦ должно проектироваться и разрабатываться с учётом обеспечения требований унификации; – применяемые при создании Модуля СЦ технические (форматы данных, протоколы передачи и прочие) и организационные (регламенты, требования, инструкции) решения должны быть доступны и документированы в виде, достаточном для независимой (без обращения к Подрядчику) реализации третьими сторонами; – термины, обозначения и наименования, используемые в ПО, должны быть стандартизованы и унифицированы, выполнены на русском языке; – взаимодействие элементов и их внешнее поведение должно быть реализовано одинаково и производиться по единым правилам 4.2.2. Развитие компонента отчетности (3 очередь) Должна быть обеспечена автоматизация процессов формирования отчетов о ЧС и нештатных ситуациях на транспорте, в т.ч. на основе данных из внешних систем. Включает следующие доработки: – разработка шаблонов отчетов в различных форматах (табличный, текстовый); – реализация выбора фотоматериалов для включения в справку; – форматирование содержимого справок с учетом правил русского языка в отношении окончаний слов (в зависимости от падежа, склонения, числа и рода); – автоматизированное формирование выводов к содержимому справки на основе настраиваемых критериев; – создание интерфейса выбора параметров (фильтрации) для формирования отчетов: o состав полей для включения в отчёт; o настройка диапазонов значений характеристик и дат; o порядок отображения полей; o настройка заголовка. – реализация способа подготовки отчётов в асинхронном режиме (очереди); – реализация интерфейса компонента формирования отчетности для отображения очереди формирования отчетов и статусов их подготовки; – экспорт отчётов в форматы xlsx, csv и справок в форматы pdf, docx. Необходимо разработать не менее 10 шаблонов отчетов и/или справок. Перечень, структура и содержание шаблонов должны быть согласованы с Заказчиком на этапе технического проектирования. 4.2.3. Развитие компонента визуализации (2 очередь) В рамках развития компонента визуализации должны быть выполнены следующие доработки, обеспечивающие: – вывод перечней (списков) сил и средств предупреждения и ликвидации ЧС и нештатных ситуаций на транспорте с отображением мест их постоянного размещения (дислокации) на карте, включая: o отображение зон ответственности на карте; o возможность их фильтрации (по видам транспорта, регионам и пр.); o реализацию инструмента расчета расстояния (с использованием сети автомобильных и железных дорог) между местом события и местами дислокации сил и средств, а также вывода маршрутов на карте; – отображение зон (полигонов) с установленными ограничениями движения в воздушном пространстве на карте; – отображение термических точек; – реализация возможности отображения данных из паспорта региона, отображаемого в модуле iМинтранс (модуль АСУ ТК); – отображение краткой карточки сущностей и ОТИ (краткой информации и/или динамических характеристик объекта) при выборе объекта на карте с возможностью перехода в полную карточку сущности и ОТИ; – отображение данных от Росгидромета, предусматривающих: o отображение неблагоприятных и опасных природных явлений на карте (с заданным периодом обновления данных); o управление отображением явлений на карте, включая настройку состава отображаемых объектов, поиск, фильтрацию, с использованием соответствующей панели управления; o выведение краткой карточки явления при выборе объекта, с возможностью перехода в полную карточку объекта – отображение на карте связанных сущностей и ОТИ; – реализация функции выбора темного и светлого стилей отображения элементов интерфейса, карточек сущностей, картографической основы и объектов, отображаемых на карте; – реализация механизма для выбора картографической основы в одном из распространенных форматов WMTS, TMS, MVT и др. Должна быть предусмотрена возможность настройки перечня картографических основ и параметров доступа к ним; – настройка базового набора дашбордов, содержащих преднастроенные виджеты о количестве событий в разрезе видов транспорта с возможностью перехода к исходным данным (карточкам событий, ОТИ и т.д.), с фильтрацией по параметрам. Параметры фильтрации должны быть определены на этапе технического проектирования. Должно быть обеспечено автоматическое и принудительное обновление данных, отображаемых на дашбордах 4.2.4. Создание компонента «Интерактивная карта» (2 очередь) В составе создаваемого компонента должны отображаться данные, доступные в компоненте визуализации. Требования к интерфейсу интерактивной карты: – интерактивная карта должна быть представлена в виде объемной карты с учетом макетов, представленных в Приложении А к ТЗ; – интерфейс должен корректно отображаться на экранах мониторов (разрешение Full HD 1920?1080), телевизоров (разрешение 4К 3840?2160), жидкокристаллических панелей для видеостены, используемой Заказчиком, с параметрами каждой панели: диагональ 55 дюймов, разрешение 1920x1080; – интерфейс должен корректно отображаться на планшетных устройствах с диагональю экрана 10-12 дюймов, конкретные требования должны быть уточнены на этапе технического проектирования; – должна быть обеспечена кластеризация и генерализация отображения объектов на карте при изменении масштаба; – должно быть обеспечено отображение основных характеристик объектов при выборе их на карте; – должно быть обеспечено управление отображением слоев на карте; – должна быть обеспечена настройка цветовой индикации отображаемых объектов транспортной инфраструктуры; – должно быть обеспечено отображение легенды карты, содержащей отображаемые объекты на карте; – должна быть обеспечена возможность одновременного отображения не менее 5 000 ОТИ и ТС на карте. На интерактивной карте должны быть отображены подвижные объекты совместно с объектами транспортной инфраструктуры (ОТИ), включая следующие возможности: § отображение местоположения транспортных средств (воздушный, водный и автомобильный транспорт) на карте в режиме реального времени (с заданным периодом обновления данных); § отображение маршрутов движения всех ТС за выбранный период времени, в том числе с использованием эффектов анимации; § отображение маршрутов движения ТС, связанных с карточкой события: ТС, являющихся участниками события, и ТС, находящиеся в заданном радиусе от события; § управление отображением сущностей и ОТИ на карте, включая настройку состава отображаемых объектов, поиск, фильтрацию, с использованием соответствующей панели управления и наглядным представлением результатов; § автоматическое изменение вида отображения объектов (цветовая индикация) по заданным условиям (например, при достижении критических значений параметров, характеризующих функционирование объекта); Должна обеспечиваться производительность обновления изображения на экране в 30 кадров в секунду на тестовой конфигурации пользовательского устройства (модель Бештау AIO2402/B560, входящая в Реестр российской промышленной продукции под номером 10394100 или аналог) при одновременном отображении не менее 5 000 объектов и 200 уникальных моделей объектов. Макеты интерфейсов Модуля СЦ должны быть предварительно согласованы с Заказчиком и разработаны с учетом требований ГОСТ Р ИСО 9241-161-2016 «Элементы графического пользовательского интерфейса» 4.3.1.3. Требования к регламенту оказания услуг Подрядчик должен руководствоваться Регламентом оказания услуг по технической поддержке Модуля СЦ. Регламент оказания услуг содержит следующую информацию: – порядок оказания услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Модуля СЦ; – порядок оказания услуги по решению инцидентов, связанных с работой ППО; – порядок оказания услуги адаптационного, конфигурационного и коррекционного сопровождения Модуля СЦ (в рамках действующих программных модулей и функциональностей); – порядок оказания услуги по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности. – Регламент содержит следующие формы заявок на оказание услуг: – форма заявки на оказание услуги по информационно-консультационной поддержке сотрудников Заказчика; – форма заявки на оказание услуги по решению инцидентов, связанных с работой ППО; – форма заявки на оказание услуг адаптационного, конфигурационного и коррекционного сопровождения Модуля СЦ (в рамках действующих программных модулей и функциональностей) (приоритет заявки определяется Заказчиком); – форма заявки на оказание услуги по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности 4.3.2. Требования к режиму обеспечения функционирования Модуля СЦ Режим оказания услуг определен в Приложении Б к настоящему ТЗ. По согласованию с Заказчиком, в целях недопущения остановки функционирования Модуля СЦ в период интенсивной работы пользователей в Модуле СЦ, отдельные услуги могут оказываться по специальному графику (в нерабочее время Подрядчика) в соответствии с заявками Заказчика 4.3.3. Требования к качеству оказываемых услуг Качество оказываемых услуг поддерживается Подрядчиком в соответствии с определяемыми данным ТЗ условиями и правилами и контролируется Заказчиком на постоянной основе, в том числе по соблюдению сроков исполнения и подтверждениям исполнения от инициаторов обращений и другим параметрам. По результатам выполнения работ по устранению инцидента должна быть устранена корневая причина инцидента с окончательным решением, устраняющим причину возникновения проблемы и исключающим вероятность повторного возникновения проблемы (инцидента). Время устранения корневых причин проблемы (инцидента) не должно составлять более 40 рабочих часов 4.3.6.3.1. Требования к порядку оказания услуги по решению инцидентов, связанных с работой ППО При поступлении от Заказчика обращения (заявки), являющегося неисправностью в работе Модуля СЦ (инцидентом), Исполнитель реагирует на инцидент в СРО в срок не более 30 минут с момента поступления. В случае необходимости, для решения инцидента ответственный специалист должен связаться с инициатором обращения (заявки) для уточнения условий воспроизведения проблемы или для получения дополнительных сведений. После получения необходимых сведений от инициатора обращения (заявки) ответственный специалист производит диагностику с целью выявления причины инцидента и возможных путей устранения. В случае, если инцидент невозможно решить без получения дополнительных сведений от инициатора, и не удается связаться с инициатором в течение пяти рабочих дней, обращение (заявка) отклоняется в связи с недостатком данных для его решения, Заказчику направляется уведомление об отклонении обращения (заявки). Время, в течение которого невозможно связаться с инициатором, вычитается из общего времени обработки обращения (заявки). Все попытки связаться с инициатором должны фиксироваться с указанием даты и времени попытки, используемого способа связи (номер телефона, адрес электронной почты) и результата попытки (не удалось дозвониться, абонент недоступен, и т.д.) Факт и время решения инцидента должны быть зафиксированы и отражены в СРО. В случае, если причиной сбоя в работе Модуля СЦ является выход из строя аппаратного обеспечения или неработоспособность смежной информационной системы, время работы над инцидентом приостанавливается до момента устранения неисправности. В ходе решения инцидентов могут быть выявлены дефекты ППО Модуля СЦ. В случае обнаружения дефектов ППО, Подрядчик информирует об этом Заказчика. Исполнитель может быть привлечен к проверке результата устранения дефекта по инициативе Заказчика. Приоритеты инцидентов приведены в Приложении Б к ТЗ. Детальный порядок оказания услуги по решению инцидентов, связанных с работой ППО Модуля СЦ определен в Регламенте оказания Услуг 4.3.6.4. Требования к услугам адаптационного, конфигурационного и коррекционного сопровождения и доработки Модуля СЦ (в рамках действующих программных модулей и функциональностей) Услуги адаптационного, конфигурационного и коррекционного сопровождения и доработки Модуля СЦ включают: – управление изменениями и адаптация функций Модуля СЦ; – изменение настроек функционирования Модуля СЦ; – внесение изменений и/или модификаций Модуля СЦ (в рамках действующих программных модулей и функциональностей), направленных на улучшение их работоспособности и функциональных возможностей; – подготовка и передача Заказчику SQL запросов в СУБД для получения агрегированной информации из Модуля СЦ, которую невозможно получить с использованием графического пользовательского интерфейса; – адаптация модулей интеграций со смежными информационными системами 4.4.7.1.5. Требования к используемым зависимостям (библиотекам) Все внешние зависимости проекта должны быть зафиксированы с указанием точных версий. Для контроля версий зависимостей в репозиторий обязательно должны быть включены следующие файлы: · Для JavaScript: package-lock.json или yarn.lock; · Для Python: requirements.txt (с зафиксированными версиями) или Pipfile.lock; · Для Go: go.mod и go.sum; Загрузка всех зависимостей должна производиться исключительно через внутренний прокси-репозиторий Заказчика, настроенный в соответствующем системе менеджере пакетов. Запрещается: · Использование плавающих версий (например, ^1.2.3, ~4.5.0, latest); · Использование библиотек, содержащих критические уязвимости, в том числе зарегистрированные в реестре CVE (Common Vulnerabilities and Exposures). 4.4.7.1.6. Требования к процессу непрерывной интеграции (CI) Сборка программного обеспечения, включая этапы компиляции, тестирования и анализа кода, должна выполняться исключительно в инфраструктуре непрерывной интеграции Заказчика. 4.4.7.1.7. Требования к хранению артефактов сборки Все артефакты сборки (результирующие пакеты, Docker-образы и т.д.) подлежат обязательному хранению в предназначенной для этого инфраструктуре Заказчика (артефакторий). Запрещается размещение финальных артефактов сборки на сторонних ресурсах 4.4.8. Требования к техническому обеспечению Количество серверов, подключаемых и настраиваемых сервисов, их параметров, схемы соединений и настройки межсетевого взаимодействия должны быть согласованы с Заказчиком на этапе № 1 Техническое проектирование. Доступ к комплексу технических средств предоставляется Заказчиком по письменному запросу Подрядчика. Применяемые в Системе программно-аппаратные и аппаратные комплексы должны соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации», требованиям Постановления Правительства Российской Федерации от 23 декабря 2024 г. № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц». Модуль СЦ, работающий в составе АСУ ТК, развернут на вычислительных мощностях ГЦОД СИЦ Минтранса России 4.5. Общие технические требования 4.5.1. Требования к численности и квалификации персонала и пользователей Модуля СЦ Программное обеспечение Модуля СЦ не должно требовать изменения штатной численности персонала Заказчика. Программное обеспечение Модуля СЦ не должно требовать наличия у пользователей дополнительной квалификации в сфере информационных технологий, кроме базовых знаний в обращении с персональным компьютером, базовых навыков работы в интернет-обозревателях и знаний о Модуле СЦ в объеме документов Руководство пользователя, Руководство администратора 4.2.4.1. Требования к технической реализации компонента «Интерактивная карта» При реализации компонента «Интерактивная карта» должны учитываться требования, указанные ниже. 4.2.4.1.1. Требования к отображению элементов Повторяющихся элементы карты (ТС, ОТИ, события и пр.) должны отрисовываться с использованием аппаратного создания экземпляров объектов на пользовательском устройстве (WebGL/WebGPU)). Отрисовка каждого объекта отдельным запросом не допускается, должна обеспечиваться возможность одновременного отображения не менее 5 000 объектов без снижения производительности (30 кадров в секунду на тестовой конфигурации). 4.2.4.1.2. Уровни детализации объектов Для управления отображением сложных объектов должно быть создано не менее 3-х уровней детализации, отображаемых при изменении масштаба с возможностью автоматического переключения между уровнями. Все отображаемые объекты должны масштабироваться с учетом разрешения экрана пользователя с сохранением качества детализации. 4.2.4.1.3. Полигональная оптимизация и текстурирование При реализации компонента «Интерактивная карта» должна обеспечиваться технология рельефного тестурирования объектов. Не должны использоваться высокополигональные трехмерные модели. Все повторяющиеся элементы должны генерироваться единоразово и повторно использоваться при последующих отображениях. 4.2.4.1.4. Управление памятью Требуется реализовать потоковую загрузку на устройство пользователя элементов карты и текстур. Загрузка данных целиком при старте приложения не допускается. Необходимо реализовать механизм очистки памяти от элементов, которые находятся вне области видимости камеры в течение заданного времени. 4.2.4.1.5. Требования к взаимодействию пользователя с интерфейсом компонента «Интерактивная карта» Программная реализация механизмов управление камерой (масштабирование и навигация) должна быть выполнена с поддержкой технологии WebAssembly (WASM). Элементы управления должны являться неотъемлемой частью интерактивной карты. 4.2.5. Развитие компонента администрирования (3 очередь) Должна быть выполнена доработка ролевой модели. Ролевая модель должна обеспечивать управление доступом к отдельным объектам Модуля СЦ и их элементам (атрибутам) с разграничением по видам транспорта, регионам и пр., в частности: – определение набора конкретных действий, доступных пользователям (выполняемых над объектом доступа, например, удаление записи, редактирование записи, формирование отчета и др.); – реализация возможности объединения пользователей в группы; – определение прав доступа для групп пользователей; – реализация интерфейса визуальной настройки прав доступа пользователей к объектам Модуля СЦ 4.3.4. Требования к документированию результатов оказываемых услуг Для обеспечения контроля оказываемых услуг по поддержке Модуля СЦ со стороны Заказчика, по окончании каждого отчетного периода по контракту в соответствии с календарным планом, Подрядчик обязан предоставить Заказчику Отчет об оказанных услугах. Отчет должен содержать детальную информацию об оказанных услугах с указанием даты выполненных мероприятий и приложением обосновывающих документов (заявок, запросов, требований) или ссылкой на такие документы, если они содержатся в Модуле СЦ. Информация о выполненных мероприятиях по заявкам должна быть сформирована на основании соответствующих записей СРО по каждому этапу исполнения Контракта. В случае оказания услуги адаптационного, конфигурационного и коррекционного сопровождения Модуля СЦ, должны быть предоставлены документы, подтверждающие выполнение требований п. 29.3 приказа ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации». Фактическое время реагирования и время решения по всем обращениям, поступившим в СРО, формируется в СРО по итогам отчетного периода в разделе «Отчеты». Фактическое время реагирования и время решения по обращениям учитывает суммарное время, затраченное на реагирование и, соответственно, на работу по обращению с момента назначения обращения специалисту Подрядчика или группе исполнителей, ответственным за оказание услуг технической поддержки 3 уровня от начала до завершения работ Подрядчиком. При этом принимается суммарное время нахождения заявки в соответствующих статусах заявки СРО на стороне Подрядчика 4.3.5. Требования к классификации обращений и заявок Обращения и заявки Заказчика классифицируются в соответствии с приоритетами и регламентными сроками, указанными в Приложении 2 к Регламенту. Регистрация обращений и заявок предусматривает создание новой записи в СРО с присвоением поступившему обращению или заявке (новой записи) уникального идентификатора. Запись в СРО должна содержать вопрос или проблему, которую требуется решить или оказать консультацию. Состав обязательной информации, которую должно содержать обращение или заявка, зафиксирован в Регламенте оказания Услуг. Если обращение или заявка автоматически зарегистрированы в СРО при отправке представителем Заказчика, Подрядчик проверяет корректность классификации обращения или заявки и может обратиться к Заказчику с просьбой корректировки, предоставив обоснования в соответствии с настоящей классификацией (Таблица 6) 4.3.6.4.1. Требования к проведению изменений Основанием для внесения изменений является запрос от Заказчика. Все активности по внесению изменений должны быть согласованы с Заказчиком, а действия Подрядчика при оказании данной услуги должны быть зафиксированы. В рамках данного Технического задания изменениями считаются локальные доработки функционала Модуля СЦ, которые не должны приводить к необходимости выполнения дополнительных аттестационных испытаний или переаттестации АСУ ТК в соответствии с п. 33 приказа от 29.04.2021 № 77 «Об утверждении Порядка организации и проведения работ по аттестации объектов информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну». При необходимости внесения изменений в Модуль СЦ, не связанных с критичным инцидентом, существенно нарушающим работоспособность Модуля СЦ, Заказчик направляет Подрядчику обращение (заявку), в котором излагает суть изменения, которое требуется внести в Модуль СЦ. Исполнитель, в течение 3 (трех) рабочих дней с момента поступления соответствующего обращения (заявки), оценивает техническую возможность реализации запрашиваемого изменения и варианты реализации. По итогу проведения оценки Подрядчик направляет Заказчику заключение о возможности реализации данного изменения с описанием возможных вариантов реализации и согласует с Заказчиком проведение данного изменения При проведении работ по изменению и адаптации Подрядчик должен: – обеспечить выполнение требований безопасной разработки программного обеспечения; – обеспечить предварительное проектирование технических решений и согласование с Заказчиком проекта реализации изменения; – использовать семантическое версионирование (SemVer) в работе, передать Заказчику все артефакты разработки (исходный код и сторонние библиотеки, конфигурации, сборочные и собранные образы и др.); – подготовить полноценное описание функционала, включенного в релиз, с необходимыми схемами и пояснениями к обновлению на стендах Заказчика; – обеспечить тестирование разработанного функционала на стендах Заказчика силами Подрядчика; – решение о переносе измененного ППО на продуктивный стенд принимается Заказчиком по итогу результатов проведенного тестирования; – обеспечить техническое сопровождение процедуры тестирования ППО и переноса измененного ППО на продуктивный стенд Заказчика; – обеспечить экстренное внесение соответствующих изменений в случае выявления некорректной работы продуктивного стенда Заказчика после проведения обновления по итогам разработанного изменения в кратчайшие сроки; – актуализировать при необходимости комплект эксплуатационной документации: o руководство пользователя; o руководство администратора; o иные документы (при необходимости). Результат выполнения изменений должен быть отражен в Отчете по оказанию услуг. Типы и приоритеты изменений могут быть скорректированы в процессе оказания услуг исключительно по согласованию с Заказчиком 4.5.2. Требования к режимам функционирования Модуля СЦ Модуль СЦ должен предусматривать наличие следующих режимов работы: – штатный; – регламентный (профилактический); – аварийный. Основным режимом функционирования является штатный. В штатном режиме все компоненты корректно и полностью выполняют свои функции. Перерывов в работе как Модуля СЦ в целом, так и одного, либо нескольких компонентов не предусмотрено. Режим регламентного (профилактического) обслуживания предназначен для проведения работ по обновлению и техническому обслуживанию компонентов Модуля СЦ, а также резервному копированию данных. При работе в данном режиме допускаются перерывы в работе Модуля СЦ с предварительным информированием пользователей. Состав процедур по регламентному обслуживанию Модуля СЦ и их периодичность определяются Подрядчиком в процессе выполнения работ по созданию Модуля СЦ. В режиме регламентного (профилактического) обслуживания Модуль СЦ может функционировать с частичным ограничением своих функциональных возможностей, либо без ограничения, но со снижением показателей надежности и производительности. Перевод в данный режим работы должен осуществляться сразу после начала выполнения любой операции, отнесенной к этому режиму, с последующим возвратом в штатный режим функционирования сразу после ее завершения. Перевод в указанный режим должен осуществляться при возникновении необходимости проведения работ по обновлению и техническому обслуживанию компонентов Модуля СЦ, а также резервному копированию данных с условием предварительного оповещения пользователей. Аварийный режим функционирования характеризуется отказом одной или нескольких подсистем, вызванных выходом из строя аппаратного и/или программного обеспечения, а также в случае временной неработоспособности каналов связи между серверами. В аварийном режиме осуществляется поиск неисправностей и проведение работ по их устранению. Перевод в аварийный режим должен осуществляться при возникновении сбоев, аварий и прочих незапланированных воздействий, сразу после наступления одной или нескольких аварийных ситуаций, с последующим возвратом в штатный режим функционирования сразу после окончания восстановительных работ. ПО Модуля СЦ должно обладать надежностью, обеспечивающей работу пользователей в произвольном режиме и оперативное восстановление работоспособности при сбоях. В целях обеспечения надежного функционирования ПО должно предусматривать: – сохранение целостности данных при нештатном завершении работы компонентов Модуля СЦ; – сохранение работоспособности программного обеспечения при некорректных действиях пользователя; – резервное копирование базы данных Модуля СЦ. – время восстановления работоспособности Модуля СЦ после отказа не более 4 часов. – отказоустойчивость на уровне 99% при единовременной количестве не менее 200 пользовательских сессий в Модуле СЦ. Указанные характеристики приведены без учета характеристик надежности инфраструктуры и времени передачи информации по каналам связи. При возникновении сбоев в аппаратном обеспечении, включая аварийное отключение электропитания, Модуль СЦ должен автоматически восстанавливать свою работоспособность (не требовать перенастройки) после устранения сбоев и корректного перезапуска аппаратного обеспечения По результатам анализа угроз безопасности информации программного обеспечения и испытаний по выявлению уязвимостей в программном обеспечении Системы должна быть предоставлена отчетная документация по формам, утвержденным в Руководстве, и артефакты сборочной среды, подтверждающие проведение испытаний по выявлению уязвимостей в программном обеспечении Систем. Уязвимости подлежат устранению в сроки, обозначенные Заказчиком. В случае обнаружения уязвимого компонента Подрядчик должен заменить/обновить библиотеки. В случае, если уязвимость не подлежит исправлению на программном уровне, Подрядчик должен разработать меры предотвращения угроз безопасности, в том числе правила безопасности для наложенных средств защиты, рекомендации по безопасной настройке конфигурации для устранения потенциальных уязвимостей и снижения рисков информационной безопасности. Уязвимости, найденные ФСБ России, ФСТЭК России, Минцифры России, Роскомнадзором в ходе исполнения Контракта, а также в течение гарантийного периода, должны быть устранены Подрядчиком за свой счет в сроки, согласованные с Заказчиком 4.5.6. Требования к эргономике и технической эстетике Взаимодействие пользователей с Модулем СЦ должно осуществляться посредством визуального графического интерфейса. Ввод-вывод данных, прием управляющих команд и отображение результатов их исполнения должны выполняться в интерактивном режиме. Интерфейс должен быть рассчитан на преимущественное использование манипулятора типа «мышь», то есть управление Модулем СЦ должно осуществляться с помощью набора экранных меню, кнопок, значков и т. п. элементов. Клавиатурный режим ввода должен использоваться главным образом при заполнении и/или редактировании текстовых и числовых полей экранных форм. Все надписи экранных форм, а также сообщения, выдаваемые пользователю (кроме системных сообщений), должны быть на русском языке. Модуль СЦ должен обеспечивать проверку вводимых пользователем данных и предупреждать о некорректно введённых значениях Экранные формы должны проектироваться с учетом требований унификации: – все экранные формы пользовательского интерфейса должны быть выполнены в едином графическом дизайне, с одинаковым расположением основных элементов управления и навигации; – для обозначения сходных операций должны использоваться сходные графические элементы, кнопки и другие управляющие (навигационные) элементы. Термины, используемые для обозначения типовых операций, а также последовательности действий пользователя при их выполнении должны быть унифицированы; – внешнее поведение сходных элементов интерфейса (реакция на наведение указателя «мыши», переключение фокуса, нажатие кнопки) должно реализовываться одинаково. Структура размещения информации и представление этой структуры в Модуле СЦ должны соответствовать следующим требованиям: – пункты меню в пользовательском веб-интерфейсе должны быть сгруппированы в соответствии с тематикой информации, функциональными задачами и технологией работы; – каждому пункту меню должна соответствовать только одна выполняемая функция; – при совершении пользователями ошибочных действий должны выдаваться сообщения об ошибках. Эскизы визуального оформления компонента «Интерактивная карта» представлены в Приложении А. 4.5.11. Требования к показателям назначения 4.5.11.1. Требования к показателям назначения мероприятий по развитию Модуля СЦ В рамках выполнения работ по развитию Модуля СЦ, предусмотренных ТЗ, показатель назначения «Количество пользователей» должен соответствовать значениям, приведенным в данном разделе. Пояснения по показателям, связанным с количеством пользователей, приведены в Таблице 8. Таблица 8. Определения показателей, связанных с количеством пользователей в Модуле СЦ № Показатель Определение Расчетное количество пользователей Количество пользователей, работу которых должен обеспечить Модуль СЦ к моменту сдачи работ по Контракту с учетом достижения всех показателей назначения Расчетное количество одновременно работающих пользователей Количество одновременно работающих пользователей, работу которых должен обеспечивать Модуль СЦ к моменту сдачи работ по Контракту с учетом достижения всех показателей назначения Значения показателей количества пользователей, достижение которых необходимо обеспечить, представлено в Таблице 9 Таблица 9. Значения показателей количества пользователей № Показатель Значение 1. Расчетное количество пользователей 1 000 2. Расчетное среднее количество одновременно работающих пользователей 200 Развитие Модуля СЦ должно быть направлено на достижение следующего эффекта (показателя), подставленного в мероприятии 103.002 «Информационно-аналитическая система регулирования на транспорте (АСУ ТК)» ВПЦТ Минтранса России: Выполнение работ по развитию Модуля СЦ предусмотрено мероприятием по развитию АСУ ТК, приведенном в ВПЦТ Минтранса России на 2026-2028 гг: № 103.002 «АСУ ТК» в составе ИТ расхода 103.26.000005 «Развитие предусматривает реализацию ОКР и эффектов, приведенных в Таблице 10. Таблица 10. ОКР и эффекты, приведенные в ВПЦТ Минтранса России на 2026 г. № ОКР Дата ОКР Эффекты 1 Обеспечено информационное взаимодействие с Минобороны России о происшествиях на транспортных объектах 25.12.2026 Сокращено время сбора и передачи сведений для Минобороны России о ЧС и НС на транспорте с 120 до 10 минут 2 Обеспечена автоматизация формирования отчетов о нештатных ситуациях на транспорте, в том числе по данным внешних систем 25.12.2026 Сокращено время на подготовку отчетов о нештатных ситуациях на транспорте с 20 до 5 минут Реализация остальных ОКР не является предметом данного ТЗ и проводится в рамках отдельного технического задания. 4.5.11.2. Требования к показателям назначения мероприятий по эксплуатации Модуля СЦ. Работы по эксплуатации Модуля СЦ не должны обеспечивать режимы функционирования Модуля СЦ, приведенные в разделе 4.5.2 данного ТЗ 5. СОСТАВ И СОДЕРЖАНИЕ РАБОТ ПО РАЗВИТИЮ И ТЕХНИЧЕСКОЙ ПОДДЕРЖКЕ МОДУЛЯ СЦ (КАЛЕНДАРНЫЙ ПЛАН) 1 Техническое проектирование Сопроводительным письмом предоставляются Заказчику: · Технический проект, включая следующие документы: – Ведомость технического проекта; – Ведомость машинных носителей информации – Пояснительная записка; – Описание информационного обеспечения системы; – Описание автоматизируемых функций; – Схема функциональной структуры; – Описание организации информационной базы; – Описание программного обеспечения; · Макеты экранных форм компонента «Интерактивная карта»; · Руководство по безопасной разработке программного обеспечения; · Документ о приемке Начало: с даты заключения контракта Окончание: не позднее 31.07.2026 Значение характеристики не может изменяться участником закупки 2 Услуги по технической поддержке Модуля СЦ (с даты заключения контракта по 10.09.2026) По окончании оказания Услуг сопроводительным письмом предоставляются Заказчику: – Отчет об оказанных Услугах по технической поддержке; – Актуальные на дату окончания оказания Услуг по данному этапу исходные коды прикладного ПО на электронном носителе (в случае внесения изменений); – Инструкция по сборке и развертыванию (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство пользователя (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство администратора (в случае внесения изменений); – Документ о приемке Начало: с даты заключения контракта Окончание: не позднее 10.09.2026 3 Разработка программного обеспечения (1 очередь, пп. 4.2.1, 4.2.6 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ; – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 1 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 1 очереди; – Руководство по резервному копированию; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 16.09.2026 4 Разработка программного обеспечения (2 очередь, пп. 4.2.3, 4.2.4 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ. – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 2 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 2 очереди; – Руководство по резервному копированию; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 25.09.2026 5 Разработка программного обеспечения (3 очередь, пп. 4.2.2, 4.2.5 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ; – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 3 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 3 очереди; – Руководство по резервному копированию; – Описание ролевой модели; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 09.10.2026 6 Опытная эксплуатация (1 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акт о завершении опытной эксплуатации 1 очереди; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке 17.09.2026 Окончание: не позднее 26.10.2026 7 Опытная эксплуатация (2 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акт о завершении опытной эксплуатации 2 очереди; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке 26.09.2026 Окончание: не позднее 26.10.2026 8 Опытная эксплуатация (3 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Акт о завершении опытной эксплуатации 3 очереди; – Документ о приемке Начало: с 10.10.2026 Окончание: не позднее 26.10.2026 9 Приемочные испытания Сопроводительным письмом предоставляются Заказчику: – Программа и методика приёмочных испытаний; – Протокол приемочных испытаний; – Исходные коды и дистрибутивы на электронном носителе (при условии внесения изменений, с учетом доработок по результатам опытной эксплуатации и проведенных испытаний); – Комплект рабочей документации на Модуль СЦ (при условии внесения изменений, с учетом доработок по результатам опытной эксплуатации и проведенных испытаний); – Акт приемки Системы в эксплуатацию; – Акт приемки-передачи исключительных прав на объект; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке; – Документы в соответствии с разделом 4.5.9 ТЗ; – Обеспечение гарантийных обязательств Начало: с 27.10.2026 Окончание: не позднее 10.11.2026 10 Услуги по технической поддержке Модуля СЦ (с 11.09.2026 по 15.12.2026) По окончании оказания Услуг сопроводительным письмом предоставляются Заказчику: – Отчет об оказанных Услугах по технической поддержке; – Актуальные на дату окончания оказания Услуг по данному этапу исходные коды прикладного ПО на электронном носителе (в случае внесения изменений); – Инструкция по сборке и развертыванию (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство пользователя (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство администратора (в случае внесения изменений); – Документ о приемке Начало: с 11.09.2026 Окончание: не позднее 15.12.2026 Работы по развитию Системы (за исключением этапов проведения опытной эксплуатации и услуг по технической поддержке) могут быть выполнены досрочно. При досрочном выполнении работ (этапов работ) Подрядчик в письменной форме уведомляет Заказчика о готовности представить для приемки результаты проведения работ в соответствии с требованиями Контракта. Подрядчик также вправе досрочно приступать к работам в рамках очередного этапа при наличии технической, организационной готовности - при условии получения соответствующего согласования Заказчиком. Сдача-приемка результатов выполненных работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная, техническая документация, а также результаты Работ по каждому этапу предоставляется Заказчику в порядке, предусмотренном Контрактом и настоящим Техническим заданием, до размещения Подрядчиком в Единой информационной системе в сфере закупок документа о приемке. Документ о приемке размещается в ЕИС по каждому этапу в соответствии с условиями Контракта. Согласование документов осуществляется в электронном виде посредством переписки с адресов электронной почты Заказчика и Подрядчика, указанных в контракте. Сдача-приемка результатов выполненных работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная техническая документация, а также результаты работ предоставляются Заказчику в порядке, предусмотренном Контрактом и ТЗ, до размещения Подрядчиком в ЕИС документа о приемке. Документ о приемке размещается в ЕИС по каждому этапу в соответствии с условиями Контракта. Этапы выполнения работ по развитию Модуля СЦ приведены в Таблице 11. Таблица 11. Этапы выполнения работ по развитию Модуля СЦ. № этапа Наименование этапа Результат (отчетная документация) Срок исполнения этапа 6. ПОРЯДОК РАЗРАБОТКИ МОДУЛЯ СЦ Проектирование Модуля СЦ должно включать разработку следующих документов: – Ведомость технического проекта; – Ведомость машинных носителей информации – Пояснительная записка; – Описание информационного обеспечения системы; – Описание автоматизируемых функций; – Схема функциональной структуры; – Описание организации информационной базы; – Руководство по безопасной разработке программного обеспечения; – Описание программного обеспечения; – Макеты экранных форм компонента «Интерактивная карта». Структура документов должна соответствовать ГОСТ Р 59795-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов». Разработка Модуля СЦ должна включать в себя: – разработку программного обеспечения в части новых функций Модуля СЦ; – сборка исходного кода, развертывание и настройку доработанного программного обеспечения Модуля СЦ на вычислительных мощностях Заказчика (тестовый контур); – Комплект рабочей документации на Модуль СЦ; – разработку документа «Программа и методика предварительных испытаний»; – разработку документа «Программа и методика приемочных испытаний»; – разработку документа «Программа опытной эксплуатации». Структура документов должна соответствовать ГОСТ Р 59795-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов». В ходе выполнения работ формируется правоустанавливающая, отчетная, рабочая и техническая документация в соответствии с Контрактом и Календарным планом, приведенном в разделе 5. Значение характеристики не может изменяться участником закупки 6.1. Сведения о гарантийном обслуживании Модуля СЦ Под гарантией понимается устранение Подрядчиком своими силами и за свой счет допущенных по его вине недостатков, выявленных после приемки выполненных Работ, как в работе самой Модуля СЦ, так и недостатков в отчетной документации. Если в период гарантийного срока обнаружатся недостатки, то Подрядчик обязан устранить их за свой счет, в сроки, установленные Заказчиком. Гарантийный срок в этом случае продлевается на период устранения недостатков. Срок гарантии: 1 год с даты приемки Заказчиком результатов исполнения Этапа № 9 контракта. Подрядчиком должны быть внесены соответствующие исправления в техническую и рабочую документацию (указанную в пунктах 5 и 6 настоящего ТЗ), связанные с устранением замечаний к работе Модуля СЦ или в случае выявления Заказчиком недостатков в такой документации в период гарантийного срока. Внесение изменений в документацию технического и рабочего проектирования осуществляется в соответствии с ГОСТ 2.503-2023 и ГОСТ Р 2.504-2021. 7. ПОРЯДОК КОНТРОЛЯ И ПРИЕМКИ РЕЗУЛЬТАТОВ ВЫПОЛНЕНИЯ РАБОТ ПО РАЗВИТИЮ МОДУЛЯ СЦ До момента подключения внешних ИС, Подрядчиком могут быть использованы эмуляторы ИС для прохождения предварительных испытаний, опытной эксплуатации и приемочных испытаний. В рамках опытной эксплуатации должны быть проведены мероприятия по нагрузочному тестированию Модуля СЦ. Документ «Программа и методика приемочных испытаний» должен быть разработан с учетом недостатков, выявленных в ходе опытной эксплуатации, утвержден Заказчиком до начала приемочных испытаний, при этом проверки Модуля СЦ в части не устраненных недостатков, выявленных в процессе опытной эксплуатации, должны быть вынесены в отдельный раздел «Программы и методики приемочных испытаний». В процессе приемочных испытаний должно быть проверено устранение недостатков, полученных в ходе опытной эксплуатации. После завершения устранения всех замечаний, препятствующих приемке Системы в эксплуатацию, перечисленных в Протоколе приемочных испытаний, Подрядчик должен письменно уведомить Заказчика о том, что все замечания устранены, после чего приемочные испытания по решению Заказчика могут быть проведены повторно. Процедура приемочных испытаний проводится до подписания Протокола приемочных испытаний, не содержащего замечаний, препятствующих приемке Системы в эксплуатацию. Приемочные испытания Системы считаются завершенными успешно, если Протокол приемочных испытаний не содержит замечаний, препятствующих приемке Системы в эксплуатацию Значение характеристики не может изменяться участником закупки Испытания должны быть организованы и проведены в соответствии с ГОСТ Р 59792-2021 «Информационная технология. Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем». Должны быть проведены следующие виды испытаний: – предварительные испытания; – опытная эксплуатация; – приемочные испытания. Указанные виды испытаний проводятся в отношении не функциональных требований и функциональных возможностей, разрабатываемых в соответствии с настоящим ТЗ. Отдельные виды испытаний проводятся поэтапно в сроки, установленные Календарным планом. Предварительные испытания, опытная эксплуатация, приемочные испытания проводятся комиссией, создаваемой организационно-распорядительным документом Заказчика, который должен определять состав комиссии, порядок ее работы. Методы предварительных испытаний и порядок их проведения должны быть определены в документе «Программа и методика предварительных испытаний», который должен быть утвержден Заказчиком до начала предварительных испытаний. По результатам предварительных испытаний оформляется Протокол предварительных испытания и Акт о приемке в опытную эксплуатацию. Порядок проведения и методы испытаний во время опытной эксплуатации должны быть определены в документе «Программа опытной эксплуатации», который должен быть утвержден Заказчиком до начала опытной эксплуатации. Ход и результаты опытной эксплуатации отражаются в документе «Журнал опытной эксплуатации», и учитываются в ходе приемочных испытаний. По результатам опытной эксплуатации подписывается Акт о завершении опытной эксплуатации 8. ТРЕБОВАНИЯ К СОСТАВУ И СОДЕРЖАНИЮ РАБОТ ПО ПОДГОТОВКЕ МОДУЛЯ СЦ К ВВОДУ В ЭКСПЛУАТАЦИЮ По результатам проведения приемочных испытаний оформляется Протокол приемочных испытаний и Акт приемки в эксплуатацию. В случае, если взаимодействие с внешними системами не может быть проверено на средах постоянной эксплуатации взаимодействующих систем (по причине неготовности со стороны внешней системы или иным причинам), функции взаимодействия, разработанные в соответствии с требованиями ТЗ, должны быть проверены на тестовых данных с использованием программ-имитаторов взаимодействия. По результатам выполнения этапа приемочных испытаний должны быть подготовлены материалы для регистрации доработанной версии Модуля СЦ (объекта учета) в НФАП в соответствии с требованиями постановления Правительства Российской Федерации от 30 января 2013?г. №?62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин» (с изменениями и дополнениями) в части обязательности размещения результатов работ в национальном фонде алгоритмов и программ для электронных вычислительных машин. Сдача-приемка результатов выполнения Работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная, техническая документация, а также программное обеспечение предоставляется Заказчику в порядке, предусмотренном Контрактом и ТЗ до размещения Подрядчиком в Единой информационной системе в сфере закупок документа о приемке. Результаты проведения опытной эксплуатации, предварительных и приемочных испытаний должны быть зафиксированы в соответствующих протоколах и актах. Выявленные отклонения от настоящего ТЗ, оформляются как недостатки Модуля СЦ Значение характеристики не может изменяться участником закупки Протоколы предварительных и приемочных испытаний должны содержать вывод о соответствии Модуля СЦ предъявляемым требованиям, а также сроки устранения замечаний и реализации рекомендаций, сформулированных комиссией в ходе предварительных и приемочных испытаний. Условием для передачи Модуля СЦ в промышленную эксплуатацию является устранение всех замечаний. Документация на Модуль СЦ и ее части (техническая и рабочая) должна содержать исчерпывающее описание принятых проектных решений в объеме, достаточном для ее дальнейшего развития и эксплуатации. Техническая и рабочая документация должна содержать описание разработанных результатов работ, в том числе программ для ЭВМ, прикладных программных интерфейсов, алгоритмов и протоколов информационного взаимодействия, технических требований, спецификаций и форматов обмена данными для взаимодействия с другими информационными системами, в объеме, достаточном для их установки, настройки, эксплуатации и развития в дальнейшем без привлечения Подрядчика. Исходные коды передаются в виде и составе, позволяющем провести: – сборку (компиляцию) Модуля СЦ в контролируемой Заказчиком среде; – установку полученной Модуля СЦ на специально подготовленную контролируемую Заказчиком инфраструктуру; – проверку функциональных возможностей Модуля СЦ; – оформление Модуля СЦ в качестве объекта национального фонда алгоритмов и программ для электронных вычислительных машин 8.1. Требования, предъявляемые в соответствии с Приказом Минцифры России от 17.12.2020 № 715 «Об утверждении типовых условий контрактов на выполнение работ по созданию и (или) развитию (модернизации) государственных (муниципальных) и (или) иных информационных систем» Передача исходных кодов, разработанных в ходе выполнения работ, программ для электронных вычислительных машин (далее – программа для ЭВМ) должна сопровождаться передачей всех необходимых для сборки и запуска программы для ЭВМ библиотек зависимостей, программных сценариев (скриптов) для проведения установки (развертывания) программы для ЭВМ. Подрядчик в процессе сдачи-приемки работ по Контракту должен провести демонстрацию процесса и установки (развертывания) разработанных программ для ЭВМ. Документация на Модуль СЦ должна содержать описание принятых проектных решений в объеме, достаточном для ее дальнейшего развития и эксплуатации 9. ТРЕБОВАНИЯ К ДОКУМЕНТИРОВАНИЮ 9.1. Общие требования Документация на Модуль СЦ должна быть разработана в составе, указанном в разделах 5-8 данного ТЗ, и должна удовлетворять требованиям комплекса стандартов и руководящих документов на автоматизированные системы: – ГОСТ Р 2.105-2019 в части оформления текстовых документов; – ГОСТ 34.201-2020 в части наименования и обозначения документов. Документация на Модуль СЦ должны оформляться на листах формата А4. Допускается для размещения рисунков и таблиц использование листов формата А3 с подшивкой по короткой стороне листа. Документы объемом более 25 (двадцати пяти) листов должны содержать информационную часть, состоящую из аннотации и содержания. Исходные коды должны быть представлены в 1 (одном) экземпляре на электронном носителе, отчетные материалы должны быть представлены в 2 (двух) экземплярах на бумажном носителе (по одному экземпляру для Заказчика и Подрядчика) и в 1 (одном) экземпляре на электронном носителе в формате документов DOCX и PDF. При разработке документов на Модуль СЦ допускается отклонение от требований комплекса стандартов, описанных выше. Документам на Модуль СЦ должны в обязательном порядке присваиваться уникальные децимальные номера в соответствии с порядком, установленном в ГОСТ 34.201-2020. Документ «Программа и методика предварительных испытаний» должен включать приложения с формой протокола предварительных испытаний и формой акта приемки в опытную эксплуатацию. Документ «Программа опытной эксплуатации» должен включать приложение с формой журнала опытной эксплуатации. Документ «Программа и методика приемочных испытаний» должен включать приложения с формой протокола приемочных испытаний и формой акта приемки в эксплуатацию Значение характеристики не может изменяться участником закупки 10. ИСТОЧНИКИ РАЗРАБОТКИ 10.1. Список литературы Специальная литература для разработки ТЗ не использовалась. 10.2. Нормативно-методические документы Список используемых нормативно-методических документов представлен в разделе 1.6 технического задания. ? Приложение А Эскизы визуального оформления компонента «Интерактивная карта» Значение характеристики не может изменяться участником закупки Приложение Б Параметры оказания услуг 1 Режим работы Системы Круглосуточно (24х7) 2 Режим доступности информационно-консультационной поддержки пользователей Системы 2.1 Прием и регистрация обращений (заявок) в СРО Регистрация обращений (заявок) производится круглосуточно в режиме 24х7, без праздников и выходных дней. Обработка заявок первой линией поддержки осуществляется в рабочие дни с 9 до 18 часов 2.2 Консультирование сотрудников Заказчика и пользователей Системы в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 3 Режим доступности по решению инцидентов, связанных с работой ППО: 3.1 - приоритет «Критический» Круглосуточно (24х7) 3.2 - приоритет «Высокий» Круглосуточно (24х7) 3.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 3.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4 Режим доступности услуг по адаптации, конфигурации и коррекционному сопровождению Системы 4.1 - приоритет «Критический» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.2 - приоритет «Высокий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 5 Режим доступности по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности 5.1 - приоритет «Критический» Круглосуточно (24х7) 5.2 - приоритет «Высокий» Круглосуточно (24х7) 5.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 5.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) Значение характеристики не может изменяться участником закупки Таблица Б.1.2. Сроки предоставления отчетности, с момента получения запроса № п/п Параметр Значение 1 Предоставление отчета об оказанных услугах за произвольный период 10 рабочих дней 2 Предоставление подробной информации по инциденту с приоритетом «Критический» 16 рабочих часов 3 Предоставление актуализированной документации 10 рабочих дней Б.1. Базовые параметры оказания Услуг Базовые параметры оказания Услуг приведены ниже: – режимы оказания Услуг (таблица Б.1.1); – сроки предоставления отчетности (таблица Б.1.2). Таблица Б.1.1 - Режимы оказания Услуг № п/п Параметр Значение Б.2. Приоритеты и регламентные сроки решения обращений (заявок) В зависимости от уровня сбоя в работе Системы обращению (заявке) присваивается один из следующих приоритетов, а также в зависимости от приоритета обращения (заявки) устанавливаются следующие контрольные сроки решения в соответствии с таблицей ниже (Таблица Б.2.1). Таблица Б.2.1 – Приоритеты и регламентные сроки решения обращений (заявок) № п/п Приоритет Максимальное время реагирования Время решения (срок выполнения) Описание приоритета По информационно-консультационной поддержке сотрудников Заказчика и пользователей Системы 1 - не более 1 часа не более 10 часов - По решению инцидентов, связанных с работой ППО: 1 Критический не более 30 минут не более 4 часов - полная недоступность ППО; - недоступность ключевых функций - ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО; - невозможность информационного обмена с ППО для ИС более 4 часов 2 Высокий не более 1 часа не более 8 часов - ошибки/сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; - снижение быстродействия СПО (время отклика ППО на операции превышает 30 секунд); - недоступность управления правами и ролями пользователей 3 Средний не более 4 часов не более 24 часов - невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым -недоступность функции формирования отчетов 4 Низкий не более 8 часов не более 40 часов - отклонение в работе ППО, не влияющее на корректную работу функций; - другие сбои и ошибки, затрагивающие основные функции ППО По адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) 1 Критический не более 40 минут не более 8 часов - изменения, необходимые при проведении аварийно-восстановительных работ для возобновления работоспособности Системы; - изменения, связанные с критичными ошибками, блокирующими возможность оказания государственных услуг и/или чтение и внесение данных в Систему 2 Высокий не более 1 часа не более 40 часов - изменения, относящиеся к обеспечению работоспособности основной функциональности Системы, устраняют выявленные дефекты в работе Системы, оказывающие существенное влияние на работу пользователей в Системе; - изменения, затрагивающие три и более подсистемы/модуля Системы для адаптации 3 Средний не более 4 часов не более 72 часов - изменения, связанные с развитием/улучшением/оптимизацией Системы и выводом новой функциональности в штатном режиме для одного-двух модулей/подсистем; - изменения, связанные с развитием интеграционных механизмов Системы, например обновление существующих и/или реализация новых видов сведений СМЭВ, обновление существующих и/или реализация новых API, адаптация и/или изменение механизмов импорта и экспорта данных Системы и т.д. 4 Низкий не более 8 часов не более 160 часов - изменения, связанные с ошибками/корректировкой/изменением в отображении информации в пользовательском графическом интерфейсе Системы (графика, текст, органы управления, элементы интерфейса) По устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности 1 Критический не более 30 минут не более 24 часов - критические уязвимости, влияющие на возможную полную недоступность ППО, ключевых функций Системы, ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО без возможности восстановления работоспособности Системы. - Критический уровень CVSS > 8.0 2 Высокий не более 1 часа не более 84 часов - критические уязвимости, влияющие на ошибки и сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО. - Высокий уровень CVSS 5.0 - 8.0 3 Средний не более 4 часов не более 120 часов - уязвимости, влияющие на невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым - Средний уровень CVSS 2.0 - 4.9 4 Низкий не более 8 часов не более 160 часов - уязвимости, влияющие на отклонение в работе ППО, не влияющее на корректную работу функций; - другие сбои и ошибки, затрагивающие основные функции ППО - Низкий уровень CVSS < 2.0 Взаимодействие Заказчика и Подрядчика в части регистрации и контроля времени реагирования и решения обращения (заявки) осуществляется через СРО. Заказчик предоставляет Подрядчику доступ к СРО после заключения Контракта. Поступившие от разных пользователей заявки по поводу однотипных инцидентов или имеющие общую причину должны объединяться в одну заявку. Срок выполнения включает время диагностики инцидента, в ходе которого определяется причина инцидента (проблемы) и способ его устранения. Подрядчик должен обеспечить функционирование Модуля СЦ в соответствии с требованиями и параметрами, указанными в настоящем ТЗ и Регламенте оказании услуг. Основные параметры быстродействия типовых операций в Модуле СЦ указаны в таблице ниже (таблица Б.2.2). Таблица Б.2.2 - Параметры быстродействия Модуля СЦ № п/п Наименование параметра Значение (секунд) 1 Среднее время получения сообщения из очереди сообщений 10 2 Среднее время получения ответа от Системы 5 3 Среднее время открытия карточки реестра 5 Приложение В Регламент оказания услуг Приложение Г Форма Отчета об оказанных услугах Отчет об оказанных услугах за этап «наименование этапа» в период с «__» _________ по «__» _________. № п/п Наименование услуги Общее количество Номер ОРС Краткое Описание Время реагирования по ТЗ Время реагирования фактическое Время решения по ТЗ Время решения фактическое Результат соблюдения времени реагирования Результат соблюдения времени решения Примечание 1 Услуги по информационно-консультационной поддержке работников Заказчика 2 546782 Консультация по работе Модуля СЦ 1 2 10 часов 11 часов Нет Нет 567123 Консультация по схеме БД 1 1 10 часов 1 час Да Да 2 … … Заказчик Подрядчик /Должность/ /Должность/ ____________________ /Ф.И.О/ ___________________ /Ф.И.О/ М.П. М.П. «_____»_______________________202_г. «_____»_______________________202_г Значение характеристики не может изменяться участником закупки Приложение 1 к Отчету об оказанных услугах Журнал обращений (заявок) на оказание услуги по информационно-консультационной поддержке пользователей Системы (шаблон) Наименование Исполнителя в этапе «наименование этапа» в период с ________________ по _______________ оказал(о) Услугу по поддержке пользователей Системы в объеме, указанном в Таблице 1 Таблица 1 - Журнал обращений (заявок) пользователей Системы № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. ИТОГО зарегистрировано: Всего обращений (заявок): ________ ИТОГО решено: Всего обращений (заявок): ________ Приложение 2 к Отчету об оказанных услугах Журнал обращений (заявок) по решению инцидентов, связанных с работой ППО (шаблон) Наименование Исполнителя в этапе «наименование этапа» в период с ________________ по _______________ оказал(о) Услугу по решению инцидентов в объеме, указанном в Таблице 1. Таблица 1 - Журнал по решению инцидентов № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. ИТОГО зарегистрировано: Всего инцидентов: ________ ИТОГО решено: Всего инцидентов: ________ Приложение 3 к Отчету об оказанных услугах Журнал обращений (заявок) выполнения адаптационного, конфигурационного и коррекционного сопровождения Системы (шаблон) Журнал выполнения адаптации, конфигурации и коррекции Системы сформирован за этап «наименование этапа» в период с «__» _________ по «__» ____________ и представлен в таблице ниже (Таблица 1). Таблица 1 - Журнал выполнения адаптации, конфигурации и коррекции сопровождения Системы № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. Количество выполненных заявок за этап: ________ Приложение 4 к Отчету об оказанных услугах Журнал обращений (заявок) по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности (шаблон) Журнал обращений (заявок) по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности сформирован за этап «наименование этапа» в период с «__» _________ по «__» ____________ и представлен в таблице ниже (Таблица 1). Таблица 1 - Журнал выполнения заявок по устранению уязвимостей в ППО № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. Количество выполненных заявок за этап: ________ Термины и сокращения В настоящем регламенте используются следующие термины и сокращения на русском и английском языках: Термины/сокращения Полное наименование/описание БЗ (База знаний) База данных Системы регистрации обращений (заявок), созданная для сбора, хранения и поиска способов решения известных проблем в рамках Системы Жизненный цикл обращения (заявки) Совокупность статусов, по которым проходит обращение (заявка), и правила перехода обращения (заявки) из одного статуса в другой Заказчик ФГБУ «СИЦ Минтранса России» – Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» ЗНИ Запрос на изменение – тип заявки, предполагающий внесение изменений в прикладное программное обеспечение Системы ЗНО Запрос на обслуживание – тип заявки, предполагающий работы по предоставлению консультации, предоставление доступа к Системе или стандартизированные типовые изменения конфигураций Системы Инцидент Тип заявки, классифицируемый как нештатное событие в работе компонентов функциональных задач Системы, которое привело или может привести к нарушению или снижению качества функционирования Системы ИС Информационная система Исполнитель Организация, которая определяется по результатам конкурсных процедур Классификация Анализ и заполнение классификационных полей справочными значениями, определяющими последовательность действий и этапов жизненного цикла заявки, а также порядок рассмотрения заявок Консультация Разъяснения по алгоритму работы, требуемых настроек прикладного программного обеспечения и технологии обработки данных при работе с Системой, предоставление информации Маршрутизация Определение процесса движения обращения (заявки) в Системе управления заявками между уровнями технической поддержки и организационными структурами на уровнях поддержки путем назначения обращения (заявки) в соответствии с его классификацией и выставленным приоритетом Обращение (заявка) Устное или письменное обращение пользователя АСУ ТК с вопросом, касающимся работоспособности АСУ ТК, по одному из определённых каналов связи: электронная почта, Система регистрации обращений (заявок) Пользователь Инициатор обращения (заявки) или пользователь Системы ППО Прикладное программное обеспечение Предмет обращения Справочник, классифицирующий типовые запросы в Системе регистрации обращений (заявок), характерные для Системы, выбранное значение определяет маршрутизацию обращения (заявки) (группу ответственных сотрудников) Приоритизация Значение, определяющее время, очередность решения обращений (заявок), ресурсы, привлекаемые для решения обращений (заявок), . Приоритет устанавливается в соответствии с масштабом выявленной проблемы, которая привела или может привести к нарушению или снижению качества функционирования Системы Релиз Выпуск версии прикладного программного обеспечения Системы, от разработки до тестирования и планового обновления Системы на продуктивной среде для установки изменений, связанных с развитием/улучшением/оптимизацией Системы Система, АСУ ТК, Информационно-аналитическая система регулирования на транспорте Информационно-аналитическая система, предназначенная для автоматизации и информационно-аналитического обеспечения процессов управления развитием транспортного комплекса Российской Федерации, обеспечения публичности деятельности органов государственного управления транспортным комплексом, а также обеспечения процессов оказания государственных услуг в электронном виде в сфере транспорта СМЭВ Система межведомственного электронного взаимодействия СПО Системное программное обеспечение СРО Система регистрации обращений (заявок) Статус обращения (заявки) Текущее состояние обращения (заявки) в жизненном цикле процесса оказания технической поддержки Системы СУБД Система управления базами данных Таблица 1 - Типы обращений (заявок) Тип обращения (заявки) Описание Запрос на обслуживание Подготовка SQL запроса к СУБД для решения прикладной задачи и д р. – запрос на любое действие, не являющееся запросом информации и несовершенный на основе происшествия, прямо или косвенно влияющего на работу Системы Консультация (входит в тип обращения (заявки) «Запрос на обслуживание») «Где взять / куда обратиться...?», «Как сделать / выполнить…», «Как это работает…?» - запрос, имеющий своей целью получение информационной поддержки Инцидент Разбор ошибок/сбоев и подготовка материалов (корректировочных релизов, инструкций) для Заказчика для устранения ошибок/сбоев, которые приводят к частичному и полному нарушению работоспособности всех или отдельных функций ППО. Подготовка изменения и материалов, необходимых для проведения аварийно-восстановительных работ для возобновления работоспособности Системы. ЗНИ Подготовка изменений, связанных с изменением, улучшением/оптимизацией Системы и выводом новой модифицированной функциональности в штатном режиме. Подготовка изменений, связанных с модификацией существующих и/или реализация новых интеграционных механизмов для получения/обработки данных внешних систем. Подготовка изменений графического интерфейса по требованиям Заказчика 3.2 Участники технической поддержки, осуществляющие сопровождение обращений (заявок) Техническая поддержка Системы должна быть организована на трех уровнях: 1. Первый и второй уровни технической поддержки организуется Заказчиком. 2. Третий уровень технической поддержки организуется Исполнителем. Зона ответственности каждого уровня технической поддержки указана в Таблице 2. Таблица 2 - Зона ответственности каждого уровня технической поддержки Участники технической поддержки Описание Первый уровень технической поддержки (далее – 1-й уровень) Группа ответственных сотрудников 1-го уровня Заказчика, осуществляющая прием и первичную обработку обращений (заявок) (описание предмета обращения, первичная классификация и приоритизация, определение назначения, маршрутизация обращений (заявок) по назначению), руководствуется в своей работе настоящим Регламентом и БЗ, наполняемой 2-м уровнем поддержки, самостоятельно решает часть обращений (заявок), связанных с недостаточной квалификацией пользователей или настройками в рамках своей компетенции. В случае невозможности решения обращений (заявок) на 1-ом уровне ответственный сотрудник передает ее на 2-й уровень Второй уровень технической поддержки (далее – 2-й уровень) Группа ответственных сотрудников 2-го уровня Заказчика по установленным компетенциям (информационная безопасность, сопровождение и эксплуатация информационно-аналитических систем, развитие информационно-аналитических систем, техническая поддержка информационно-аналитических систем) отвечает за поддержание работоспособности Системы, обработку обращений (заявок) и их решение в регламентные сроки в соответствии с установленными приоритетами. Осуществляет информационно-консультационную поддержку пользователей Системы в рамках своей компетенции. Оказывает экспертную помощь ответственным сотрудникам 1-го уровня в части формирования БЗ, содержащей ответы на часто задаваемые вопросы пользователей, с целью передачи знаний, навыков и инструментария на 1-й уровень для ускорения решения обращений (заявок). В случае невозможности решения обращения (заявки) на 2-ом уровне ответственный сотрудник передает его на 3-й уровень. При выявлении необходимости изменений в ППО Системы инициирует формирование обращения (заявки) и направляет его на группу ответственных сотрудников 3-го уровня по соответствующему классификатору (ЗНО, ЗНИ, и т.д.) Уровень технической поддержки Организационно-структурная часть технической поддержки, имеющая определённые организационно-нормативными документами зоны ответственности, обязанности, а также временные нормативы, в течение которых эти обязательства должны выполняться либо эскалироваться на следующий уровень технической поддержки Услуги Услуги по технической поддержке Информационно-аналитической системы регулирования на транспорте АСУ ТК ФИО Фамилия, имя, отчество Эскалация Процедура повышения внимания к обращению (заявке) путем повышения его приоритета и/или передачи на следующий уровень технической поддержки, а также привлечение ролей, которые могут принимать решения без передачи на следующий уровень технической поддержки API Англ. Application Programming Interface — программный интерфейс приложения, интерфейс прикладного программирования — описание способов (набор классов, процедур, функций, структур или констант), которыми одна компьютерная программа может взаимодействовать с другой программой CVSS Англ. Common Vulnerability Scoring System - открытый стандарт, используемый для расчета количественных оценок уязвимости в безопасности компьютерной системы, обычно с целью понять приоритет ее исправления. В современном инструментарии информационной безопасности используется версия 3.0 и выше с дополнительными метриками к базовым оценкам ID Англ. Identifier – идентификатор, уникальный признак объекта, позволяющий отличать его от других объектов, то есть, идентифицировать SLA Англ. Service Level Agreement - утвержденные условия по обработке обращения (заявки) с установленными метриками времени, которые определяют пороговые значения для эскалации в зависимости от статуса обращения (заявки) (например, время реакции – время от регистрации до осуществления первичной обработки, время решения – время от регистрации обращения (заявки) до его решения и т.д.) SQL Англ. Structured Query Language — «язык структурированных запросов», — декларативный язык программирования, применяемый для создания, модификации и управления данными в реляционной базе данных, управляемой соответствующей СУБД 1 Общие сведения 1.1 Полное наименование Услуг Оказание услуг по технической поддержке Модуля СЦ АСУ ТК в 2026 году. 1.2 Предмет Регламента оказания услуг Требования Технического задания 2 Общие положения 2.1 Цель и задачи оказания услуг Целью технической поддержки Системы является обеспечение ее стабильного и безопасного функционирования и эксплуатации, предупреждение, выявление и устранение сбоев в работе Системы и минимизация их неблагоприятного влияния. Для достижения поставленной цели требуется решение следующих задач: 1. Обеспечение информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы. 2. Поддержание параметров функционирования ППО Системы, удовлетворяющих требованиям производственных процессов, включая их непрерывность. 3. Обеспечение бесперебойного функционирования ППО и своевременное устранение сбоев и аварийных ситуаций в Системе. 4. Своевременное устранение уязвимостей при выявлении таковых, в соответствии с требованиями к обеспечению информационной безопасности. 5. Адаптация, конфигурирование, коррекция программного обеспечения в соответствии с изменениями нормативно-правовой базы и запросами уполномоченных сотрудников органов государственной власти, включая выполнение процедур тестирования и участие в обновлениях ППО на стендах Заказчика. 6. Обеспечение сохранения работоспособности ППО в изменяемой среде эксплуатации. 7. Ведение документации по настоящему контракту и инициирование актуализации документации на Систему по результатам обработки запросов Заказчика и внесения соответствующих изменений в ППО Третий уровень технической поддержки (далее – 3-й уровень) Группа ответственных сотрудников Исполнителя, отвечающая за устранение сбоев и аварий, проведение информационно-консультационной поддержки пользователей Системы, проведение адаптации и конфигурирования Системы в объемах действующих контрактов на оказание технической поддержки 3.3 Перечень и описание статусов обращений (заявок) В Таблице 3 приведен перечень статусов обращений (заявок), действующий в СРО, и их описание. Таблица 3 - Перечень статусов обращений (заявок) и их описание Статус Описание Зарегистрирован Обращение (заявка) принято и зарегистрировано Направлен в группу Присваивается при назначении ответственными сотрудниками 1-го уровня группе ответственных сотрудников 2-го уровня по тематике обращения (заявки) после заполнения всей необходимой информации и полей обращения (заявки), а также при его передаче между группами 2-го уровня Передан в группу Присваивается при передаче обращения (заявки) ответственными сотрудниками 2-го уровня на группу ответственных сотрудников 3-го уровня Назначен Присваивается при назначении обращения (заявки) на ответственного сотрудника для его решения в рамках компетенции В работе Присваивается при приеме обращения (заявки) в работу ответственным сотрудником для его решения Решен Присваивается ответственным сотрудником, выполнившим работы по обращению (заявке) Закрыт Присваивается автоматически при решении запроса по обращению (заявке), а также отсутствии дополнительных запросов пользователя в соответствии с действующим SLA, или при подтверждении решения обращения (заявки) со стороны пользователя Запрос доп. информации Присваивается при необходимости запроса дополнительной информации и/или уточнения предмета обращения по обращению (заявке) у пользователя Ответ предоставлен Присваивается после ответа пользователем на запрос дополнительной информации Отклонен Присваивается, если обращение (заявка) не актуальна (по информации от пользователя), отсутствует техническая возможность решения обращения (заявки), предмет обращения не входит в компетенции технической поддержки, или существует влияние доработки на другие компоненты, что нарушает общий порядок работы Системы Согласование Присваивается при необходимости согласования направления обращения (заявки) ответственным сотрудником Заказчика на 3-й уровень Анализ Присваивается при проведении анализа на предмет возможности внесения изменений, связанных с развитием/улучшением/оптимизацией Системы и выводом новой функциональности и оценке ресурсоемкости Тестирование Присваивается Исполнителем при завершении разработки и проведенном предварительном тестировании для последующего осуществления приемочного тестирования Специалистом 2-го уровня Релиз Присваивается ответственным сотрудником Заказчика при принятии решения о возможности вывода доработки в продуктивную среду Утверждение заказчиком Присваивается при согласовании группой профильных специалистов на 2-м уровне поддержки с пользователем технического задания для внесения изменений, связанных с развитием/улучшением/оптимизацией Системы и выводом новой функциональности Доработка Присваивается в случае несогласования Заказчиком работ, проведенных Исполнителем в рамках контрактных обязательств, по внесению изменений, связанных с развитием/улучшением/оптимизацией Системы и выводом новой функциональности в штатном режиме, и необходимости последующего направления Исполнителю для ее доработки Отложен Присваивается в случае невозможности выполнения запроса, изложенного в обращении (заявке), в связи с необходимостью запроса дополнительной информации у третьих сторон Изменение приоритета уже зарегистрированного обращения (заявки) используется в случае появления новых обстоятельств, которые ведут к изменению влияния и/или срочности существующего обращения (заявки). При регистрации обращения (заявки) необходимо провести его приоритизацию. В процессе управления обращениями (заявками) каждому обращению (заявке) присваивается приоритет, принимающий одно из значений: Низкий, Средний, Высокий или Критический. В соответствии с приоритетом определяется время, очередность устранения, , ресурсы, привлекаемые для работ по обращению (заявке), а также может определяться порядок/процедура действий при работе с обращением (заявкой). Заказчиком в зависимости от уровня сбоя в работе Системы обращению (заявке) присваивается приоритет с указанием максимального времени реакции и решения в соответствии с требованиями, указанными в Приложении 2 к настоящему Регламенту 4 Формы обращений (заявок) на оказание услуг по технической поддержке Системы, заполняемые в СРО 4.1. Форма обращения (заявки) на оказание услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы При подаче обращения (заявки) типа «ЗНО» в СРО указывается (Таблица 5): Таблица 5 – Описание атрибутов формы обращения (заявки) на оказание услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 5) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 5) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 5) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 5) Категория обращения: информационно-консультационная поддержка Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 5) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 5) Текст запроса на оказание услуги по информационно-консультационной поддержке сотрудников Заказчика Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 5) На рисунке 5 приведена форма обращения (заявки) типа «ЗНО» в СРО. Рисунок 5 - Форма обращения (заявки) типа «ЗНО» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы, заполненную в свободной форме. Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 8) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 8) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 8) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 8) Категория обращения (заявки): инцидент Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 8) Приоритет Время, очередность решения обращения (заявки), ресурсы, привлекаемые для решения обращения (заявки), порядок/процедура действий при решении обращения (заявки) – поле СРО «Приоритет» (см. рисунок 8) Тип изменения Справочник, классифицирующий типовые запросы характерные для Системы – поле СРО «Предмет обращения» (см. рисунок 8) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 8) Текст запроса на оказание услуги по обновлению или удалению уязвимых компонентов (библиотек) ППО в соответствии с требованиями к обеспечению информационной безопасности Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 8) На рисунке 8 приведена форма обращения (заявки) типа «Инцидент» в СРО. Рисунок 8 - Форма обращения (заявки) типа «Инцидент» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуги по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности, заполненную в свободной форме Приложение 1 к Регламенту Матрица ответственных за взаимодействия в рамках выполнения работ по техническому сопровождению Системы Таблица 1 – Ответственные за взаимодействия в рамках выполнения работ по техническому сопровождению Системы со стороны Исполнителя ФИО Должность Адрес электронной почты Телефон — — — Общий контакт Приложение 2 к Регламенту Приоритеты и регламентные сроки решения обращений (заявок) Приоритеты и регламентные сроки решения обращений (заявок) приведены в таблице 1. Таблица 1 – Приоритеты и регламентные сроки решения обращений (заявок) № п/п Приоритет Максимальное время реагирования Время решения (срок выполнения) Описание приоритета По информационно-консультационной поддержке сотрудников Заказчика и пользователей Системы 1 – не более 1 часа не более 10 часов – Приложение Д Форма Протокола проверки результатов организационно-штатных и подготовительных мероприятий (шаблон) Протокол проверки результатов организационно-штатных и подготовительных мероприятий Настоящий Протокол содержит результаты проверки организационно-штатных и подготовительных мероприятий, проведенных Исполнителем (Таблица Д.1). Таблица Д.1. Протокол проверки результатов № Мероприятия Подготовительного этапа Результат проверки 1. Определить и направить Заказчику документ «Ответственные за взаимодействия в рамках выполнения работ по техническому сопровождению Системы со стороны Исполнителя». Документ содержит контактную информацию (ФИО, должность, адрес электронной рабочей почты, номер телефона) не менее чем о 2 лицах, ответственных за оказание услуг со стороны Подрядчика Выполнено/Не выполнено 2. Обеспечить подключение специалистов Подрядчика к Системе Выполнено/Не выполнено 3. Обеспечить подключение специалистов Подрядчика к СРО Выполнено/Не выполнено Заказчик Подрядчик /Должность/ /Должность/ ____________________ /Ф.И.О/ ___________________ /Ф.И.О/ М.П. М.П. «_____»_______________________202_г. «_____»_______________________202_г 2.2 Общее описание процесса оказания сопровождения (технической поддержки) Системы Процесс оказания технической поддержки Системы включает: 1. Поступление обращений (заявок) от пользователей и их регистрацию. 2. Сопровождение обращений (заявок) в соответствии с их классификацией и приоритизацией, в том числе, с их последующей эскалацией. 3. Определение ролей и регламент их взаимодействия при осуществлении деятельности по процессу. 4. Решение обращений (заявок) в установленные настоящим Регламентом сроки. 5. Взаимодействие между 1-м, 2-м и 3-м уровнями технической поддержки, в том числе, с формированием заданий для сопровождения Системы. 6. Контроль качества выполняемых Исполнителем работ, состоящий из проверки сценария, приводящего к ошибке, зафиксированной в Инциденте, и/или к ошибке воспроизведения, а также тестирование внесенных изменений в рамках ЗНИ. 7. Обеспечение мониторинга и проведение анализа процесса обработки поступающих в техническую поддержку обращений (заявок). Техническая поддержка реализуется путем проведения ответственными сотрудниками соответствующей информационно-консультационной деятельности в соответствии с определенными ролями, а также выполнения Исполнителем конкретных действий по своевременному выявлению причин сбоев и аварийных ситуаций и их устранению, а также по адаптации, конфигурированию, корректировке Системы, включая выполнение процедур тестирования и участия в обновлениях Системы. Все роли подразделяются на уровни поддержки, взаимодействующие между собой в соответствии с блок-схемой процесса технической поддержки. Общая схема процесса рассмотрения обращений (заявок) в соответствии с видами технической поддержки представлена на рисунке 1. . Рисунок 1 - Общая схема процесса рассмотрения обращений (заявок) в соответствии с видами технической поддержки 2.3 Каналы связи Должна быть предусмотрена омниканальность в части приема обращений (заявок). Получение обращений (заявок) технической поддержкой происходит по следующим каналам связи: – СРО; – электронная почта; – телефонная линия. Исполнитель обеспечивает прием обращений (заявок) от Заказчика и предоставляет информацию в рамках оказания услуг по техническому сопровождению Системы, руководствуясь матрицей взаимодействия, приведенной в Приложении 1 к настоящему Регламенту 3 Порядок оказания Услуг 3.1 Типы обращений (заявок) Обращения и заявки Заказчика классифицируются в соответствии с приоритетами и регламентными сроками, указанными в Приложении 2 к настоящему Регламенту. Регистрация обращений и заявок предусматривает создание новой записи в СРО с присвоением поступившему обращению или заявке (новой записи) уникального идентификатора. Запись в СРО должна содержать вопрос или проблему, которую требуется решить или оказать консультацию. Если обращение или заявка автоматически зарегистрированы в СРО при отправке представителем Заказчика, Исполнитель проверяет корректность указанного типа обращения (заявки) и может обратиться к Заказчику с просьбой корректировки, предоставив обоснования в соответствии с настоящей классификацией (Таблица 1) 3.4 Порядок регистрации и сопровождения Заявок Порядок регистрации и сопровождения обращений (заявок) в рамках оказываемых услуг по технической поддержке Системы зависит от типа обращения (заявки): 1. Услуга по решению инцидентов, связанных с работой ППО – тип обращения (заявки) «Инцидент». 2. Услуга по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности – тип обращения (заявки) «Инцидент». 3. Услуга информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы – тип обращения (заявки) «Запрос на обслуживание» (в том числе, консультационный запрос). 4. Услуга адаптационного, конфигурационного и коррекционного сопровождения Системы (в рамках действующих программных модулей и функциональностей) – тип обращения (заявки) «Запрос на изменение». В случае недоступности СРО взаимодействие и информирование Исполнителем о ходе оказания услуги по обращению (заявке), изменению статусов обращений (заявок) осуществляется по согласованию с Заказчиком в соответствии с матрицей взаимодействия, представленной в Приложении 1 к настоящему Регламенту. 3.4.1 Инцидент На рисунке 2 представлена функциональная схема регистрации и сопровождения обращений (заявок) типа «Инцидент». Рисунок 2 - Функциональная схема регистрации и сопровождения обращений (заявок) типа «Инцидент» 3.4.2 Запрос на обслуживание На рисунке 3 представлена функциональная схема регистрации и сопровождения обращения (заявки) типа «ЗНО». Рисунок 3 - Функциональная схема регистрации и сопровождения обращения (заявки) типа «ЗНО» 3.4.3 Запрос на изменение На рисунке 4 представлена функциональная схема регистрации и сопровождения обращений (заявок) типа «ЗНИ». Рисунок 4 - Функциональная схема регистрации и сопровождения обращений (заявок) типа «ЗНИ» 3.5 Порядок классификации и приоритизации обращений (заявок) Классификация является начальной стадией процесса оказания технической поддержки, необходимой для идентификации обращения (заявки) и определения соответствующих действий для его обработки. Для проведения первичной классификации необходимо получить от пользователя и зафиксировать в описании обращения (заявки) подробные сведения о сути запроса, в том числе, для Инцидентов зафиксировать сценарий воспроизведения обнаруженной ошибки. Для проведения вторичной классификации необходимо провести анализ и диагностику для определения корневой причины и затронутой Инцидентом функциональной области (инфраструктура, сеть, ППО). В процессе классификации осуществляется первичная диагностика и оценка проблемы, описанной пользователем Системы в обращении (заявке), в части функционирования и/или удобства использования Системы. Корректная классификация позволяет увеличить скорость обработки обращения (заявки) и решения описанной в обращении (заявке) проблемы при минимальном привлечении ресурсов, в частности, за счет использования известных решений для типовых обращений (заявок), которые должны описываться в БЗ СРО. Классификация позволяет произвести первоначальное назначение обращения (заявки) на ответственного сотрудника и выставить приоритет с учетом приоритизации. Приоритизация применяется для определения критичности описанной в обращении (заявке) проблемы для функционирования ППО Системы. Приоритет рассмотрения обращения (заявки) определяется в процессе ее классификации на основании ряда параметров, вводимых при заполнении обращения (заявки). Приоритизация используется для того, чтобы при одновременном наличии нескольких обращений (заявок) в первую очередь рассматривалась обращения (заявки) с наивысшим приоритетом и не позднее установленных для данного приоритета сроков 4.2. Форма обращения (заявки) на оказание услуги по решению инцидентов, связанных с работой ППО При подаче обращения (заявки) типа «Инцидент» в СРО указывается (Таблица 6): Таблица 6 – Описание атрибутов формы обращения (заявки) на оказание услуги по решению инцидентов, связанных с работой ППО Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 6) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 6) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 6,) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 6) Категория обращения (заявки): инцидент Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 6) Приоритет изменения Время - одно из значений: Низкий, Средний, Высокий или Критический. Определяет, очередность решения обращения (заявки), ресурсы, привлекаемые для решения обращения (заявки), порядок/процедура действий при решении обращения (заявки) – поле СРО «Приоритет» (см. рисунок 6,) Тип изменения Справочник, классифицирующий типовые запросы характерные для Системы – поле СРО «Предмет обращения» (см. рисунок 6) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 6) Полное описание инцидента, включая скриншоты и описание шагов, приведших к неисправности Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 6) Однократность/неоднократность Круг пользователей или компьютеров, затронутых данным инцидентом Действия, предпринятые для самостоятельного решения инцидента (при наличии) Версии используемого программного обеспечения на клиентской рабочей станции, где воспроизводится ошибка (операционная система, прикладное программное обеспечение) Дополнительная информация На рисунке 6 приведена форма обращения (заявки) типа «Инцидент» в СРО. Рисунок 6 - Форма обращения (заявки) типа «Инцидент» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуги по решению инцидентов, связанных с работой ППО, заполненную в свободной форме По решению инцидентов, связанных с работой ППО 1 Критический не более 30 минут не более 4 часов – полная недоступность ППО; – недоступность ключевых функций; – ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО; – невозможность информационного обмена с ППО для ИС более 4 часов 2 Высокий не более 1 часа не более 8 часов – ошибки/сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; – снижение быстродействия СПО (время отклика ППО на операции превышает 30 секунд); – невозможность управления правами и ролями пользователей 3 Средний не более 4 часов не более 24 часов – невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым недоступность функции формирования отчетов 4 Низкий не более 8 часов не более 40 часов – отклонение в работе ППО, не влияющее на корректную работу функций; – другие сбои и ошибки, затрагивающие основные функции ППО По адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) 1 Критический не более 40 минут не более 8 часов – изменения необходимые при проведении аварийно-восстановительных работ для возобновления работоспособности Системы; – изменения, связанные с критичными ошибками, блокирующими возможность оказания государственных услуг и/или чтение и внесение данных в Систему 2 Высокий не более 1 часа не более 40 часов – изменения относящиеся к обеспечению работоспособности основной функциональности Системы, устраняют выявленные дефекты в работе Системы, оказывающие существенное влияние на процесс оказания государственных услуг и работу пользователей в Системе; – изменения, затрагивающие три и более подсистемы/модуля Системы для адаптации 3 Средний не более 4 часов не более 72 часов – изменения, связанные с развитием/улучшением/оптимизацией Системы и выводом новой функциональности в штатном режиме для одного-двух модулей/подсистем; – изменения, связанные с развитием интеграционных механизмов Системы, например, обновление существующих и/или реализация новых видов сведений СМЭВ, обновление существующих и/или реализация новых API, адаптация и/или изменение механизмов импорта и экспорта данных Системы и т.д. 4 Низкий не более 8 часов не более 160 часов – изменения, связанные с ошибками/ корректировкой/изменение в отображении информации в пользовательском графическом интерфейсе Системы (графика, текст, органы управления, элементы интерфейса) По устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности 1 Критический не более 30 минут не более 24 часов – критические уязвимости, влияющие на возможную полную недоступность ППО, ключевых функций Системы, ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО без возможности восстановления работоспособности Системы; – Критический уровень CVSS > 8.0 2 Высокий не более 1 часа не более 84 часов – критические уязвимости, влияющие на ошибки и сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; – Высокий уровень CVSS 5.0 - 8.0 3 Средний не более 4 часов не более 120 часов – уязвимости, влияющие на невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым; – Средний уровень CVSS 2.0 - 4.9 4 Низкий не более 8 часов не более 160 часов – уязвимости, влияющие на отклонение в работе ППО, не влияющее на корректную работу функций; – другие сбои и ошибки, затрагивающие основные функции ППО; – Низкий уровень CVSS < 2.0 4.3. Форма обращения (заявки) на оказание услуг по адаптационному конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) При подаче обращения (заявки) типа «ЗНИ» в СРО указывается (Таблица 7): Таблица 7 – Описание атрибутов формы обращения (заявки) на оказание услуг по адаптационному, конфигурационному и коррекционному сопровождению Системы Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 10) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 9) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 10) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 10) Категория обращения (заявки): запрос на изменение Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 7) Приоритет изменения Время, очередность решения обращения (заявки), ресурсы, привлекаемые для решения обращения (заявки), порядок/процедура действий при решении обращения (заявки) – поле СРО «Приоритет» (см. рисунок 7) Тип изменения Справочник, классифицирующий типовые запросы характерные для Системы – поле СРО «Предмет обращения» (см. рисунок 7) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 7) Текст запроса на оказание услуги по адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 7) На рисунке 7 приведена форма обращения (заявки) типа «ЗНИ» в СРО. Рисунок 7 - Форма обращения (заявки) типа «ЗНИ» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуг по адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей), заполненную в свободной форме 4.4. Форма обращения (заявки) на оказание услуги по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности При подаче обращения (заявки) типа «Инцидент» в СРО указывается (Таблица 8): Таблица 8 – Описание атрибутов формы обращения (заявки) на оказание услуг по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности - Наименование характеристики - Значение характеристики - Единица измерения характеристики - Инструкция по заполнению характеристик в заявке - ОПРЕДЕЛЕНИЯ, ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ - Модуль iМинтранс Модуль сбора данных и представления показателей деятельности Министерства транспорта Российской Федерации iМинтранс АСУ ТК Модуль СЦ Модуль сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК НС Нештатная ситуация НСИ Нормативно-справочная информация ОТИ Объект транспортной инфраструктуры П-ГИС Геоинформационная подсистема П-ИВ Подсистема информационного взаимодействия П-НСИ Подсистема ведения нормативно-справочной информации и метаданных ПО Программное обеспечение Подрядчик, Исполнитель Организация, с которой будет заключен контракт на выполнение работ по развитию Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК П-СД Подсистема сбора данных Работы Работы по развитию Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК СЗИ Средство защиты информации СМЭВ Система межведомственного электронного взаимодействия СУБД Система управления базами данных ТЗ Техническое задание (настоящий документ) ТС Транспортное средство ТК Транспортный комплекс Учреждение Учреждения в области информационной безопасности - - Значение характеристики не может изменяться участником закупки - ФГБУ «СИЦ Минтранса России» Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации», Заказчик Федеральный закон № 44-ФЗ Федеральный закон от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» ФЗ Функциональная задача ФЗ «Реестр объектов» Функциональная задача «Формирование и ведение единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации» ФСБ России Федеральная служба безопасности Российской Федерации ФСТЭК России Федеральная служба по техническому и экспортному контролю ЧС Чрезвычайная ситуация ЭВМ Электронно-вычислительная машина API От англ. Application Programming Interface – интерфейс прикладного программирования – совокупность инструментов и функций в виде интерфейса для взаимодействия с программой CSS От англ. Cascading Style Sheets — каскадные таблицы стилей FPS От англ. frame per second - количество кадров в секунду HTML От англ. HyperText Markup Language - стандартный язык разметки документов, создающий основу и структуру всех веб-страниц JSON От англ. JavaScript Object Notation – текстовый формат обмена данными, основанный на JavaScript WebAssembly (Wasm) Открытый стандарт, представляющий собой низкоуровневый бинарный формат инструкций, который позволяет выполнять код, написанный на языках C++, Rust или Go, в браузерах с производительностью, близкой к нативной - Автоматизированная система (АС) Система, состоящая из комплекса средств автоматизации, реализующего информационную технологию выполнения установленных функций, и персонала, обеспечивающего его функционирование (ГОСТ Р 59853-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения») АРМ Автоматизированное рабочее место АСУ ТК, Система Информационно-аналитическая система регулирования на транспорте АТС Автоматическая телефонная станция БД База данных ГИС Государственная информационная система ГОСТ Государственный стандарт ГЦОД СИЦ Минтранса России, ГЦОД Головной центр обработки данных ФГБУ «СИЦ Минтранса России» Дашборд Интерактивная аналитическая панель, графический интерфейс. ЕИС Единая информационная система в сфере закупок ЕСИА Единая система идентификации и аутентификации Заказчик Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» КИИ Критическая информационная инфраструктура Кластер Кла?стер (англ. cluster) – объединение нескольких однородных элементов, которое может рассматриваться как самостоятельная единица, обладающая определёнными свойствами Компонент Часть АС, выделенная по определенному признаку или совокупности признаков и рассматриваемая как единое целое (ГОСТ Р 59853-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения») Контракт Контракт на выполнение работ по развитию и оказанию услуг по технической поддержке Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК в 2026 году, заключаемый по результатам проведения конкурентной процедуры закупки в соответствии с требованиями Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» - 1. ОБЩИЕ СВЕДЕНИЯ - 1.1. Наименование Системы Полное наименование системы: Информационно-аналитическая система регулирования на транспорте. Условное обозначение системы: АСУ ТК. Полное наименование модуля: Модуль сбора, ведения и анализа информации о нештатных ситуациях на транспорте. Условное обозначение модуля: Модуль СЦ. Модуль СЦ создан в рамках контракта от 05.08.2024 № ОК/24_04 на выполнение работ по развитию АСУ ТК в части создания модуля «Сбора, ведения и анализа информации о нештатных ситуациях на транспорте». Развитие Модуля СЦ осуществлено в рамках контракта от 19.05.2025 № ОК/25_09 на выполнение работ по развитию Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК - - Значение характеристики не может изменяться участником закупки - – ГОСТ Р 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.7. Сроки начала и окончания работ Начало работ: с даты заключения Контракта. Окончание работ: не позднее 15.12.2026. Работы выполняются в соответствии с этапами. Сроки выполнения этапов работ по развитию и технической поддержке Модуля СЦ определяются Календарным планом. Календарный план, приведен в разделе 5 настоящего ТЗ - 1.2. Шифр темы или номер контракта Присваивается Заказчиком по результатам организации закупочных процедур. 1.2.1. Предмет контракта Выполнение работ по развитию Модуля СЦ. Код по ОКПД2: 62.01.11.000 – услуги по проектированию и разработке информационных технологий для прикладных задач и тестированию программного обеспечения. Оказание услуг по технической поддержке Модуля СЦ. Код по ОКПД2: 62.02.30.000 – услуги по технической поддержке информационных технологий. Выполнение работ по развитию Модуля СЦ предусмотрено с учетом ключевых результатов (ОКР) Ведомственной программы цифровой трансформации Минтранса России на 2026-2028 (далее - ВПЦТ Минтранса России) в составе мероприятия № 103.002 «АСУ ТК» ИТ расхода 103.26.000005 «Развитие Информационно-аналитической системы регулирования на транспорте (АСУ ТК)»: · «Обеспечено информационное взаимодействие с Минобороны о происшествиях на транспортных объектах»; · «Обеспечена автоматизация формирования отчетов о нештатных ситуациях на транспорте, в том числе по данным внешних систем». Выполнение работ по технической поддержке АСУ ТК предусмотрено ВПЦТ Минтранса России в составе мероприятия № 103.002 «АСУ ТК» ИТ расхода 103.26.000021 «Эксплуатация Информационно-аналитической системы регулирования на транспорте (АСУ ТК)» - 1.3. Заказчик Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» (ФГБУ «СИЦ Минтранса России»). Адрес: 107078, Москва, Садовая-Спасская ул., д.18, стр. 1. Оператором Системы является Заказчик - Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» (ФГБУ «СИЦ Минтранса России) - 1.4. Подрядчик Определяется по результатам проведения конкурентной процедуры закупки в соответствии с требованиями Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (далее – Федеральный закон № 44-ФЗ) - 1.5. Основания для выполнения работ Работы осуществляются на основании следующих документов: – постановление Правительства Российской Федерации от 30.12.2003 № 794 «О единой государственной системе предупреждения и ликвидации чрезвычайных ситуаций»; – постановление Правительства Российской Федерации от 08.11.2013 № 1007 «О силах и средствах единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций»; – распоряжение Правительства Российской Федерации от 27.11.2021 № 3363-р «О Транспортной стратегии Российской Федерации до 2030 года с прогнозом на период до 2035 года»; – Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 26.08.2025 №ЕФ-3; – Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 27.11.2025 №ЕФ-23; - 1.8. Общие сведения об источниках и порядке финансирования работ Источником финансирования являются средства субсидии федерального бюджета Российской Федерации, предоставленной в соответствии с абзацем вторым пункта 1 статьи 78.1 Бюджетного кодекса Российской Федерации (код цели 08-01) - 1.9. Порядок оформления и предъявления результатов работ Подрядчик должен передать Заказчику результаты работ в порядке, определенном Контрактом в сроки, установленные п. 5 настоящего ТЗ, в соответствии с Календарным планом - 1.10. Место выполнения Работ Работы выполняются удаленно на комплексе технических средств Заказчика. Адрес размещения комплекса технических средств Заказчика: Московская обл., Богородский район, пос. Горбуша, Радиоцентр. Техническая возможность удаленного подключения обеспечивается Заказчиком (в части предоставления параметров доступа). Оплата телематических и иных услуг, технических и программных средств, необходимых Подрядчику для удаленного подключения и для выполнения требований по информационной безопасности, осуществляется Подрядчиком самостоятельно за свой счет - – Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 19.02.2026 №ЕФ-1; – План мероприятий по профилактике случаев непроизводственного травматизма граждан на железнодорожном транспорте, являющийся приложением к постановлению коллегии Министерства транспорта Российской Федерации от 11.03.2026 № 2 - 1.6. Перечень документов, требования которых должны быть учтены при выполнении работ – Федеральный закон Российской Федерации от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации»; – Федеральный закон Российской Федерации от 27.07.2006 № 152-ФЗ «О персональных данных»; – Федеральный закон Российской Федерации от 06.04.2011 № 63-ФЗ «Об электронной подписи»; – Федеральный закон Российской Федерации от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации»; – Указ Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации»; – Указ Президента Российской Федерации от 01.05.2022 № 250 «О дополнительных мерах по обеспечению информационной безопасности Российской Федерации»; – Указ Президента Российской Федерации от 31.03.2010 № 403 «О создании комплексной системы обеспечения безопасности населения на транспорте»; – постановление Правительства Российской Федерации от 30.07.2004 № 395 «Об утверждении Положения о Министерстве транспорта Российской Федерации»; – постановление Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации»; – постановление Правительства Российской Федерации от 16.11.2015 № 1236 «Об установлении запрета на допуск программного обеспечения, происходящего из иностранных государств, для целей осуществления закупок для обеспечения государственных и муниципальных нужд»; – постановление Правительства Российской Федерации от 23.12.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 Федерального закона «Об электронной подписи»; - – постановление Правительства Российской Федерации от 08.06.2011 № 451 «Об инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг и исполнения государственных и муниципальных функций в электронной форме»; – постановление Правительства Российской Федерации от 30.01.2013 № 62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин»; – приказ ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации»; – приказ ФСТЭК России от 11.04.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений»; – приказ ФСБ России от 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 «Национальный стандарт Российской Федерации. Интеллектуальная собственность. Патентные исследования. Содержание и порядок проведения»; - 2. ЦЕЛИ И НАЗНАЧЕНИЕ ВЫПОЛНЕНИЯ РАБОТ - 2.1. Назначение АСУ ТК АСУ ТК предназначена для автоматизации и информационно-аналитического обеспечения процессов управления развитием транспортного комплекса Российской Федерации, обеспечения публичности деятельности органов государственного управления транспортным комплексом. Основными целями АСУ ТК являются: – повышение эффективности процессов управления функционированием и развитием транспортного комплекса на основе создания единой информационной среды и комплекса информационно-аналитических услуг на уровне органов государственного управления ТК; – повышение уровня безопасности ТК на базе получения полной, достоверной и оперативной информации о происходящих изменениях, своевременного выявления негативных тенденций и для принятия соответствующих мер по их устранению и ликвидации последствий - - Значение характеристики не может изменяться участником закупки - Основными задачами АСУ ТК являются: – автоматизация процессов прогнозирования развития транспортного комплекса и поддержки принятия управленческих решений; – автоматизация процессов мониторинга безопасности и устойчивости транспортного комплекса, управления в чрезвычайных и нештатных ситуациях; – автоматизация процессов управления программами и проектами развития и модернизации транспортного комплекса; – автоматизация процессов мониторинга состояния транспортного комплекса, в том числе с использованием набора ключевых показателей эффективности деятельности транспортного комплекса; – информационно-технологическая поддержка взаимодействия субъектов транспортного комплекса Российской Федерации, органов государственного управления и контроля, международных организаций на основе создания единой технологической среды взаимодействия и управления движением данных (и связанных с ними документов) в транспортном комплексе; – использование в процессах управления транспортным комплексом РФ современных технологий электронного документооборота и электронного обмена данными; – организация межведомственного электронного взаимодействия подразделений Министерства транспорта Российской Федерации, подведомственных агентств и службы с другими организациями - 2.2. Назначение и цели развития и технической поддержки Модуля СЦ Назначение Модуля СЦ: – оперативный мониторинг нештатных и чрезвычайных ситуаций на транспорте ; – оповещение заинтересованных лиц и структур о нештатных и чрезвычайных ситуациях; – сбор, обработка и хранение данных о нештатных и чрезвычайных ситуациях. Целями развития Модуля СЦ являются: – расширение состава данных об оперативной обстановке на транспорте; – оптимизация процесса сбора данных об оперативной обстановке на транспорте; – повышение информированности пользователей за счет визуализация данных Модуля СЦ; – автоматизация процесса формирования отчетов о ЧС и нештатной ситуации на транспорте; – обеспечение информационного взаимодействия с заинтересованными организациями по вопросам ведения. - Целями оказания услуг по технической поддержке являются: – обеспечение информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы; – поддержание параметров функционирования ППО Системы, удовлетворяющих требованиям производственных процессов, включая их непрерывность; – обеспечение бесперебойного функционирования ППО и своевременное устранение сбоев и аварийных ситуаций в Системе; – своевременное устранение уязвимостей при выявлении таковых, в соответствии с требованиями к обеспечению информационной безопасности; – адаптация, конфигурирование, коррекция программного обеспечения в соответствии с изменениями нормативно-правовой базы и запросами уполномоченных сотрудников органов государственной власти, включая выполнение процедур тестирования и участие в обновлениях ППО на стендах Заказчика; – обеспечение сохранения работоспособности ППО в изменяемой среде эксплуатации; – ведение документации по настоящему ТЗ, инициирование и актуализация документации на Систему по результатам обработки запросов Заказчика и внесении соответствующих изменений в ППО. Модуль СЦ применяется в деятельности Министерства транспорта Российской Федерации, подведомственных агентств и службы и другими организациями в соответствии с соглашениями об информационном обмене - 3. ХАРАКТЕРИСТИКА ОБЪЕКТА АВТОМАТИЗАЦИИ - 3.3. Состав используемого ПО Модуля СЦ Программная архитектура Модуля СЦ разработана как трехуровневая клиент-серверная архитектура. Архитектура включает в себя следующие уровни: • уровень представления – презентационный уровень, обеспечивающий взаимодействие с пользователя с клиентскими приложениями с использованием веб-браузера («тонкий» клиент); • уровень приложений – реализован в виде сервисов, обеспечивает обработку запросов, поступающих от клиентских приложений, формирование ответов на запрос в доступном пользователю виде (формирование пользовательских интерфейсов); • уровень хранения данных – реализуется как сервер БД и обеспечивает хранение и целостность хранимых данных, создание резервных копий, ведение журнала транзакций, восстановление данных после сбоев. Программная архитектура Модуля СЦ включает в себя сервисы и интерфейсы, указанные в Таблице 3. Таблица 3. Программная архитектура Модуля СЦ Программный сервис/интерфейс Технологии реализации Уровень представления Интерфейс пользователя и администратора (front-end) Javascript Уровень приложений Сервис (GateWay) Kotlin Сервис геокодирования (geocoding-service) Kotlin Сервис уведомлений (notifiсation-service) Kotlin Сервис работы с файлами (file-service) Kotlin Сервис отчетности (report-service) Kotlin Сервис управления событиями (event-service) Kotlin Сервис информирования через мессенджер (messenger-notifier) Python Сервис внешних интеграций (integration-service) Сбор информации из внешних систем и сервисов Брокер сообщений Kafka Уровень хранения данных Файловое хранилище MinIO S3 СУБД Postgres Pro Enterprise - - Значение характеристики не может изменяться участником закупки - 3.4. Информационное взаимодействие программных сервисов и интерфейсов Модуля СЦ Объект автоматизации функционирует в распределенной информационной среде. Обмен данными осуществляется по защищенным каналам связи (в том числе ведомственным сетям передачи данных). Источники информации включают: · внешние автоматизированные системы (органов государственной власти); · внутренние базы данных (реестры объектов транспортной инфраструктуры, паспорта регионов и пр.); · оперативная информация от персонала, поступающая через автоматизированные рабочие места (АРМ) и мобильные устройства. 3.4.1. Взаимодействие Модуля СЦ со смежными подсистемами АСУ ТК Модуль СЦ входит в состав АСУ ТК и взаимодействует со следующими ее функциональными задачами и подсистемами: · Функциональной задачей «Формирование и ведение единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации» (ФЗ «Реестр объектов»); · Геоинформационной подсистемой АСУ ТК (П-ГИС); · Подсистемой ведения нормативно-справочной информации и метаданных (П-НСИ); · Подсистемой сбора данных и централизованное хранилище данных (П-СД); · Подсистемой информационного взаимодействия (П-ИВ). 3.4.2. Взаимодействие с внешними информационными системами Список внешних информационных систем, с которыми осуществляется взаимодействие Модуля СЦ: · ЕСИА; · мессенджер; · Яндекс Геокодер; · Информационная система «Централизованная система сбора информации систем-112»; · ПВК «Поиск-Море», АИС РПТ; · облачная АТС - 3.5. Требования к эксплуатации Применяемое в Системе программное обеспечение, программно-аппаратные и аппаратные комплексы должны соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации» - 3.1. Описание объекта автоматизации АСУ ТК Объектом автоматизации являются процессы основной и обеспечивающей деятельности, направленные на управление транспортным комплексом, в том числе, процессы информационного взаимодействия с другими организациями и субъектами транспортного комплекса. АСУ ТК относится к государственным информационным системам, а также к информационным системам персональных данных и значимым объектам критической информационной инфраструктуры Российской Федерации. АСУ ТК соответствует требованиям, предъявляемым к: – ГИС второго класса защищенности в соответствии с приказом ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах»; – ИС персональных данных при обеспечении третьего уровня защищенности персональных данных в соответствии с требованиями постановления Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»; – значимым объектам КИИ Российской Федерации второй категории значимости с постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении Правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений». Модуль СЦ является подсистемой АСУ ТК. Перечень платформенных решений и функциональных задач АСУ ТК представлен в Таблице 1 - Таблица 1 – Перечень платформенных решений и функциональных задач АСУ ТК № Наименование подсистемы/ функциональной задачи/ модуля Назначение 1 Подсистема сбора данных и централизованного хранилища данных Подсистема обеспечивает выполнение сбора данных в АСУ ТК, и в т. ч., в рамках функциональных задач «Формирование и ведение межрегионального транспортного баланса пассажирских перевозок в дальнем (межрегиональном) сообщении» и «Формирование и ведение транспортного паспорта региона» 2 Подсистема информационного взаимодействия Подсистема информационного предназначена для обеспечения информационного взаимодействия подсистем АСУ ТК, а также, взаимодействия АСУ ТК с АС федеральных органов исполнительной власти 3 Подсистема ведения нормативно-справочной информации и метаданных Подсистема предназначена для автоматизации функций формирования и актуализации справочников, классификаторов, реестров и регистров, необходимых для обеспечения информационной поддержки пользователей НСИ и интеграции подсистем АСУ ТК в части применения НСИ 4 Модуль СМЭВ Модуль взаимодействия со СМЭВ представляет собой набор сервисов взаимодействия: сервис синхронного взаимодействия и сервис отправки, осуществляющих дополнительную обработку сообщений, отправляемых в СМЭВ и принимаемых из СМЭВ 5 Геоинформационная подсистема Программное обеспечение геоинформационной подсистемы предназначено для обеспечения смежных подсистем АСУ ТК возможностью работы с картографической информацией, в том числе, отображения на электронных картах объектов транспортной инфраструктуры и получения информации о местоположении, характеристиках контролируемых транспортных объектов 6 Подсистема информационного портала АСУ ТК Подсистема информационного портала предназначена для отображения и входа в функциональные задачи АСУ ТК 7 Подсистема технического портала АСУ ТК Подсистема технического портала АСУ ТК предназначена для управления заявками пользователей и технологического документооборота заявок - 8 Подсистема проектного архива АСУ ТК Подсистема проектного архива АСУ ТК предназначена для автоматизации деловых процессов должностных лиц Министерства транспорта Российской Федерации, подведомственных агентств и службы, в том числе, и процессов информационного взаимодействия внутреннего и внешнего характера 9 ФЗ «Реестр объектов» Функциональная задача предназначена для формирования и ведения единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации 10 ФЗ «СТП» Функциональная задача предназначена для организации информационно-аналитической поддержки процессов территориального планирования Российской Федерации в области федерального транспорта 11 ФЗ «МРТБ ПП» Функциональная задача предназначена для формирования и ведения межрегионального транспортного баланса пассажирских перевозок в дальнем (межрегиональном) сообщении 12 ФЗ «МДД» Функциональная задача предназначена для осуществления мониторинга дорожного движения 13 ФЗ «ТПР» Функциональная задача предназначена для формирования и ведения транспортного паспорта региона 14 ФЗ «Данные по грузообороту» Функциональная задача предназначена для обеспечения подсистем и пользователей АСУ ТК данными по грузообороту между Российской Федерацией и зарубежными странами 15 ФЗ «МЖТ» Функциональная задача предназначена для осуществления мониторинга железнодорожного транспорта 16 ФЗ «МГМП» Функциональная задача предназначена для осуществления мониторинга грузопотоков в морских портах с целью формирования единой цифровой среды мониторинга и планирования перевозок в/из портов Дальнего Востока - 17 Модуль ГЭТ Модуль предназначен для получения, хранения данных инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по отдельно взятому предприятию-перевозчику. Формирования отчетов об инвентаризации с детальными данными по каждому разделу инвентаризации с маршрутизацией в муниципалитет / регион / Минтранс. Содержит агрегированные данные инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по всем перевозчикам, относящихся к данному муниципалитету. Формирует сводный отчет по муниципалитету по каждому разделу инвентаризации с маршрутизацией в регион / Минтранс. Формирует агрегированные данные инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по всем перевозчикам, относящиеся к данному региону и по всем муниципалитетам, относящимся к данному региону. Аналитические и статистические данные о состоянии ГЭТ региона. Содержит данные о видах транспорта, цифровых транспортных сервисах и платежных инструментах Региона. Формирует сводный отчет по каждому разделу инвентаризации с маршрутизацией в Минтранс. Формирует агрегированную статистику и аналитику по всем регионам страны в разрезе транспортных средств, маршрутов, пассажиропотоков, инфраструктуры ГЭТ. Данные о рейтинге регионов и перевозчиков на основании выбранных параметров, документооборот с участниками Системы: получение подписанных печатных форм, их утверждение, возврат на доработку. 18 Модуль iМинтранс Модуль создан для отчета по ключевым показателям транспортного комплекса России (Отраслевые и статистические показатели, исполнение бюджета, исполнение поручений, аналитика СМИ, происшествия по видам транспорта). 19 Модуль СЦ Модуль СЦ предназначен для оперативного мониторинга нештатных ситуаций транспортной отрасли, оповещения заинтересованных лиц и структур и предоставления данных о нештатных ситуациях - АСУ ТК осуществляет идентификацию и авторизацию посредством Единой системы идентификации и аутентификации (ЕСИА). Информационный обмен с внешними информационными системами осуществляется посредством СМЭВ 3 и СМЭВ 4. АСУ ТК развернута на вычислительных мощностях ГЦОД СИЦ Минтранса России - 3.2. Описание и текущее состояние объекта автоматизации Модуля СЦ Объектом автоматизации является процесс организации мониторинга информации о НС и ЧС на транспорте. Предметом деятельности Учреждения являются следующие функции: – информационное обеспечение в области транспортной безопасности, защиты населения и территорий от чрезвычайных ситуаций природного и техногенного характера в транспортном комплексе; – подготовка справочных материалов при угрозе возникновения и возникновении чрезвычайных ситуаций и иных происшествий в транспортном комплексе; – взаимодействие и обмен оперативной информацией с органами управления Единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций; – организация оперативного мониторинга обстановки на объектах транспорта при угрозе и возникновении чрезвычайных ситуаций и иных происшествий. Перечень компонентов Модуля СЦ и выполняемые ими функции представлены в Таблице 2 - Таблица 2. Перечень компонентов Модуля СЦ и их функции № п/п Компонент Выполняемые функции 1 Регистрация событий – ведение карточки события; – удаление комментария; – динамическое отображение существующих событий в заданном радиусе и за заданный период; – возможность автоматической проверки вводимых данных в части количества пострадавших; – отображение карточки ОТИ, ТС в соответствии с ФЗ Реестр объектов; – сохранение и отображение версии карточки события; – привязка события к координатам по картографической основе; – указание признака выполнения действия по отработке события; – перевод статуса события; – закрытие карточки события; – публикация информации о событии в канале мессенджера; – возможность перехода из карточки события на картографическую основу для просмотра местоположения события 2 Визуализация – отображение событий на картографической основе в виде пиктограмм; – масштабирование карты; – отображение краткой карточки события при выборе события на картографической основе; – отображение списка событий; – отображение карточки события; – отображение журнала действий пользователя; – отображение дополнительной информации (текстовая информация и приложенные файлы); – отображение справки о событиях и отчета о событиях; – отображение фильтров и количества отфильтрованных объектов; – отображение результатов поиска; – отображение статистики по событиям на экране; – возможность создания события с картографической основы; – отображения картографических слоев в зависимости от примененных фильтров; – возможность настройки шага картографической сети; – возможность настройки географической точки центра карты; – отображение количества непрочитанных сообщений; – возможность перехода к детальной карточке события из краткой карточки события при выборе события на картографической основе - 3 Информирование – ведение справочника способов оповещения (веб-интерфейс, мессенджер); – формирование сценария выполнения оповещения (настройка условий, способа, параметров оповещения); – выполнение оповещений пользователей 4 Отчетность – формирование отчета и справки о событиях; – фильтрация событий для выгрузки в справку о событиях или в отчет о событиях 5 Администрирование – ведение ролей пользователей; – ведение учетных данных пользователей; – ведение справочника организаций; – ведение справочника групп системы мгновенного обмена сообщениями; – выполнение исходящего звонка на контактный телефонный номер организации; – формирование матрицы эскалации событий Архитектура Модуля СЦ представлена на рисунке 1. Рисунок 1. Архитектура Модуля СЦ - 4. ТРЕБОВАНИЯ К МОДУЛЮ СЦ - 4.2.6. Взаимосвязи с внешними автоматизированными системами (1 очередь) Способы взаимодействия с внешними информационными системами должны быть определены на этапе технического проектирования. Должны быть выполнены следующие доработки: – интеграции с информационными ресурсами в целях получения данных о движении подвижных ТС (воздушные суда, суда водного транспорта); – интеграция с информационным ресурсом в целях получения данных о событиях на железнодорожном транспорте. Реализация интеграций должна включать проектирование и реализацию интеграционных механизмов обмена данными с учетом доступных вариантов реализации, обеспечение защищенных способов взаимодействия, настройку отображения отдельных данных на карте (настройка слоев). Взаимодействия, имеющие каналы связи, выходящие за пределы контролируемой зоны взаимодействующих систем, считаются защищенными, если для их защиты используются программные и/или программно-аппаратные шифровальные (криптографические) средства, сертифицированные ФСБ России (далее – СКЗИ). Выбор СКЗИ, схемы подключения и требуемого класса криптостойкости должен производиться в соответствии с Техническими условиями на подключение к информационным ресурсам ФГБУ «СИЦ Минтранса России» и инструкциями по подключению пользователей к ресурсам инфраструктуры Головного центра обработки данных, утвержденных приказом директора ФБГУ «СИЦ Минтранса России» от 24.05.2024 № 21-ОД - - Значение характеристики не может изменяться участником закупки - 4.3. Требования к оказанию услуг по технической поддержке Модуля СЦ 4.3.1. Общие требования к оказанию Услуг Техническая поддержка Модуля СЦ должна осуществляться с учетом требований постановления Правительства Российской Федерации от 06.07.2015 N 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации». Подрядчик обязан выполнять требования законодательства в сфере защиты информации, требования по защите информации, информационной безопасности, указанные в локальных нормативных актах ФГБУ «СИЦ Минтранса России», регламентирующих условия информационного взаимодействия, защиты информации и подключения к информационным ресурсам ФГБУ «СИЦ Минтранса России», участвующих в информационном взаимодействии в рамках оказания услуг по технической поддержке АСУ ТК в 2026 году - 4.3.1.1. Требования к составу и содержанию услуг третьего уровня технической поддержки Оказание услуг по технической поддержке Системы осуществляется в рамках этапов в соответствии с календарным планом. Подрядчик в течение 5 рабочих дней с даты заключения Контракта должен предоставить со своей стороны, а Заказчик со своей стороны Матрицу ответственных за взаимодействия в соответствии с Приложением 1 к Регламенту оказания услуг по третьему уровню технической поддержки Модуля СЦ (далее – Регламент, Приложение В). Подрядчик в течение 10 рабочих дней с даты заключения Контракта должен провести мероприятия по организации третьего уровня технической поддержки в соответствии с Регламентом. Услуги по третьему уровню технической поддержки Модуля СЦ должны включать: – организацию Подрядчиком третьего уровня технической поддержки; – информационно-консультационную поддержку работников Заказчика; – решение инцидентов, связанных с работой ППО; – адаптационное, конфигурационное и коррекционное сопровождение Модуля СЦ (в рамках действующих программных модулей и функциональности); – устранение уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности - Таблица 6. Категории обращений и заявок Категория Примеры Запрос на обслуживание Подготовка SQL запроса к СУБД для решения прикладной задачи и д.р. – запрос на любое действие, не являющееся запросом информации и несовершенный на основе происшествия, прямо или косвенно влияющего на работу Модуля СЦ Консультация «Где взять / куда обратиться...?», «Как сделать / выполнить…», «Как это работает…?» - запрос, имеющий своей целью получение информационной поддержки Инцидент Разбор ошибок/сбоев и подготовка материалов (корректировочных релизов, инструкций) для Заказчика для устранения ошибок/сбоев, которые приводят к частичному и полному нарушению работоспособности всех или отдельных функций ППО. Подготовка изменения и материалов, необходимых для проведения аварийно-восстановительных работ для возобновления работоспособности Модуля СЦ ЗНИ Подготовка изменений, связанных с изменением, улучшением/оптимизацией Модуля СЦ и выводом новой модифицированной функциональности в штатном режиме. Подготовка изменений, связанных с модификацией существующих и/или реализация новых интеграционных механизмов для получения/обработки данных внешних систем. Подготовка изменений графического интерфейса по требованиям Заказчика. Перечень статусов обращений (заявок) приведен в пункте 3.3. Регламента оказания Услуг. Назначение обращению (заявке) статуса «Закрыто» осуществляется Заказчиком только после получения от инициатора обращения (заявки) подтверждения о его исполнении или нахождения обращения (заявки) в статусе «Выполнено» и отсутствия повторных вопросов/запросов по данному обращению (заявки) в течение 5 рабочих дней. Категории и статусы обращений (заявок) могут быть скорректированы в процессе оказания услуг исключительно по согласованию с Заказчиком - 4.3.6. Требования к услугам технической поддержки 4.3.6.1. Требования к организации третьего уровня технической поддержки Основными задачами организации третьего уровня технической поддержки в рамках оказания услуг по технической поддержке Модуля СЦ являются организация эксплуатационной службы Подрядчика, проверка готовности технических и программных средств для обеспечения непрерывного функционирования ППО Модуля СЦ. Подрядчиком должны быть проведены организационно-штатные и подготовительные мероприятия (в т. ч. технические) в рамках организации технической поддержки Модуля СЦ. Подрядчик в течение 5 (пяти) рабочих дней с даты заключения Контракта должен: – определить и направить Заказчику документ «Перечень уполномоченных специалистов», содержащий контактную информацию (ФИО, должность, адрес рабочей электронной почты) лиц, ответственных за оказание услуг со стороны Подрядчика; – обеспечить подключение специалистов Подрядчика к Системе регистрации обращений (заявок) (СРО предоставляется Заказчиком) для оказания услуг; – согласовать с Заказчиком способ доступа Подрядчика к Модулю СЦ. Результат выполнения мероприятий фиксируется в Протоколе проверки результатов организационно-штатных и подготовительных мероприятий (см. Приложение Д к настоящему ТЗ) - 4.1. Требования к структуре Модуля СЦ В процессе работ по развитию Системы должны сохраниться основные требования к построению архитектуры Системы в соответствии с принципами трехуровневой архитектуры: 1. уровень хранения данных или уровень базы данных (сервер СУБД); 2. уровень сервера приложений (сервер аналитической обработки); 3. презентационный уровень, обеспечивающий взаимодействие с клиентскими приложениями. В состав Системы должны входить следующие основные компоненты: 4. сервер баз данных; 5. сервер приложений; 6. веб-сервер. Сервер баз данных должен обеспечивать хранение и целостность хранимых данных, создание резервных копий, ведение журнала транзакций, восстановление данных после сбоев. Сервер приложений должен обеспечивать обработку запросов, поступающих от клиентских приложений (через веб-сервер), формирование ответов на запрос в доступном пользователю виде (формирование пользовательских интерфейсов). Веб-сервер должен обеспечивать взаимодействие с оператором и внешними системами по HTTP / HTTPS протоколу в режиме «запрос-ответ» (получения запросов от пользователя и передачи ответа в виде соответствующей информации, обработанной серверами приложений). Взаимодействие Системы с пользователем должно отвечать требованиям модели «тонкого клиента» (т.е. представлять на стороне клиента (пользователя) лишь графический пользовательский интерфейс). Все составляющие Системы должны использовать единую методологию и отвечать единым принципам взаимодействия, надежности и управления. Перечень компонентов Модуля СЦ представлен в Таблице 4. Таблица 4. Перечень компонентов Модуля СЦ, в отношении которых выполняются работы по развитию № п.п. Наименование компонента Модуля СЦ Раздел ТЗ 1 Компонент регистрации событий 4.2.1. 2 Компонент отчетности 4.2.2 3 Компонент визуализации 4.2.3 4 «Интерактивная карта» (компонент создается) 4.2.4 5 Компонент администрирования 4.2.5 - 4.2. Требования к дорабатываемым функциям модуля СЦ 4.2.1. Развитие компонента регистрации событий (1 очередь) Должны быть выполнены следующие доработки: – обеспечение логирования действий пользователя, связанных с карточкой события; – доработка объектной модели в части создания новых типов сущностей (карточек) с учетом реализуемых интеграций с информационными ресурсами (силы и средства предупреждения и ликвидации ЧС и нештатных ситуаций на транспорте, ТС, ограничения воздушного пространства, неблагоприятные и опасные природные явления); – реализация механизма установления связи между сущностями в Модуле СЦ автоматизированным и ручным способами (события, природные явления, силы и средства предупреждения и ликвидации ЧС и нештатных ситуаций на транспорте, ограничения воздушного пространства, ОТИ, ТС и др.); – отображение в карточке установленных связей между сущностями. - 4.3.1.2. Требования к общему порядку оказания услуг Техническая поддержка Модуля СЦ должна быть организована на трех уровнях: – первый и второй уровни технической поддержки организуется Заказчиком; – третий уровень технической поддержки организуется Подрядчиком. Перечень действий на каждом уровне технической поддержки указан в Таблице 5: Таблица 5 – Перечень действий на каждом уровне технической поддержки Уровень технической поддержки Доступные действия Условия передачи задачи на следующий уровень Первый уровень технической поддержки (далее – 1-й уровень) – принимает обращения (заявки) пользователей Модуля СЦ и работников Заказчика; – регистрирует обращения в Модуле СЦ регистрации обращений; – присваивает уникальный идентификационный номер, классифицирует обращения; – самостоятельно решает обращения, которые связаны с недостаточной квалификацией пользователей или настройками в рамках своей компетенции; – взаимодействует с пользователями Модуля СЦ при решении проблемы Передает обращение на второй уровень поддержки в случае невозможности решения на своем уровне Второй уровень технической поддержки (далее – 2-й уровень) – принимает обращения от 1-го уровня; – уточняет классификацию обращения в результате дополнительного анализа; – самостоятельно решает обращения в рамках своей компетенции; – осуществляет техническую и консультационную поддержку Модуля СЦ; – взаимодействует с сотрудниками 1-го и 3-го уровня и пользователями Модуля СЦ; – формирует заявки для 3-го уровня и контролирует исполнение Передает обращение на третий уровень поддержки в случае невозможности решения на своем уровне Третий уровень технической поддержки (далее – 3-й уровень) – принимает обращения от 2-го уровня; – обеспечивает выполнение требований, предъявляемых Контрактом и настоящим Техническим заданием к Услугам, оказываемым Подрядчиком Все поступающие обращения должны быть исполнены Подрядчиком - Для обеспечения взаимодействия с Заказчиком Подрядчик со своей стороны определяет ответственных лиц, уполномоченных в структуре Подрядчика за своевременное и качественное оказание Услуг в рамках настоящего ТЗ, а также контактную информацию ответственных лиц (телефон, электронную почту). Подрядчик должен предоставить Заказчику единый адрес электронной почты для приема обращений (заявок) в течение 3 (трех) рабочих дней после заключения Контракта. Указанный в настоящем пункте адрес электронной почты (способ направления обращений (заявок) применяется в случае сбоя в работе СРО Заказчика. Со своей стороны, Заказчик предоставляет Подрядчику перечень и контактную информацию (телефон, электронную почту) уполномоченных лиц для осуществления взаимодействия с указанием зон ответственности. О любых изменениях в контактной информации ответственных лиц Стороны должны уведомить друг друга в течение 1 (одного) рабочего дня с момента возникновения таких изменений посредством уведомления на электронную почту ответственных лиц и/или в письменной форме. В результате оказания услуг по настоящему ТЗ не должны быть изменены исходные коды, дистрибутивы и иные компоненты Модуля СЦ вне согласованных с Заказчиком изменений. Любые изменения исходных кодов, дистрибутивов и иных компонентов Модуля СЦ должны производиться только после согласования с Заказчиком уполномоченными лицами по электронной почте или иным заранее согласованным способом. Не должна быть ухудшена надежность и производительность Модуля СЦ. Оказание услуг по Контракту не должно нарушать требования к информационной безопасности, описанной в документации на Модуль СЦ - 4.3.6.2. Требования к услугам информационно-консультационной поддержки работников Заказчика и пользователей Модуля СЦ Услуги информационно-консультационной поддержки сотрудников Заказчика включают: – обработку обращений и заявок, поступивших от сотрудников Заказчика; – консультирование сотрудников Заказчика и пользователей Модуля СЦ; – актуализацию документации, и других материалов по работе с Модулем СЦ при необходимости. – консультирование и разработку рекомендаций по настройке Модуля СЦ (без изменения программного кода), включая изменение настроек функционирования; – консультации по вопросам использования, настройки и возможностям Модуля СЦ; – консультации по проведению превентивных мер для недопущения аварийных ситуаций в Модуле СЦ; – консультации по предварительной диагностике и локализации возникшей неисправности Модуля СЦ; – консультации по вопросам обеспечения информационной безопасности Модуля СЦ и настройки функций, обеспечивающих корректную работу программного обеспечения для совершения юридически значимых действий в Модуле СЦ; – другие вопросы, связанные с работой Модуля СЦ. 4.3.6.2.1. Требования к порядку оказания услуг информационно-консультационной поддержки работников Заказчика и пользователей Модуля СЦ Подрядчик выполняет консультирование сотрудников Заказчика и пользователей Модуля СЦ. Консультация может быть предоставлена по согласованным с представителем Заказчика каналам коммуникации с регистрацией результата консультации в СРО Подрядчиком. Детальный порядок оказания консультационных услуг определен в Регламенте оказания Услуг - 4.3.6.3. Требования к услугам по решению инцидентов, связанных с работой ППО Подрядчик устраняет неисправности Модуля СЦ, связанные с работой ППО, выявленные в рамках оказания услуг согласно настоящему Техническому заданию, при этом в зону ответственности Подрядчика не входит устранение неисправностей, выявленных на стороне Заказчика и на стороне третьих лиц (провайдера связи, поставщика электропитания и т.д.). Первичная диагностика выявленной неисправности проводится на 1 и 2 уровнях технической поддержки и не входит в зону ответственности Подрядчика. Если при проведении первичной диагностики и попытке устранить неисправности на 1 и 2 уровнях технической поддержки, данную неисправность устранить не удалось и в процессе диагностики было выявлено, что проблема связана с работоспособностью ППО, обращение (заявка) назначается сотруднику Подрядчика, ответственному за оказание услуг технической поддержки 3 уровня. Инцидентами вне зоны ответственности Подрядчика являются: – работоспособность функциональности, выходящая за рамки текущей реализации функций в Модуле СЦ и/или являющаяся расширением требований Заказчика к функциям Модуля СЦ; – проведение профилактических и плановых работ, согласованных с Заказчиком; – нарушение работоспособности функций Модуля СЦ, вызванное проведением работ на стороне Заказчика - 4.3.6.4.2. Требования к изменению настроек функционирования Изменение настроек функционирования может проводиться в рамках допустимых пределов изменения функционирования, заложенных в архитектуру Модуля СЦ. Изменение настроек функционирования включает в себя изменение данных и справочников, изменение форм документов, формируемых Модулем СЦ, изменение и настройку форматов и версий передачи данных в смежные системы. Доработка программного кода Модуля СЦ может допускаться (в случае необходимости) при выполнении работ по адаптации функций Модуля СЦ в части изменения формата передачи данных в смежные информационные системы при условии соблюдения требований пункта 29.3 приказа ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации» - 4.3.6.5. Требования к услугам по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности По запросу Заказчика Подрядчик должен провести работу по приведению ППО в соответствие с требованиями по обеспечению информационной безопасности. Критичность уязвимости оценивается в соответствии в соответствии с Методическим документом ФСТЭК России «Методика оценки уровня критичности уязвимостей программных, программно-аппаратных средств» (утвержден ФСТЭК России 30.06.2025), а также с учетом ГОСТ 56545-2015 и международными стандартами (CVSS 3.0 и выше), и задает необходимый срок устранения. В процессе проведения Заказчиком обследования Модуля СЦ и выявления уязвимостей в ППО, связанных с исходным кодом Модуля СЦ и/или используемыми компонентами (библиотеками), Заказчик направляет Подрядчику обращение (заявку) на устранение, с указанием критичности и срочности принятия мер по устранению в СРО. - Подрядчик при оказании услуг по обновлению или устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности должен: – провести анализ уязвимостей и связанных с ними исходным кодом и/или используемыми компонентами (библиотеками); – выработать варианты устранения указанных уязвимостей и согласовать с Заказчиком их реализацию; – своевременно внести изменения в исходный код Модуля СЦ и/или используемые компоненты (библиотеки) и подготовить соответствующее обновление; – провести обновление Модуля СЦ в тестовом контуре Заказчика и проинформировать Заказчика о готовности проведения тестирования; – протестировать успешность обновления или устранения уязвимостей в ППО и корректность функционирования Модуля СЦ на тестовом контуре, совместно с Заказчиком; – при невозможности незамедлительного устранения уязвимости приоритетов «Критический» и «Высокий» Подрядчик обязан предоставить исчерпывающий список причин и согласовать план достаточных компенсирующих мер с ответственными сотрудниками Заказчика. Результат внесения изменений отображается в соответствующей записи в СРО и в составе Отчета об оказанных услугах - 4.3.6.5.1. Требования к порядку оказания услуг по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности Подрядчик в соответствии с приоритетами обращений и контрольными сроками исполнения (см. Приложение Б к ТЗ) оценивает техническую возможность и сроки устранения уязвимостей, и реализацию обновления Модуля СЦ. По итогу проведения оценки Подрядчик направляет в заявке СРО Заказчику заключение о возможности устранения уязвимостей и/или обновления в ППО и согласует с Заказчиком проведение данных работ - Технические меры по обеспечению надежности должны предусматривать: – резервирование критически важных компонентов и данных Системы и отсутствие единой точки отказа; – использование программного резервирования (программной избыточности); – изменение конфигурации используемых средств и применение специализированного ПО, обеспечивающего высокую надёжность. Организационные меры по обеспечению надежности должны быть направлены на минимизацию ошибок пользователей (а также обслуживающего персонала при эксплуатации и проведении работ по обслуживанию), минимизацию времени ремонта или замены вышедших из строя компонентов за счёт: – обеспечения для обслуживающего персонала требуемого уровня квалификации; – регламентации и нормативного обеспечения выполнения работ обслуживающим персоналом; – своевременной диагностики неисправностей. Расчетное значение коэффициента доступности Модуля СЦ должно составлять не менее 0,95. - 4.5.3. Требования по диагностированию Модуля СЦ Диагностирование Модуля СЦ должно осуществляться путем анализа записей в системных журналах СУБД, операционных систем серверов, а также с помощью встроенных средств диагностирования общего программного обеспечения Модуля СЦ. Диагностированию подлежат: – сбои и нарушения функционирования технического обеспечения (серверов) Модуля СЦ; – сбои и нарушения функционирования системного программного обеспечения серверов, используемых для работы Модуля СЦ; – сбои и нарушения функционирования прикладного программного обеспечения серверов, используемых для работы Модуля СЦ; – случаи недоступности (отсутствия ответа) или некорректные ответы внешних систем; – сбои и нарушения функционирования СУБД; – сбои при выполнении регламентных операций резервного копирования. При возникновении аварийных ситуаций либо ошибок в программном обеспечении диагностические инструменты должны позволять сохранять набор информации, необходимой для идентификации и устранения проблемы. Модуль СЦ и ее компоненты должны обеспечивать возможность диагностики своей работоспособности с возможностью интеграции с модулем мониторинга АСУ ТК. Набор передаваемых журналов и метрик должен быть определен на этапе технического проектирования - 4.5.4. Требования к надежности Должно быть предусмотрено сохранение работоспособности Модуля СЦ при некорректных действиях пользователя и сохранение целостности данных при нештатном завершении работы Модуля СЦ (отказ рабочей станции, потеря сетевого доступа и т.п.). Модуль СЦ должен предоставлять механизмы обеспечения сохранности данных через применение процедур резервного копирования и восстановления, описанных в документации на Систему. Ключевые показатели надежности информационной системы — допустимое время на восстановление работоспособности Модуля СЦ (RTO - recovery time objective) и/или допустимый интервал времени потери изменений в данных при сбоях/отказах (RPO – recovery point objective) должны быть определены Подрядчиком и согласованы с Заказчиком на этапе технического проектирования - Оказание услуг в рамках данного технического задания осуществляется Подрядчиком по обращению (заявке) Заказчика, направляемой посредством СРО Заказчика. Регистрация обращений, поступивших непосредственно в Модуль СЦ регистрации обращений Заказчика, производится сотрудниками Заказчика, которые обеспечивают первый уровень технической поддержки Модуля СЦ. В случае назначения приоритета «Критический» или «Высокий», информация о назначении также дублируется оповещением ответственных представителей Подрядчика посредством звонка на предоставленные номера телефонов. Обращение (заявка) должна содержать следующую информацию: – контакты пользователя/организации; – приоритет обращения, соответствующий Приложению 2 к Регламенту; – время обнаружения; – наименование компонента АСУ ТК - Модуль СЦ; Информация может быть расширена по согласованию с Заказчиком. Обращения (заявки) сотрудников Заказчика должны приниматься Подрядчиком через веб-интерфейс СРО. В процессе обработки обращений (заявок) Подрядчик должен обеспечить выполнение следующих процедур: – прием обращений(заявок) от сотрудников Заказчика; – оказание информационно-консультационной поддержки в соответствии с требованиями настоящего Технического задания; – информирование сотрудников Заказчика о статусе обработки и результатах обработки обращений(заявок). Подрядчик осуществляет обязательную регистрацию и учет всех обращений и заявок, поступивших к Подрядчику от представителей Заказчика в рамках оказания настоящих услуг - Примечание: в случае приостановки работы по обращению или заявке (обращение или заявка находится в статусе «Приостановлено»), указываются причины, по которым работы по обращению или заявке приостановлены с указанием перечня действий/информации, запрошенных у инициатора обращения, а также даты, формы и адресата такого запроса. В случае отклонения обращения или заявки (заполняется в случае, если обращению или заявке присваивается статус «Отклонено»), указываются подробно причины такого отклонения, а также фиксируется дата и время перехода в статус «Отклонено». В случае, если обращение или заявка отклонены (отменены) самим Инициатором, то указывается дата и способ, которым от инициатора получено соответствующее уведомление. В случае невыполнения Подрядчиком регламентного времени реагирования или решения обращения (заявки) Заказчик вправе отозвать обращение и направить его Подрядчику повторно. При этом каждое отозванное обращение учитывается в Отчёте об оказанных услугах, как обращение с превышением времени реагирования или решения, но оплате не подлежит. В случае, если обращение (заявка) связано с некачественным выполнением Подрядчиком другой задачи, такое обращение решается в регламентное время, установленное Техническим заданием, при этом оплате такие обращения не подлежат, о чем указывается в Отчете об оказанных услугах в графе «Примечание» - Работы по устранению неисправности приостанавливаются (по согласованию с Заказчиком) в следующих случаях: – если Подрядчиком в результате диагностики выявлено, что неисправность находится в зоне ответственности Заказчика. Подрядчик информирует Заказчика о выявленной неисправности в зоне его ответственности по согласованным каналам связи; – требуется действие со стороны Заказчика – до момента выполнения данного действия Заказчика. Заказчик информируется о необходимых действиях по согласованным каналам связи; – отсутствие возможности связаться со специалистами Заказчика, участие которых необходимо для устранения неисправности; – требуется доставить оборудование на объект – до момента доставки и установки оборудования. В случаях, представленных выше, время приостановки работ не входит в учет продолжительности устранения неисправности. Учет времени устранения неисправности Подрядчиком считается с момента назначения Инцидента специалисту Подрядчика, ответственному за оказание услуг технической поддержки 3 уровня. Подтверждение необходимости приостановления работ находится в зоне ответственности Подрядчика. Приостановление сроков выполнения задач в соответствии с настоящим пунктом подтверждается Заказчиком по мотивированному обращению Подрядчика в СРО, основанному на данных диагностики или на иных фактических обстоятельствах - В случае непринятия Подрядчиком необходимых мер по информированию Заказчика (отсутствие надлежащего обращения от Подрядчика или отсутствие уведомления о необходимости осуществления каких-либо действий Заказчиком) не может являться основанием для приостановления работ по устранению неисправности. В отдельных случаях Подрядчику может потребоваться выполнение технологических работ для устранения причин неисправности или недопущения повторения их в будущем. Для обеспечения устранения неисправности Модуля СЦ Заказчиком проводится классификация в соответствии с приоритетами по степени срочности их устранения. Продолжительность устранения неисправности, а также периодичность информирования Подрядчиком Заказчика о ходе устранения неисправности, определены в Регламенте оказания услуг. При подаче обращения (заявки) наивысшего приоритета через СРО Заказчик должен дополнительно проинформировать службу поддержки Подрядчика о созданном обращении (заявки) по телефону уполномоченного сотрудника Подрядчика. При этом временем подачи обращения (заявки) считается время подачи обращения (заявки) через СРО - При проведении работ по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности необходимо выполнить следующее: – Заказчику сформировать заявку на устранение (обновление) в СРО с полным списком обнаруженных уязвимостей и планируемыми работами; – согласовать в рабочем порядке время начала и завершения работ, перечень работ, выполняемых в рамках обновления или устранения уязвимостей в ППО с Заказчиком; – оповестить Заказчика о начале проведения работ на тестовом контуре; – провести работы по обновлению или устранению уязвимостей в ППО на тестовом контуре Модуля СЦ в установленные сроки; – протестировать выполнение работ в тестовом контуре и проинформировать Заказчика о готовности переноса ППО на продуктивный контур; – силами Заказчика обновить продуктивный контур Модуля СЦ, в соответствии с планом устранения и выполненными работами; – совместно с Заказчиком проверить корректность функционирования Модуля СЦ и устранения уязвимостей в продуктивном контуре Модуля СЦ по результатам обновления; – при необходимости актуализировать документацию (описание архитектуры, анкеты постановки на мониторинг и иные документы). Любые изменения в части обновления или устранения уязвимостей в ППО на промышленном контуре Модуля СЦ должны применяться только в случае успешного проведения аналогичных работ на тестовом контуре. Детальный порядок оказания услуги по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности определен в Регламенте оказания Услуг - 4.4. Требования к видам обеспечения 4.4.1. Требования к лингвистическому обеспечению Документация на Модуль СЦ должна разрабатываться на русском языке. Взаимодействие пользователей с Модулем СЦ посредством графического интерфейса должно происходить на русском языке за исключением сообщений, зависящих от настроек системного программного обеспечения, установленного на рабочих местах пользователей. При разработке программных решений Модуля СЦ должно быть предусмотрено использование языков программирования высокого уровня, приведенных в Таблице 7. Таблица 7. Языки и средства разработки, специального программного обеспечения Модуля СЦ Категория Наименование Назначение Языки программирования Kotlin Разработка серверной логики и сервисов (backend) JavaScript / TypeScript Разработка клиентской части (frontend) Python Разработка скриптов интеграции, обработки данных и автоматизации Фреймворки и библиотеки Vue.JS Разработка пользовательских интерфейсов (веб-интерфейсы компонентов визуализации и отчетности) React Разработка пользовательских интерфейсов (при необходимости создания сложных интерактивных компонентов) Решения по лингвистическому обеспечению, включая перечень используемых языков программирования, должны быть согласованы с Заказчиком на этапе технического проектирования - 4.4.2. Требования к математическому обеспечению Требования к математическому обеспечению не предъявляются. 4.4.3. Требования к метрологическому обеспечению Требования к метрологическому обеспечению не предъявляются. 4.4.4. Требования к организационному обеспечению Требования к организационному обеспечению не предъявляются. 4.4.5. Требования к методическому обеспечению Задачи методического обеспечения Модуля СЦ должны быть обеспечены за счет использования технологических и методических документов касающихся вопросов функционирования транспортного комплекса и разработки и эксплуатации ПО. 4.4.6. Требования к информационному обеспечению Состав, структура и способы организации информационного обеспечения в Модуле СЦ должны быть определены на этапе технического проектирования. Факты информационного обмена с внешними системами должны фиксироваться в соответствующем журнале - 4.5.5. Требования к информационной безопасности Работы по защите информации/информационной безопасности, не включенные в состав настоящего раздела, требуемые в соответствии с требованиями постановления Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации», а также нормативно правовых актов в области защиты персональных данных и обеспечения безопасности объектов критической информационной инфраструктуры, будут проведены в рамках исполнения отдельного контракта, заключенного по результатам отдельной закупочной процедуры (не является частью данного ТЗ), включающего: – определение актуальных угроз безопасности информации и актуализация модели угроз безопасности информации (при необходимости); – выполнение требований о согласовании технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России в установленном порядке; – выполнение требований по устранению Подрядчиком замечаний и недостатков, в случае их выявления при согласовании Заказчиком технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России; – выполнение требований к классу защищенности ГИС, уровню защищенности персональных данных и категории значимости объекта КИИ РФ, установленных для Головного центра обработки данных ФГБУ «СИЦ Минтранса России» (далее – ГЦОД); - – определение перечня объектов защиты информационной системы; – описание (актуализированных) требований к системе защиты информации, а также к мерам защиты информации информационной системы в зависимости от установленных классов защищенности, уровня защищенности персональных данных и категории значимости объектов КИИ РФ (приказы ФСТЭК России № 21, 117, 239); – выполнение требований к мерам по защите ГИС от атак, направленных на отказ в обслуживании, в соответствии с пунктами 30, 34, 59, 63 Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений, утвержденных приказом ФСТЭК России от 11.04.2025 № 117; – описание (актуализированных) требований по защите информации, подлежащих реализации в информационно телекоммуникационной инфраструктуре ГЦОД; – выполнение требований о применении сертифицированных средств защиты информации, включая их классы защиты и уровни доверия; – выполнение требований о запрете использования с 01.01.2025 органами (организациями) средств защиты информации странами происхождения, которых являются иностранные государства в соответствии с пунктом 6 Указа Президента Российской Федерации от 01.05.2022 № 250; – выполнение требований по обеспечению непрерывного взаимодействия с ГосСОПКА в установленном порядке; - 4.5.7. Требования по сохранности информации при авариях В случае возникновения аварии или сбоя в процессе выполнения пользовательских задач должно быть обеспечено восстановление баз данных до состояния на момент последней завершенной Модулем СЦ транзакции, и структуры файлового хранилища. Все аварийные ситуации должны обрабатываться программно с выдачей соответствующих сообщений, с корректной обработкой ситуации (завершение транзакций, закрытие файлов и т.п.), без потери обрабатываемой информации. В Модуле СЦ должны быть предусмотрены меры, обеспечивающие целостность данных в случае отказа программного обеспечения или аппаратных средств, исключая случаи физического уничтожения носителя или нарушения функциональности носителя, операционной системы или СУБД по вине их производителя либо обслуживающего персонала. Используемые аппаратные и системные платформы должны обеспечивать сохранность и целостность информации в Модуле СЦ при полном или частичном отключении электропитания, аварии сетей телекоммуникации, полном или частичном отказе технических средств Модуля СЦ. Технические решения должны обеспечивать сохранность информации в случае возникновения следующих событий (аварий, отказов и т.п.): – отказ аппаратного обеспечения на сервере; – отключение питания на сервере; – отказ аппаратного обеспечения на рабочей станции; – отключение питания на рабочей станции администратора; – отказ линий связи, в том числе при осуществлении обмена данными - 4.5.8. Требования к защите от влияния внешних воздействий Требования к защите от влияния внешних воздействий не предъявляются - 4.5.9. Требования к патентной чистоте и патентоспособности 4.5.9.1. Исключительные права на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, базы данных, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, принадлежат Российской Федерации в лице Заказчика. Право собственности на результаты работ, отчетные документы и материалы, полученные в ходе выполнения работ по Контракту, принадлежат Российской Федерации в лице Заказчика и считаются переданными с момента подписания Сторонами Акта сдачи-приемки выполненных работ. Разработанное программное обеспечение поставляется вместе с исходными кодами. 4.5.9.2. Все проектные и технические решения должны отвечать требованиям четвертой части Гражданского кодекса Российской Федерации. Результаты Работ должны быть свободными от возможности предъявления любых прав и притязаний третьих лиц, основанных на промышленной, интеллектуальной или другой собственности. 4.5.9.3 Результаты выполненных Работ не должны повлечь необходимость осуществления Заказчиком закупок программного обеспечения (как исключительных, так и неисключительных прав) для обеспечения функциональности Системы в соответствии с Техническим заданием. При выполнении работ Подрядчик должен использовать только объекты интеллектуальной собственности, права на которые приобретены (получены) и используются без нарушений прав на интеллектуальную собственность третьих лиц или предоставлены Заказчиком - 4.4.7. Требования к программному обеспечению Общесистемное ПО, используемое в составе Модуля СЦ, должно быть зарегистрировано в Едином реестре российских программ для электронных вычислительных машин и баз данных и соответствовать рекомендованным показателям эффективности и соответствующим им значениям индикаторов эффективности перехода подведомственных организаций на использование российского ПО, заданных Приказом Минцифры России от 18.01.2023 № 21 «Об утверждении методических рекомендаций по переходу на использование российского программного обеспечения, в том числе на значимых объектах критической информационной инфраструктуры Российской Федерации, и о реализации мер, направленных на ускоренный переход органов государственной власти и организаций на использование российского программного обеспечения в Российской Федерации». Применяемое в системе программное обеспечение должно соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации, постановления Правительства Российской Федерации от 23 декабря 2024 г. № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц» - Прикладное программное обеспечение должно отвечать следующим требованиям: – совместимость программных продуктов в части используемых технических средств, системного программного обеспечения и общесистемной инфраструктуры в пределах требований к техническому обеспечению, а также их информационная совместимость в пределах требований к информационному обмену; – обеспечение трехуровневой архитектуры с разделением на уровень хранения данных (сервер БД), уровень бизнес-логики (сервер приложений) и уровень представления ( - 4.4.7.1. Требования к инструментам разработки и процессу контроля версий программного обеспечения 4.4.7.1.1. Система контроля версий Для управления исходным кодом должна использоваться система контроля версий кода, развернутая в инфраструктуре Заказчика. 4.4.7.1.2. Правила именования веток Имя ветки должно соответствовать следующему формату: / / Категории веток: ? feature/ — разработка новой функциональности, а также рефакторинг или удаление существующей; ? fix/ — исправление ошибок; ? hotfix/ — срочные исправления, применяемые в обход стандартного процесса разработки; ? test/ — для проведения экспериментов, не влияющих на основную разработку. Идентификатор задачи: после категории указывается ссылка на задачу (issue) в системе контроля версий кода. Описание: добавляется краткое описание решаемой задачи в формате kebab-case (слова разделяются дефисами, например, add-user-auth). Примеры именования веток: ? feature/#123/add-payment-integration; ? fix/#45/correct-calculation-logic; ? hotfix/#67/urgent-database-connection-patch. 4.4.7.1.3. Правила именования коммитов Сообщение коммита должно соответствовать соглашению Conventional Commits и состоять из категории и описания: : ? fix — исправление ошибки. Примеры сообщений коммитов: ? feat: добавление формы регистрации пользователя; ? fix: исправление ошибки валидации email-адреса; ? refactor: оптимизация алгоритма сортировки данных; ? chore: обновление версий в файле dependencies. 4.4.7.1.4. Модель ветвления В процессе разработки используются следующие основные ветви: ? main / master — стабильная ветка, содержит только код, прошедший полное тестирование и развернутый в продуктивных контурах; ? dev — ветка для интеграции завершенных задач, предназначенная для сборки и тестирования в тестовых средах. Попадание кода в main осуществляется только через Merge Request (MR) из dev - – выполнение требований по обеспечению в автоматизированном режиме с Национальной системой противодействия DDoS-атакам (НСПА) Центра мониторинга и управления сетью связи общего пользования ФГУП «ГРЧЦ» в рамках реализации мер по защите ГИС от атак, направленных на отказ в обслуживании; – детализированные требования к составу и содержанию работ по аттестации, а также к их результатам в соответствии с пунктами 13, 15 и 16 требований приказа ФСТЭК России от 29.04.2021 № 77 «Об утверждении Порядка организации и проведения работ по аттестации объектов информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну» - 4.5.5.1. Требования к безопасности исходного кода Процесс разработки исходного кода должен соответствовать требованиям законодательства, нормативным правовым актам Российской Федерации, приказу ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по безопасности значимых объектов критической информационной инфраструктуры Российской Федерации», а также учитывать отраслевые практики безопасной разработки. Подрядчик должен предоставить Заказчику Руководство по безопасной разработке программного обеспечения (далее – Руководство), применяемое при разработке исходного кода Модуля СЦ. Руководство должно содержать: · описание процесса безопасной разработки и ролевой модели, отражающей зоны ответственности сотрудников Подрядчика; · описание процессов моделирования, оценки и формирования мер предотвращения угроз, применяемых Подрядчиком; · описание методик, применяемых Подрядчиком при разработке исходного кода (правила написания кода); · описание методик, периодичности проведения и инструментария статического, динамического, композитного и фаззинг тестирования исходного кода, включающего критерии отбора релизных версий ПО, применяемые Подрядчиком в процессе разработки; · описание механизмов безопасности в процессе сборки и доставки (безопасность образов, безопасность секретов, безопасность окружения и сборочной среды), применяемые Подрядчиком; · утвержденные шаблоны отчетной документации (в том числе акты), в соответствии с которыми Заказчик принимает результаты проверок (артефакты сборочного процесса), проведенных Подрядчиком; · описание процедур отслеживания и исправления обнаруженных ошибок и уязвимостей программного обеспечения; · описание способов и сроков доведения Подрядчиком до Заказчика информации об уязвимостях программного обеспечения, о компенсирующих мерах по защите информации или ограничениях по применению программного обеспечения, способов получения пользователями программного обеспечения его обновлений, проверки их целостности и подлинности - Подрядчик должен обеспечить реализацию и проведение внутренних проверок мер по разработке безопасного ПО, приведенных в Руководстве. Подрядчик должен провести анализ угроз безопасности информации программного обеспечения в соответствии с ГОСТ 58412-2019 «Защита информации. Разработка безопасного программного обеспечения. Угрозы безопасности информации при разработке программного обеспечения». Подрядчик должен провести испытания по выявлению уязвимостей в программном обеспечении Системы: · проведение статического анализа исходного кода программы; · проведение динамического анализа исходного кода программы; · проведение композитного анализа исходного кода и образов программы; · проведение фаззинг-тестирования программы, направленного на выявление в ней уязвимостей. Испытания по выявлению уязвимостей в программном обеспечении Системы должны быть проведены в рамках: · предварительных испытаний; · опытной эксплуатации; · приемочных испытаний - 4.5.9.4. Подрядчик подтверждает, что обладает всеми правами на передачу Заказчику исключительных прав в соответствии с требованиями настоящего раздела Технического задания. В случае, если к Заказчику по вине Подрядчика будут предъявлены претензии в этой части, иски третьих лиц, связанные с нарушением их прав, Подрядчик принимает на себя такие претензии и иски и возмещает Заказчику все расходы и весь ущерб, понесенный в связи с ними. 4.5.9.5. Подрядчик обязан согласовать с Заказчиком необходимость использования при выполнении работ охраняемых результатов интеллектуальной деятельности, права на которые принадлежат Подрядчику или третьим лицам. 4.5.9.6. В случае, если при выполнении Работ используется готовое программное обеспечение (платформа, подсистема, СУБД и т.д.), которое становится частью (компонентом) Системы, Заказчику передаются полные исключительные права, или неисключительные права (путем заключения лицензионного/сублицензионного договора/соглашения) на такое программное обеспечение со следующими возможностями: – права передаются бессрочно (на весь срок действия исключительных прав); – территория действия Российская Федерация; – должно быть обеспечено право Российской Федерации (в лице Заказчика) передавать, дорабатывать, распространять, развивать результаты работ, созданные в процессе исполнения Контракта, а также перерабатывать такое программное обеспечение. Лицензионное (сублицензионное) соглашение (договор), Акт передачи прав, подписанные Подрядчиком, согласие правообладателя, оформленное в соответствии с положениями Гражданского кодекса Российской Федерации (в случае, если Подрядчик не является правообладателем такого программного обеспечения), инструкция по инсталляции, руководство администратора, руководство пользователя передаются Заказчику в сроки, установленные Техническим заданием для соответствующего функционала Системы - Лицензионное (сублицензионное) соглашение (договор) не может возлагать на Заказчика какие-либо обязанности (в т.ч. в части конфиденциальности, предоставления отчетности), не предусмотренные Контрактом. 4.5.9.7. Передача Заказчику исключительных прав, или простых (неисключительных) прав не может повлечь увеличение стоимости Контракта и/или изменение иных существенных условий Контракта. 4.5.9.8. Функциональность Модуля СЦ передается в объеме и в сроки, установленные Техническим заданием. 4.5.9.9. Нарушение условий настоящего раздела Технического задания, в т.ч. отсутствие соответствующего лицензионного (сублицензионного) соглашения (или договора), либо предоставление лицензионного (сублицензионного) соглашения (или договора), не соответствующего требованиям действующего законодательства Российской Федерации или требованиям Контракта, является нарушением существенных условий Контракта. 4.5.9.10. В случае, если в соответствии с пунктом 4.5.9.6 Заказчику передается исключительное право, такая передача осуществляется в порядке, установленном Гражданским кодексом Российской Федерации. 4.5.9.11. В случае, если при выполнении Работ положения пунктов 4.5.9.5-4.5.9.6 не применялись, Подрядчик в составе отчетной документации предоставляет об этом декларацию в свободной форме. Декларация должна содержать сведения о полном соответствии результата Работ требованиям Контракта, а также о неприменении при выполнении работ готового программного обеспечения (платформ, подсистем, СУБД и т.д.), которое стало частью (компонентом) Системы - 4.5.9.12. Передача Заказчику комплекта документов, материалов и сведений, предусмотренных нормативными правовыми актами Российской Федерации в сфере информационных технологий, защиты информации, правовой защиты интересов государства в области интеллектуальной собственности, включая документы, подтверждающие отказ авторов (разработчиков) от исключительных прав на передаваемые объекты интеллектуальной собственности в пользу Подрядчика, с проектами заявок на государственную регистрацию в установленном порядке прав Заказчика на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, базы данных, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, осуществляется Подрядчиком в составе отчетной документации, предусмотренной условиями Контракта. 4.5.9.13. По результатам выполнения работ по развитию системы должны быть подготовлены материалы для регистрации доработанной версии Системы (объекта учета) в НФАП в соответствии с требованиями постановления Правительства Российской Федерации от 30 января 2013?г. №?62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин» (с изменениями и дополнениями) в части обязательности размещения результатов работ в национальном фонде алгоритмов и программ для электронных вычислительных машин - 4.5.10. Требования по стандартизации и унификации К Модулю СЦ предъявляются следующие требования в части стандартизации и унификации: – работы по развитию Модуля СЦ должны производиться в соответствии с действующими стандартами и нормами Российской Федерации; – при создании и модернизации элементов Модуля СЦ следует руководствоваться действующими в Российской Федерации национальными стандартами и другими нормативно-техническими документами; – используемые оборудование и материалы, подлежащие обязательной сертификации, должны иметь соответствующие сертификаты; – ПО Модуля СЦ должно проектироваться и разрабатываться с учётом обеспечения требований унификации; – применяемые при создании Модуля СЦ технические (форматы данных, протоколы передачи и прочие) и организационные (регламенты, требования, инструкции) решения должны быть доступны и документированы в виде, достаточном для независимой (без обращения к Подрядчику) реализации третьими сторонами; – термины, обозначения и наименования, используемые в ПО, должны быть стандартизованы и унифицированы, выполнены на русском языке; – взаимодействие элементов и их внешнее поведение должно быть реализовано одинаково и производиться по единым правилам - 4.2.2. Развитие компонента отчетности (3 очередь) Должна быть обеспечена автоматизация процессов формирования отчетов о ЧС и нештатных ситуациях на транспорте, в т.ч. на основе данных из внешних систем. Включает следующие доработки: – разработка шаблонов отчетов в различных форматах (табличный, текстовый); – реализация выбора фотоматериалов для включения в справку; – форматирование содержимого справок с учетом правил русского языка в отношении окончаний слов (в зависимости от падежа, склонения, числа и рода); – автоматизированное формирование выводов к содержимому справки на основе настраиваемых критериев; – создание интерфейса выбора параметров (фильтрации) для формирования отчетов: o состав полей для включения в отчёт; o настройка диапазонов значений характеристик и дат; o порядок отображения полей; o настройка заголовка. – реализация способа подготовки отчётов в асинхронном режиме (очереди); – реализация интерфейса компонента формирования отчетности для отображения очереди формирования отчетов и статусов их подготовки; – экспорт отчётов в форматы xlsx, csv и справок в форматы pdf, docx. Необходимо разработать не менее 10 шаблонов отчетов и/или справок. Перечень, структура и содержание шаблонов должны быть согласованы с Заказчиком на этапе технического проектирования. - 4.2.3. Развитие компонента визуализации (2 очередь) В рамках развития компонента визуализации должны быть выполнены следующие доработки, обеспечивающие: – вывод перечней (списков) сил и средств предупреждения и ликвидации ЧС и нештатных ситуаций на транспорте с отображением мест их постоянного размещения (дислокации) на карте, включая: o отображение зон ответственности на карте; o возможность их фильтрации (по видам транспорта, регионам и пр.); o реализацию инструмента расчета расстояния (с использованием сети автомобильных и железных дорог) между местом события и местами дислокации сил и средств, а также вывода маршрутов на карте; – отображение зон (полигонов) с установленными ограничениями движения в воздушном пространстве на карте; – отображение термических точек; – реализация возможности отображения данных из паспорта региона, отображаемого в модуле iМинтранс (модуль АСУ ТК); – отображение краткой карточки сущностей и ОТИ (краткой информации и/или динамических характеристик объекта) при выборе объекта на карте с возможностью перехода в полную карточку сущности и ОТИ; – отображение данных от Росгидромета, предусматривающих: o отображение неблагоприятных и опасных природных явлений на карте (с заданным периодом обновления данных); o управление отображением явлений на карте, включая настройку состава отображаемых объектов, поиск, фильтрацию, с использованием соответствующей панели управления; o выведение краткой карточки явления при выборе объекта, с возможностью перехода в полную карточку объекта - – отображение на карте связанных сущностей и ОТИ; – реализация функции выбора темного и светлого стилей отображения элементов интерфейса, карточек сущностей, картографической основы и объектов, отображаемых на карте; – реализация механизма для выбора картографической основы в одном из распространенных форматов WMTS, TMS, MVT и др. Должна быть предусмотрена возможность настройки перечня картографических основ и параметров доступа к ним; – настройка базового набора дашбордов, содержащих преднастроенные виджеты о количестве событий в разрезе видов транспорта с возможностью перехода к исходным данным (карточкам событий, ОТИ и т.д.), с фильтрацией по параметрам. Параметры фильтрации должны быть определены на этапе технического проектирования. Должно быть обеспечено автоматическое и принудительное обновление данных, отображаемых на дашбордах - 4.2.4. Создание компонента «Интерактивная карта» (2 очередь) В составе создаваемого компонента должны отображаться данные, доступные в компоненте визуализации. Требования к интерфейсу интерактивной карты: – интерактивная карта должна быть представлена в виде объемной карты с учетом макетов, представленных в Приложении А к ТЗ; – интерфейс должен корректно отображаться на экранах мониторов (разрешение Full HD 1920?1080), телевизоров (разрешение 4К 3840?2160), жидкокристаллических панелей для видеостены, используемой Заказчиком, с параметрами каждой панели: диагональ 55 дюймов, разрешение 1920x1080; – интерфейс должен корректно отображаться на планшетных устройствах с диагональю экрана 10-12 дюймов, конкретные требования должны быть уточнены на этапе технического проектирования; – должна быть обеспечена кластеризация и генерализация отображения объектов на карте при изменении масштаба; – должно быть обеспечено отображение основных характеристик объектов при выборе их на карте; – должно быть обеспечено управление отображением слоев на карте; – должна быть обеспечена настройка цветовой индикации отображаемых объектов транспортной инфраструктуры; – должно быть обеспечено отображение легенды карты, содержащей отображаемые объекты на карте; – должна быть обеспечена возможность одновременного отображения не менее 5 000 ОТИ и ТС на карте. - На интерактивной карте должны быть отображены подвижные объекты совместно с объектами транспортной инфраструктуры (ОТИ), включая следующие возможности: § отображение местоположения транспортных средств (воздушный, водный и автомобильный транспорт) на карте в режиме реального времени (с заданным периодом обновления данных); § отображение маршрутов движения всех ТС за выбранный период времени, в том числе с использованием эффектов анимации; § отображение маршрутов движения ТС, связанных с карточкой события: ТС, являющихся участниками события, и ТС, находящиеся в заданном радиусе от события; § управление отображением сущностей и ОТИ на карте, включая настройку состава отображаемых объектов, поиск, фильтрацию, с использованием соответствующей панели управления и наглядным представлением результатов; § автоматическое изменение вида отображения объектов (цветовая индикация) по заданным условиям (например, при достижении критических значений параметров, характеризующих функционирование объекта); Должна обеспечиваться производительность обновления изображения на экране в 30 кадров в секунду на тестовой конфигурации пользовательского устройства (модель Бештау AIO2402/B560, входящая в Реестр российской промышленной продукции под номером 10394100 или аналог) при одновременном отображении не менее 5 000 объектов и 200 уникальных моделей объектов. Макеты интерфейсов Модуля СЦ должны быть предварительно согласованы с Заказчиком и разработаны с учетом требований ГОСТ Р ИСО 9241-161-2016 «Элементы графического пользовательского интерфейса» - 4.3.1.3. Требования к регламенту оказания услуг Подрядчик должен руководствоваться Регламентом оказания услуг по технической поддержке Модуля СЦ. Регламент оказания услуг содержит следующую информацию: – порядок оказания услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Модуля СЦ; – порядок оказания услуги по решению инцидентов, связанных с работой ППО; – порядок оказания услуги адаптационного, конфигурационного и коррекционного сопровождения Модуля СЦ (в рамках действующих программных модулей и функциональностей); – порядок оказания услуги по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности. – Регламент содержит следующие формы заявок на оказание услуг: – форма заявки на оказание услуги по информационно-консультационной поддержке сотрудников Заказчика; – форма заявки на оказание услуги по решению инцидентов, связанных с работой ППО; – форма заявки на оказание услуг адаптационного, конфигурационного и коррекционного сопровождения Модуля СЦ (в рамках действующих программных модулей и функциональностей) (приоритет заявки определяется Заказчиком); – форма заявки на оказание услуги по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности - 4.3.2. Требования к режиму обеспечения функционирования Модуля СЦ Режим оказания услуг определен в Приложении Б к настоящему ТЗ. По согласованию с Заказчиком, в целях недопущения остановки функционирования Модуля СЦ в период интенсивной работы пользователей в Модуле СЦ, отдельные услуги могут оказываться по специальному графику (в нерабочее время Подрядчика) в соответствии с заявками Заказчика - 4.3.3. Требования к качеству оказываемых услуг Качество оказываемых услуг поддерживается Подрядчиком в соответствии с определяемыми данным ТЗ условиями и правилами и контролируется Заказчиком на постоянной основе, в том числе по соблюдению сроков исполнения и подтверждениям исполнения от инициаторов обращений и другим параметрам. По результатам выполнения работ по устранению инцидента должна быть устранена корневая причина инцидента с окончательным решением, устраняющим причину возникновения проблемы и исключающим вероятность повторного возникновения проблемы (инцидента). Время устранения корневых причин проблемы (инцидента) не должно составлять более 40 рабочих часов - 4.3.6.3.1. Требования к порядку оказания услуги по решению инцидентов, связанных с работой ППО При поступлении от Заказчика обращения (заявки), являющегося неисправностью в работе Модуля СЦ (инцидентом), Исполнитель реагирует на инцидент в СРО в срок не более 30 минут с момента поступления. В случае необходимости, для решения инцидента ответственный специалист должен связаться с инициатором обращения (заявки) для уточнения условий воспроизведения проблемы или для получения дополнительных сведений. После получения необходимых сведений от инициатора обращения (заявки) ответственный специалист производит диагностику с целью выявления причины инцидента и возможных путей устранения. В случае, если инцидент невозможно решить без получения дополнительных сведений от инициатора, и не удается связаться с инициатором в течение пяти рабочих дней, обращение (заявка) отклоняется в связи с недостатком данных для его решения, Заказчику направляется уведомление об отклонении обращения (заявки). Время, в течение которого невозможно связаться с инициатором, вычитается из общего времени обработки обращения (заявки). Все попытки связаться с инициатором должны фиксироваться с указанием даты и времени попытки, используемого способа связи (номер телефона, адрес электронной почты) и результата попытки (не удалось дозвониться, абонент недоступен, и т.д.) - Факт и время решения инцидента должны быть зафиксированы и отражены в СРО. В случае, если причиной сбоя в работе Модуля СЦ является выход из строя аппаратного обеспечения или неработоспособность смежной информационной системы, время работы над инцидентом приостанавливается до момента устранения неисправности. В ходе решения инцидентов могут быть выявлены дефекты ППО Модуля СЦ. В случае обнаружения дефектов ППО, Подрядчик информирует об этом Заказчика. Исполнитель может быть привлечен к проверке результата устранения дефекта по инициативе Заказчика. Приоритеты инцидентов приведены в Приложении Б к ТЗ. Детальный порядок оказания услуги по решению инцидентов, связанных с работой ППО Модуля СЦ определен в Регламенте оказания Услуг - 4.3.6.4. Требования к услугам адаптационного, конфигурационного и коррекционного сопровождения и доработки Модуля СЦ (в рамках действующих программных модулей и функциональностей) Услуги адаптационного, конфигурационного и коррекционного сопровождения и доработки Модуля СЦ включают: – управление изменениями и адаптация функций Модуля СЦ; – изменение настроек функционирования Модуля СЦ; – внесение изменений и/или модификаций Модуля СЦ (в рамках действующих программных модулей и функциональностей), направленных на улучшение их работоспособности и функциональных возможностей; – подготовка и передача Заказчику SQL запросов в СУБД для получения агрегированной информации из Модуля СЦ, которую невозможно получить с использованием графического пользовательского интерфейса; – адаптация модулей интеграций со смежными информационными системами - 4.4.7.1.5. Требования к используемым зависимостям (библиотекам) Все внешние зависимости проекта должны быть зафиксированы с указанием точных версий. Для контроля версий зависимостей в репозиторий обязательно должны быть включены следующие файлы: · Для JavaScript: package-lock.json или yarn.lock; · Для Python: requirements.txt (с зафиксированными версиями) или Pipfile.lock; · Для Go: go.mod и go.sum; Загрузка всех зависимостей должна производиться исключительно через внутренний прокси-репозиторий Заказчика, настроенный в соответствующем системе менеджере пакетов. Запрещается: · Использование плавающих версий (например, ^1.2.3, ~4.5.0, latest); · Использование библиотек, содержащих критические уязвимости, в том числе зарегистрированные в реестре CVE (Common Vulnerabilities and Exposures). 4.4.7.1.6. Требования к процессу непрерывной интеграции (CI) Сборка программного обеспечения, включая этапы компиляции, тестирования и анализа кода, должна выполняться исключительно в инфраструктуре непрерывной интеграции Заказчика. 4.4.7.1.7. Требования к хранению артефактов сборки Все артефакты сборки (результирующие пакеты, Docker-образы и т.д.) подлежат обязательному хранению в предназначенной для этого инфраструктуре Заказчика (артефакторий). Запрещается размещение финальных артефактов сборки на сторонних ресурсах - 4.4.8. Требования к техническому обеспечению Количество серверов, подключаемых и настраиваемых сервисов, их параметров, схемы соединений и настройки межсетевого взаимодействия должны быть согласованы с Заказчиком на этапе № 1 Техническое проектирование. Доступ к комплексу технических средств предоставляется Заказчиком по письменному запросу Подрядчика. Применяемые в Системе программно-аппаратные и аппаратные комплексы должны соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации», требованиям Постановления Правительства Российской Федерации от 23 декабря 2024 г. № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц». Модуль СЦ, работающий в составе АСУ ТК, развернут на вычислительных мощностях ГЦОД СИЦ Минтранса России - 4.5. Общие технические требования 4.5.1. Требования к численности и квалификации персонала и пользователей Модуля СЦ Программное обеспечение Модуля СЦ не должно требовать изменения штатной численности персонала Заказчика. Программное обеспечение Модуля СЦ не должно требовать наличия у пользователей дополнительной квалификации в сфере информационных технологий, кроме базовых знаний в обращении с персональным компьютером, базовых навыков работы в интернет-обозревателях и знаний о Модуле СЦ в объеме документов Руководство пользователя, Руководство администратора - 4.2.4.1. Требования к технической реализации компонента «Интерактивная карта» При реализации компонента «Интерактивная карта» должны учитываться требования, указанные ниже. 4.2.4.1.1. Требования к отображению элементов Повторяющихся элементы карты (ТС, ОТИ, события и пр.) должны отрисовываться с использованием аппаратного создания экземпляров объектов на пользовательском устройстве (WebGL/WebGPU)). Отрисовка каждого объекта отдельным запросом не допускается, должна обеспечиваться возможность одновременного отображения не менее 5 000 объектов без снижения производительности (30 кадров в секунду на тестовой конфигурации). 4.2.4.1.2. Уровни детализации объектов Для управления отображением сложных объектов должно быть создано не менее 3-х уровней детализации, отображаемых при изменении масштаба с возможностью автоматического переключения между уровнями. Все отображаемые объекты должны масштабироваться с учетом разрешения экрана пользователя с сохранением качества детализации. 4.2.4.1.3. Полигональная оптимизация и текстурирование При реализации компонента «Интерактивная карта» должна обеспечиваться технология рельефного тестурирования объектов. Не должны использоваться высокополигональные трехмерные модели. Все повторяющиеся элементы должны генерироваться единоразово и повторно использоваться при последующих отображениях. 4.2.4.1.4. Управление памятью Требуется реализовать потоковую загрузку на устройство пользователя элементов карты и текстур. Загрузка данных целиком при старте приложения не допускается. Необходимо реализовать механизм очистки памяти от элементов, которые находятся вне области видимости камеры в течение заданного времени. 4.2.4.1.5. Требования к взаимодействию пользователя с интерфейсом компонента «Интерактивная карта» Программная реализация механизмов управление камерой (масштабирование и навигация) должна быть выполнена с поддержкой технологии WebAssembly (WASM). Элементы управления должны являться неотъемлемой частью интерактивной карты. - 4.2.5. Развитие компонента администрирования (3 очередь) Должна быть выполнена доработка ролевой модели. Ролевая модель должна обеспечивать управление доступом к отдельным объектам Модуля СЦ и их элементам (атрибутам) с разграничением по видам транспорта, регионам и пр., в частности: – определение набора конкретных действий, доступных пользователям (выполняемых над объектом доступа, например, удаление записи, редактирование записи, формирование отчета и др.); – реализация возможности объединения пользователей в группы; – определение прав доступа для групп пользователей; – реализация интерфейса визуальной настройки прав доступа пользователей к объектам Модуля СЦ - 4.3.4. Требования к документированию результатов оказываемых услуг Для обеспечения контроля оказываемых услуг по поддержке Модуля СЦ со стороны Заказчика, по окончании каждого отчетного периода по контракту в соответствии с календарным планом, Подрядчик обязан предоставить Заказчику Отчет об оказанных услугах. Отчет должен содержать детальную информацию об оказанных услугах с указанием даты выполненных мероприятий и приложением обосновывающих документов (заявок, запросов, требований) или ссылкой на такие документы, если они содержатся в Модуле СЦ. Информация о выполненных мероприятиях по заявкам должна быть сформирована на основании соответствующих записей СРО по каждому этапу исполнения Контракта. В случае оказания услуги адаптационного, конфигурационного и коррекционного сопровождения Модуля СЦ, должны быть предоставлены документы, подтверждающие выполнение требований п. 29.3 приказа ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации». Фактическое время реагирования и время решения по всем обращениям, поступившим в СРО, формируется в СРО по итогам отчетного периода в разделе «Отчеты». Фактическое время реагирования и время решения по обращениям учитывает суммарное время, затраченное на реагирование и, соответственно, на работу по обращению с момента назначения обращения специалисту Подрядчика или группе исполнителей, ответственным за оказание услуг технической поддержки 3 уровня от начала до завершения работ Подрядчиком. При этом принимается суммарное время нахождения заявки в соответствующих статусах заявки СРО на стороне Подрядчика - 4.3.5. Требования к классификации обращений и заявок Обращения и заявки Заказчика классифицируются в соответствии с приоритетами и регламентными сроками, указанными в Приложении 2 к Регламенту. Регистрация обращений и заявок предусматривает создание новой записи в СРО с присвоением поступившему обращению или заявке (новой записи) уникального идентификатора. Запись в СРО должна содержать вопрос или проблему, которую требуется решить или оказать консультацию. Состав обязательной информации, которую должно содержать обращение или заявка, зафиксирован в Регламенте оказания Услуг. Если обращение или заявка автоматически зарегистрированы в СРО при отправке представителем Заказчика, Подрядчик проверяет корректность классификации обращения или заявки и может обратиться к Заказчику с просьбой корректировки, предоставив обоснования в соответствии с настоящей классификацией (Таблица 6) - 4.3.6.4.1. Требования к проведению изменений Основанием для внесения изменений является запрос от Заказчика. Все активности по внесению изменений должны быть согласованы с Заказчиком, а действия Подрядчика при оказании данной услуги должны быть зафиксированы. В рамках данного Технического задания изменениями считаются локальные доработки функционала Модуля СЦ, которые не должны приводить к необходимости выполнения дополнительных аттестационных испытаний или переаттестации АСУ ТК в соответствии с п. 33 приказа от 29.04.2021 № 77 «Об утверждении Порядка организации и проведения работ по аттестации объектов информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну». При необходимости внесения изменений в Модуль СЦ, не связанных с критичным инцидентом, существенно нарушающим работоспособность Модуля СЦ, Заказчик направляет Подрядчику обращение (заявку), в котором излагает суть изменения, которое требуется внести в Модуль СЦ. Исполнитель, в течение 3 (трех) рабочих дней с момента поступления соответствующего обращения (заявки), оценивает техническую возможность реализации запрашиваемого изменения и варианты реализации. По итогу проведения оценки Подрядчик направляет Заказчику заключение о возможности реализации данного изменения с описанием возможных вариантов реализации и согласует с Заказчиком проведение данного изменения - При проведении работ по изменению и адаптации Подрядчик должен: – обеспечить выполнение требований безопасной разработки программного обеспечения; – обеспечить предварительное проектирование технических решений и согласование с Заказчиком проекта реализации изменения; – использовать семантическое версионирование (SemVer) в работе, передать Заказчику все артефакты разработки (исходный код и сторонние библиотеки, конфигурации, сборочные и собранные образы и др.); – подготовить полноценное описание функционала, включенного в релиз, с необходимыми схемами и пояснениями к обновлению на стендах Заказчика; – обеспечить тестирование разработанного функционала на стендах Заказчика силами Подрядчика; – решение о переносе измененного ППО на продуктивный стенд принимается Заказчиком по итогу результатов проведенного тестирования; – обеспечить техническое сопровождение процедуры тестирования ППО и переноса измененного ППО на продуктивный стенд Заказчика; – обеспечить экстренное внесение соответствующих изменений в случае выявления некорректной работы продуктивного стенда Заказчика после проведения обновления по итогам разработанного изменения в кратчайшие сроки; – актуализировать при необходимости комплект эксплуатационной документации: o руководство пользователя; o руководство администратора; o иные документы (при необходимости). Результат выполнения изменений должен быть отражен в Отчете по оказанию услуг. Типы и приоритеты изменений могут быть скорректированы в процессе оказания услуг исключительно по согласованию с Заказчиком - 4.5.2. Требования к режимам функционирования Модуля СЦ Модуль СЦ должен предусматривать наличие следующих режимов работы: – штатный; – регламентный (профилактический); – аварийный. Основным режимом функционирования является штатный. В штатном режиме все компоненты корректно и полностью выполняют свои функции. Перерывов в работе как Модуля СЦ в целом, так и одного, либо нескольких компонентов не предусмотрено. Режим регламентного (профилактического) обслуживания предназначен для проведения работ по обновлению и техническому обслуживанию компонентов Модуля СЦ, а также резервному копированию данных. При работе в данном режиме допускаются перерывы в работе Модуля СЦ с предварительным информированием пользователей. Состав процедур по регламентному обслуживанию Модуля СЦ и их периодичность определяются Подрядчиком в процессе выполнения работ по созданию Модуля СЦ. В режиме регламентного (профилактического) обслуживания Модуль СЦ может функционировать с частичным ограничением своих функциональных возможностей, либо без ограничения, но со снижением показателей надежности и производительности. Перевод в данный режим работы должен осуществляться сразу после начала выполнения любой операции, отнесенной к этому режиму, с последующим возвратом в штатный режим функционирования сразу после ее завершения. Перевод в указанный режим должен осуществляться при возникновении необходимости проведения работ по обновлению и техническому обслуживанию компонентов Модуля СЦ, а также резервному копированию данных с условием предварительного оповещения пользователей. Аварийный режим функционирования характеризуется отказом одной или нескольких подсистем, вызванных выходом из строя аппаратного и/или программного обеспечения, а также в случае временной неработоспособности каналов связи между серверами. - В аварийном режиме осуществляется поиск неисправностей и проведение работ по их устранению. Перевод в аварийный режим должен осуществляться при возникновении сбоев, аварий и прочих незапланированных воздействий, сразу после наступления одной или нескольких аварийных ситуаций, с последующим возвратом в штатный режим функционирования сразу после окончания восстановительных работ. ПО Модуля СЦ должно обладать надежностью, обеспечивающей работу пользователей в произвольном режиме и оперативное восстановление работоспособности при сбоях. В целях обеспечения надежного функционирования ПО должно предусматривать: – сохранение целостности данных при нештатном завершении работы компонентов Модуля СЦ; – сохранение работоспособности программного обеспечения при некорректных действиях пользователя; – резервное копирование базы данных Модуля СЦ. – время восстановления работоспособности Модуля СЦ после отказа не более 4 часов. – отказоустойчивость на уровне 99% при единовременной количестве не менее 200 пользовательских сессий в Модуле СЦ. Указанные характеристики приведены без учета характеристик надежности инфраструктуры и времени передачи информации по каналам связи. При возникновении сбоев в аппаратном обеспечении, включая аварийное отключение электропитания, Модуль СЦ должен автоматически восстанавливать свою работоспособность (не требовать перенастройки) после устранения сбоев и корректного перезапуска аппаратного обеспечения - По результатам анализа угроз безопасности информации программного обеспечения и испытаний по выявлению уязвимостей в программном обеспечении Системы должна быть предоставлена отчетная документация по формам, утвержденным в Руководстве, и артефакты сборочной среды, подтверждающие проведение испытаний по выявлению уязвимостей в программном обеспечении Систем. Уязвимости подлежат устранению в сроки, обозначенные Заказчиком. В случае обнаружения уязвимого компонента Подрядчик должен заменить/обновить библиотеки. В случае, если уязвимость не подлежит исправлению на программном уровне, Подрядчик должен разработать меры предотвращения угроз безопасности, в том числе правила безопасности для наложенных средств защиты, рекомендации по безопасной настройке конфигурации для устранения потенциальных уязвимостей и снижения рисков информационной безопасности. Уязвимости, найденные ФСБ России, ФСТЭК России, Минцифры России, Роскомнадзором в ходе исполнения Контракта, а также в течение гарантийного периода, должны быть устранены Подрядчиком за свой счет в сроки, согласованные с Заказчиком - 4.5.6. Требования к эргономике и технической эстетике Взаимодействие пользователей с Модулем СЦ должно осуществляться посредством визуального графического интерфейса. Ввод-вывод данных, прием управляющих команд и отображение результатов их исполнения должны выполняться в интерактивном режиме. Интерфейс должен быть рассчитан на преимущественное использование манипулятора типа «мышь», то есть управление Модулем СЦ должно осуществляться с помощью набора экранных меню, кнопок, значков и т. п. элементов. Клавиатурный режим ввода должен использоваться главным образом при заполнении и/или редактировании текстовых и числовых полей экранных форм. Все надписи экранных форм, а также сообщения, выдаваемые пользователю (кроме системных сообщений), должны быть на русском языке. Модуль СЦ должен обеспечивать проверку вводимых пользователем данных и предупреждать о некорректно введённых значениях - Экранные формы должны проектироваться с учетом требований унификации: – все экранные формы пользовательского интерфейса должны быть выполнены в едином графическом дизайне, с одинаковым расположением основных элементов управления и навигации; – для обозначения сходных операций должны использоваться сходные графические элементы, кнопки и другие управляющие (навигационные) элементы. Термины, используемые для обозначения типовых операций, а также последовательности действий пользователя при их выполнении должны быть унифицированы; – внешнее поведение сходных элементов интерфейса (реакция на наведение указателя «мыши», переключение фокуса, нажатие кнопки) должно реализовываться одинаково. Структура размещения информации и представление этой структуры в Модуле СЦ должны соответствовать следующим требованиям: – пункты меню в пользовательском веб-интерфейсе должны быть сгруппированы в соответствии с тематикой информации, функциональными задачами и технологией работы; – каждому пункту меню должна соответствовать только одна выполняемая функция; – при совершении пользователями ошибочных действий должны выдаваться сообщения об ошибках. Эскизы визуального оформления компонента «Интерактивная карта» представлены в Приложении А. - 4.5.11. Требования к показателям назначения 4.5.11.1. Требования к показателям назначения мероприятий по развитию Модуля СЦ В рамках выполнения работ по развитию Модуля СЦ, предусмотренных ТЗ, показатель назначения «Количество пользователей» должен соответствовать значениям, приведенным в данном разделе. Пояснения по показателям, связанным с количеством пользователей, приведены в Таблице 8. Таблица 8. Определения показателей, связанных с количеством пользователей в Модуле СЦ № Показатель Определение Расчетное количество пользователей Количество пользователей, работу которых должен обеспечить Модуль СЦ к моменту сдачи работ по Контракту с учетом достижения всех показателей назначения Расчетное количество одновременно работающих пользователей Количество одновременно работающих пользователей, работу которых должен обеспечивать Модуль СЦ к моменту сдачи работ по Контракту с учетом достижения всех показателей назначения Значения показателей количества пользователей, достижение которых необходимо обеспечить, представлено в Таблице 9 - Таблица 9. Значения показателей количества пользователей № Показатель Значение 1. Расчетное количество пользователей 1 000 2. Расчетное среднее количество одновременно работающих пользователей 200 Развитие Модуля СЦ должно быть направлено на достижение следующего эффекта (показателя), подставленного в мероприятии 103.002 «Информационно-аналитическая система регулирования на транспорте (АСУ ТК)» ВПЦТ Минтранса России: Выполнение работ по развитию Модуля СЦ предусмотрено мероприятием по развитию АСУ ТК, приведенном в ВПЦТ Минтранса России на 2026-2028 гг: № 103.002 «АСУ ТК» в составе ИТ расхода 103.26.000005 «Развитие предусматривает реализацию ОКР и эффектов, приведенных в Таблице 10. Таблица 10. ОКР и эффекты, приведенные в ВПЦТ Минтранса России на 2026 г. № ОКР Дата ОКР Эффекты 1 Обеспечено информационное взаимодействие с Минобороны России о происшествиях на транспортных объектах 25.12.2026 Сокращено время сбора и передачи сведений для Минобороны России о ЧС и НС на транспорте с 120 до 10 минут 2 Обеспечена автоматизация формирования отчетов о нештатных ситуациях на транспорте, в том числе по данным внешних систем 25.12.2026 Сокращено время на подготовку отчетов о нештатных ситуациях на транспорте с 20 до 5 минут Реализация остальных ОКР не является предметом данного ТЗ и проводится в рамках отдельного технического задания. - 4.5.11.2. Требования к показателям назначения мероприятий по эксплуатации Модуля СЦ. Работы по эксплуатации Модуля СЦ не должны обеспечивать режимы функционирования Модуля СЦ, приведенные в разделе 4.5.2 данного ТЗ - 5. СОСТАВ И СОДЕРЖАНИЕ РАБОТ ПО РАЗВИТИЮ И ТЕХНИЧЕСКОЙ ПОДДЕРЖКЕ МОДУЛЯ СЦ (КАЛЕНДАРНЫЙ ПЛАН) - 1 Техническое проектирование Сопроводительным письмом предоставляются Заказчику: · Технический проект, включая следующие документы: – Ведомость технического проекта; – Ведомость машинных носителей информации – Пояснительная записка; – Описание информационного обеспечения системы; – Описание автоматизируемых функций; – Схема функциональной структуры; – Описание организации информационной базы; – Описание программного обеспечения; · Макеты экранных форм компонента «Интерактивная карта»; · Руководство по безопасной разработке программного обеспечения; · Документ о приемке Начало: с даты заключения контракта Окончание: не позднее 31.07.2026 - - Значение характеристики не может изменяться участником закупки - 2 Услуги по технической поддержке Модуля СЦ (с даты заключения контракта по 10.09.2026) По окончании оказания Услуг сопроводительным письмом предоставляются Заказчику: – Отчет об оказанных Услугах по технической поддержке; – Актуальные на дату окончания оказания Услуг по данному этапу исходные коды прикладного ПО на электронном носителе (в случае внесения изменений); – Инструкция по сборке и развертыванию (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство пользователя (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство администратора (в случае внесения изменений); – Документ о приемке Начало: с даты заключения контракта Окончание: не позднее 10.09.2026 - 3 Разработка программного обеспечения (1 очередь, пп. 4.2.1, 4.2.6 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ; – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 1 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 1 очереди; – Руководство по резервному копированию; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 16.09.2026 - 4 Разработка программного обеспечения (2 очередь, пп. 4.2.3, 4.2.4 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ. – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 2 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 2 очереди; – Руководство по резервному копированию; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 25.09.2026 - 5 Разработка программного обеспечения (3 очередь, пп. 4.2.2, 4.2.5 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ; – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 3 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 3 очереди; – Руководство по резервному копированию; – Описание ролевой модели; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 09.10.2026 - 6 Опытная эксплуатация (1 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акт о завершении опытной эксплуатации 1 очереди; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке 17.09.2026 Окончание: не позднее 26.10.2026 - 7 Опытная эксплуатация (2 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акт о завершении опытной эксплуатации 2 очереди; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке 26.09.2026 Окончание: не позднее 26.10.2026 - 8 Опытная эксплуатация (3 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Акт о завершении опытной эксплуатации 3 очереди; – Документ о приемке Начало: с 10.10.2026 Окончание: не позднее 26.10.2026 - 9 Приемочные испытания Сопроводительным письмом предоставляются Заказчику: – Программа и методика приёмочных испытаний; – Протокол приемочных испытаний; – Исходные коды и дистрибутивы на электронном носителе (при условии внесения изменений, с учетом доработок по результатам опытной эксплуатации и проведенных испытаний); – Комплект рабочей документации на Модуль СЦ (при условии внесения изменений, с учетом доработок по результатам опытной эксплуатации и проведенных испытаний); – Акт приемки Системы в эксплуатацию; – Акт приемки-передачи исключительных прав на объект; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке; – Документы в соответствии с разделом 4.5.9 ТЗ; – Обеспечение гарантийных обязательств Начало: с 27.10.2026 Окончание: не позднее 10.11.2026 - 10 Услуги по технической поддержке Модуля СЦ (с 11.09.2026 по 15.12.2026) По окончании оказания Услуг сопроводительным письмом предоставляются Заказчику: – Отчет об оказанных Услугах по технической поддержке; – Актуальные на дату окончания оказания Услуг по данному этапу исходные коды прикладного ПО на электронном носителе (в случае внесения изменений); – Инструкция по сборке и развертыванию (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство пользователя (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство администратора (в случае внесения изменений); – Документ о приемке Начало: с 11.09.2026 Окончание: не позднее 15.12.2026 - Работы по развитию Системы (за исключением этапов проведения опытной эксплуатации и услуг по технической поддержке) могут быть выполнены досрочно. При досрочном выполнении работ (этапов работ) Подрядчик в письменной форме уведомляет Заказчика о готовности представить для приемки результаты проведения работ в соответствии с требованиями Контракта. Подрядчик также вправе досрочно приступать к работам в рамках очередного этапа при наличии технической, организационной готовности - при условии получения соответствующего согласования Заказчиком. Сдача-приемка результатов выполненных работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная, техническая документация, а также результаты Работ по каждому этапу предоставляется Заказчику в порядке, предусмотренном Контрактом и настоящим Техническим заданием, до размещения Подрядчиком в Единой информационной системе в сфере закупок документа о приемке. Документ о приемке размещается в ЕИС по каждому этапу в соответствии с условиями Контракта. Согласование документов осуществляется в электронном виде посредством переписки с адресов электронной почты Заказчика и Подрядчика, указанных в контракте. - Сдача-приемка результатов выполненных работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная техническая документация, а также результаты работ предоставляются Заказчику в порядке, предусмотренном Контрактом и ТЗ, до размещения Подрядчиком в ЕИС документа о приемке. Документ о приемке размещается в ЕИС по каждому этапу в соответствии с условиями Контракта. Этапы выполнения работ по развитию Модуля СЦ приведены в Таблице 11. Таблица 11. Этапы выполнения работ по развитию Модуля СЦ. № этапа Наименование этапа Результат (отчетная документация) Срок исполнения этапа - 6. ПОРЯДОК РАЗРАБОТКИ МОДУЛЯ СЦ - Проектирование Модуля СЦ должно включать разработку следующих документов: – Ведомость технического проекта; – Ведомость машинных носителей информации – Пояснительная записка; – Описание информационного обеспечения системы; – Описание автоматизируемых функций; – Схема функциональной структуры; – Описание организации информационной базы; – Руководство по безопасной разработке программного обеспечения; – Описание программного обеспечения; – Макеты экранных форм компонента «Интерактивная карта». Структура документов должна соответствовать ГОСТ Р 59795-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов». Разработка Модуля СЦ должна включать в себя: – разработку программного обеспечения в части новых функций Модуля СЦ; – сборка исходного кода, развертывание и настройку доработанного программного обеспечения Модуля СЦ на вычислительных мощностях Заказчика (тестовый контур); – Комплект рабочей документации на Модуль СЦ; – разработку документа «Программа и методика предварительных испытаний»; – разработку документа «Программа и методика приемочных испытаний»; – разработку документа «Программа опытной эксплуатации». Структура документов должна соответствовать ГОСТ Р 59795-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов». В ходе выполнения работ формируется правоустанавливающая, отчетная, рабочая и техническая документация в соответствии с Контрактом и Календарным планом, приведенном в разделе 5. - - Значение характеристики не может изменяться участником закупки - 6.1. Сведения о гарантийном обслуживании Модуля СЦ Под гарантией понимается устранение Подрядчиком своими силами и за свой счет допущенных по его вине недостатков, выявленных после приемки выполненных Работ, как в работе самой Модуля СЦ, так и недостатков в отчетной документации. Если в период гарантийного срока обнаружатся недостатки, то Подрядчик обязан устранить их за свой счет, в сроки, установленные Заказчиком. Гарантийный срок в этом случае продлевается на период устранения недостатков. Срок гарантии: 1 год с даты приемки Заказчиком результатов исполнения Этапа № 9 контракта. Подрядчиком должны быть внесены соответствующие исправления в техническую и рабочую документацию (указанную в пунктах 5 и 6 настоящего ТЗ), связанные с устранением замечаний к работе Модуля СЦ или в случае выявления Заказчиком недостатков в такой документации в период гарантийного срока. Внесение изменений в документацию технического и рабочего проектирования осуществляется в соответствии с ГОСТ 2.503-2023 и ГОСТ Р 2.504-2021. - 7. ПОРЯДОК КОНТРОЛЯ И ПРИЕМКИ РЕЗУЛЬТАТОВ ВЫПОЛНЕНИЯ РАБОТ ПО РАЗВИТИЮ МОДУЛЯ СЦ - До момента подключения внешних ИС, Подрядчиком могут быть использованы эмуляторы ИС для прохождения предварительных испытаний, опытной эксплуатации и приемочных испытаний. В рамках опытной эксплуатации должны быть проведены мероприятия по нагрузочному тестированию Модуля СЦ. Документ «Программа и методика приемочных испытаний» должен быть разработан с учетом недостатков, выявленных в ходе опытной эксплуатации, утвержден Заказчиком до начала приемочных испытаний, при этом проверки Модуля СЦ в части не устраненных недостатков, выявленных в процессе опытной эксплуатации, должны быть вынесены в отдельный раздел «Программы и методики приемочных испытаний». В процессе приемочных испытаний должно быть проверено устранение недостатков, полученных в ходе опытной эксплуатации. После завершения устранения всех замечаний, препятствующих приемке Системы в эксплуатацию, перечисленных в Протоколе приемочных испытаний, Подрядчик должен письменно уведомить Заказчика о том, что все замечания устранены, после чего приемочные испытания по решению Заказчика могут быть проведены повторно. Процедура приемочных испытаний проводится до подписания Протокола приемочных испытаний, не содержащего замечаний, препятствующих приемке Системы в эксплуатацию. Приемочные испытания Системы считаются завершенными успешно, если Протокол приемочных испытаний не содержит замечаний, препятствующих приемке Системы в эксплуатацию - - Значение характеристики не может изменяться участником закупки - Испытания должны быть организованы и проведены в соответствии с ГОСТ Р 59792-2021 «Информационная технология. Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем». Должны быть проведены следующие виды испытаний: – предварительные испытания; – опытная эксплуатация; – приемочные испытания. Указанные виды испытаний проводятся в отношении не функциональных требований и функциональных возможностей, разрабатываемых в соответствии с настоящим ТЗ. Отдельные виды испытаний проводятся поэтапно в сроки, установленные Календарным планом. Предварительные испытания, опытная эксплуатация, приемочные испытания проводятся комиссией, создаваемой организационно-распорядительным документом Заказчика, который должен определять состав комиссии, порядок ее работы. Методы предварительных испытаний и порядок их проведения должны быть определены в документе «Программа и методика предварительных испытаний», который должен быть утвержден Заказчиком до начала предварительных испытаний. По результатам предварительных испытаний оформляется Протокол предварительных испытания и Акт о приемке в опытную эксплуатацию. Порядок проведения и методы испытаний во время опытной эксплуатации должны быть определены в документе «Программа опытной эксплуатации», который должен быть утвержден Заказчиком до начала опытной эксплуатации. Ход и результаты опытной эксплуатации отражаются в документе «Журнал опытной эксплуатации», и учитываются в ходе приемочных испытаний. По результатам опытной эксплуатации подписывается Акт о завершении опытной эксплуатации - 8. ТРЕБОВАНИЯ К СОСТАВУ И СОДЕРЖАНИЮ РАБОТ ПО ПОДГОТОВКЕ МОДУЛЯ СЦ К ВВОДУ В ЭКСПЛУАТАЦИЮ - По результатам проведения приемочных испытаний оформляется Протокол приемочных испытаний и Акт приемки в эксплуатацию. В случае, если взаимодействие с внешними системами не может быть проверено на средах постоянной эксплуатации взаимодействующих систем (по причине неготовности со стороны внешней системы или иным причинам), функции взаимодействия, разработанные в соответствии с требованиями ТЗ, должны быть проверены на тестовых данных с использованием программ-имитаторов взаимодействия. По результатам выполнения этапа приемочных испытаний должны быть подготовлены материалы для регистрации доработанной версии Модуля СЦ (объекта учета) в НФАП в соответствии с требованиями постановления Правительства Российской Федерации от 30 января 2013?г. №?62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин» (с изменениями и дополнениями) в части обязательности размещения результатов работ в национальном фонде алгоритмов и программ для электронных вычислительных машин. Сдача-приемка результатов выполнения Работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная, техническая документация, а также программное обеспечение предоставляется Заказчику в порядке, предусмотренном Контрактом и ТЗ до размещения Подрядчиком в Единой информационной системе в сфере закупок документа о приемке. Результаты проведения опытной эксплуатации, предварительных и приемочных испытаний должны быть зафиксированы в соответствующих протоколах и актах. Выявленные отклонения от настоящего ТЗ, оформляются как недостатки Модуля СЦ - - Значение характеристики не может изменяться участником закупки - Протоколы предварительных и приемочных испытаний должны содержать вывод о соответствии Модуля СЦ предъявляемым требованиям, а также сроки устранения замечаний и реализации рекомендаций, сформулированных комиссией в ходе предварительных и приемочных испытаний. Условием для передачи Модуля СЦ в промышленную эксплуатацию является устранение всех замечаний. Документация на Модуль СЦ и ее части (техническая и рабочая) должна содержать исчерпывающее описание принятых проектных решений в объеме, достаточном для ее дальнейшего развития и эксплуатации. Техническая и рабочая документация должна содержать описание разработанных результатов работ, в том числе программ для ЭВМ, прикладных программных интерфейсов, алгоритмов и протоколов информационного взаимодействия, технических требований, спецификаций и форматов обмена данными для взаимодействия с другими информационными системами, в объеме, достаточном для их установки, настройки, эксплуатации и развития в дальнейшем без привлечения Подрядчика. Исходные коды передаются в виде и составе, позволяющем провести: – сборку (компиляцию) Модуля СЦ в контролируемой Заказчиком среде; – установку полученной Модуля СЦ на специально подготовленную контролируемую Заказчиком инфраструктуру; – проверку функциональных возможностей Модуля СЦ; – оформление Модуля СЦ в качестве объекта национального фонда алгоритмов и программ для электронных вычислительных машин - 8.1. Требования, предъявляемые в соответствии с Приказом Минцифры России от 17.12.2020 № 715 «Об утверждении типовых условий контрактов на выполнение работ по созданию и (или) развитию (модернизации) государственных (муниципальных) и (или) иных информационных систем» Передача исходных кодов, разработанных в ходе выполнения работ, программ для электронных вычислительных машин (далее – программа для ЭВМ) должна сопровождаться передачей всех необходимых для сборки и запуска программы для ЭВМ библиотек зависимостей, программных сценариев (скриптов) для проведения установки (развертывания) программы для ЭВМ. Подрядчик в процессе сдачи-приемки работ по Контракту должен провести демонстрацию процесса и установки (развертывания) разработанных программ для ЭВМ. Документация на Модуль СЦ должна содержать описание принятых проектных решений в объеме, достаточном для ее дальнейшего развития и эксплуатации - 9. ТРЕБОВАНИЯ К ДОКУМЕНТИРОВАНИЮ - 9.1. Общие требования Документация на Модуль СЦ должна быть разработана в составе, указанном в разделах 5-8 данного ТЗ, и должна удовлетворять требованиям комплекса стандартов и руководящих документов на автоматизированные системы: – ГОСТ Р 2.105-2019 в части оформления текстовых документов; – ГОСТ 34.201-2020 в части наименования и обозначения документов. Документация на Модуль СЦ должны оформляться на листах формата А4. Допускается для размещения рисунков и таблиц использование листов формата А3 с подшивкой по короткой стороне листа. Документы объемом более 25 (двадцати пяти) листов должны содержать информационную часть, состоящую из аннотации и содержания. Исходные коды должны быть представлены в 1 (одном) экземпляре на электронном носителе, отчетные материалы должны быть представлены в 2 (двух) экземплярах на бумажном носителе (по одному экземпляру для Заказчика и Подрядчика) и в 1 (одном) экземпляре на электронном носителе в формате документов DOCX и PDF. При разработке документов на Модуль СЦ допускается отклонение от требований комплекса стандартов, описанных выше. Документам на Модуль СЦ должны в обязательном порядке присваиваться уникальные децимальные номера в соответствии с порядком, установленном в ГОСТ 34.201-2020. Документ «Программа и методика предварительных испытаний» должен включать приложения с формой протокола предварительных испытаний и формой акта приемки в опытную эксплуатацию. Документ «Программа опытной эксплуатации» должен включать приложение с формой журнала опытной эксплуатации. Документ «Программа и методика приемочных испытаний» должен включать приложения с формой протокола приемочных испытаний и формой акта приемки в эксплуатацию - - Значение характеристики не может изменяться участником закупки - 10. ИСТОЧНИКИ РАЗРАБОТКИ - 10.1. Список литературы Специальная литература для разработки ТЗ не использовалась. 10.2. Нормативно-методические документы Список используемых нормативно-методических документов представлен в разделе 1.6 технического задания. ? Приложение А Эскизы визуального оформления компонента «Интерактивная карта» - - Значение характеристики не может изменяться участником закупки - Приложение Б Параметры оказания услуг - 1 Режим работы Системы Круглосуточно (24х7) 2 Режим доступности информационно-консультационной поддержки пользователей Системы 2.1 Прием и регистрация обращений (заявок) в СРО Регистрация обращений (заявок) производится круглосуточно в режиме 24х7, без праздников и выходных дней. Обработка заявок первой линией поддержки осуществляется в рабочие дни с 9 до 18 часов 2.2 Консультирование сотрудников Заказчика и пользователей Системы в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 3 Режим доступности по решению инцидентов, связанных с работой ППО: 3.1 - приоритет «Критический» Круглосуточно (24х7) 3.2 - приоритет «Высокий» Круглосуточно (24х7) 3.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 3.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4 Режим доступности услуг по адаптации, конфигурации и коррекционному сопровождению Системы 4.1 - приоритет «Критический» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.2 - приоритет «Высокий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 5 Режим доступности по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности 5.1 - приоритет «Критический» Круглосуточно (24х7) 5.2 - приоритет «Высокий» Круглосуточно (24х7) 5.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 5.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) - - Значение характеристики не может изменяться участником закупки - Таблица Б.1.2. Сроки предоставления отчетности, с момента получения запроса № п/п Параметр Значение 1 Предоставление отчета об оказанных услугах за произвольный период 10 рабочих дней 2 Предоставление подробной информации по инциденту с приоритетом «Критический» 16 рабочих часов 3 Предоставление актуализированной документации 10 рабочих дней - Б.1. Базовые параметры оказания Услуг Базовые параметры оказания Услуг приведены ниже: – режимы оказания Услуг (таблица Б.1.1); – сроки предоставления отчетности (таблица Б.1.2). Таблица Б.1.1 - Режимы оказания Услуг № п/п Параметр Значение - Б.2. Приоритеты и регламентные сроки решения обращений (заявок) В зависимости от уровня сбоя в работе Системы обращению (заявке) присваивается один из следующих приоритетов, а также в зависимости от приоритета обращения (заявки) устанавливаются следующие контрольные сроки решения в соответствии с таблицей ниже (Таблица Б.2.1). Таблица Б.2.1 – Приоритеты и регламентные сроки решения обращений (заявок) № п/п Приоритет Максимальное время реагирования Время решения (срок выполнения) Описание приоритета По информационно-консультационной поддержке сотрудников Заказчика и пользователей Системы 1 - не более 1 часа не более 10 часов - По решению инцидентов, связанных с работой ППО: 1 Критический не более 30 минут не более 4 часов - полная недоступность ППО; - недоступность ключевых функций - ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО; - невозможность информационного обмена с ППО для ИС более 4 часов 2 Высокий не более 1 часа не более 8 часов - ошибки/сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; - снижение быстродействия СПО (время отклика ППО на операции превышает 30 секунд); - недоступность управления правами и ролями пользователей 3 Средний не более 4 часов не более 24 часов - невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым -недоступность функции формирования отчетов 4 Низкий не более 8 часов не более 40 часов - отклонение в работе ППО, не влияющее на корректную работу функций; - другие сбои и ошибки, затрагивающие основные функции ППО - По адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) 1 Критический не более 40 минут не более 8 часов - изменения, необходимые при проведении аварийно-восстановительных работ для возобновления работоспособности Системы; - изменения, связанные с критичными ошибками, блокирующими возможность оказания государственных услуг и/или чтение и внесение данных в Систему 2 Высокий не более 1 часа не более 40 часов - изменения, относящиеся к обеспечению работоспособности основной функциональности Системы, устраняют выявленные дефекты в работе Системы, оказывающие существенное влияние на работу пользователей в Системе; - изменения, затрагивающие три и более подсистемы/модуля Системы для адаптации 3 Средний не более 4 часов не более 72 часов - изменения, связанные с развитием/улучшением/оптимизацией Системы и выводом новой функциональности в штатном режиме для одного-двух модулей/подсистем; - изменения, связанные с развитием интеграционных механизмов Системы, например обновление существующих и/или реализация новых видов сведений СМЭВ, обновление существующих и/или реализация новых API, адаптация и/или изменение механизмов импорта и экспорта данных Системы и т.д. 4 Низкий не более 8 часов не более 160 часов - изменения, связанные с ошибками/корректировкой/изменением в отображении информации в пользовательском графическом интерфейсе Системы (графика, текст, органы управления, элементы интерфейса) - По устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности 1 Критический не более 30 минут не более 24 часов - критические уязвимости, влияющие на возможную полную недоступность ППО, ключевых функций Системы, ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО без возможности восстановления работоспособности Системы. - Критический уровень CVSS > 8.0 2 Высокий не более 1 часа не более 84 часов - критические уязвимости, влияющие на ошибки и сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО. - Высокий уровень CVSS 5.0 - 8.0 3 Средний не более 4 часов не более 120 часов - уязвимости, влияющие на невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым - Средний уровень CVSS 2.0 - 4.9 4 Низкий не более 8 часов не более 160 часов - уязвимости, влияющие на отклонение в работе ППО, не влияющее на корректную работу функций; - другие сбои и ошибки, затрагивающие основные функции ППО - Низкий уровень CVSS < 2.0 - Взаимодействие Заказчика и Подрядчика в части регистрации и контроля времени реагирования и решения обращения (заявки) осуществляется через СРО. Заказчик предоставляет Подрядчику доступ к СРО после заключения Контракта. Поступившие от разных пользователей заявки по поводу однотипных инцидентов или имеющие общую причину должны объединяться в одну заявку. Срок выполнения включает время диагностики инцидента, в ходе которого определяется причина инцидента (проблемы) и способ его устранения. Подрядчик должен обеспечить функционирование Модуля СЦ в соответствии с требованиями и параметрами, указанными в настоящем ТЗ и Регламенте оказании услуг. Основные параметры быстродействия типовых операций в Модуле СЦ указаны в таблице ниже (таблица Б.2.2). Таблица Б.2.2 - Параметры быстродействия Модуля СЦ № п/п Наименование параметра Значение (секунд) 1 Среднее время получения сообщения из очереди сообщений 10 2 Среднее время получения ответа от Системы 5 3 Среднее время открытия карточки реестра 5 - Приложение В Регламент оказания услуг - Приложение Г Форма Отчета об оказанных услугах Отчет об оказанных услугах за этап «наименование этапа» в период с «__» _________ по «__» _________. № п/п Наименование услуги Общее количество Номер ОРС Краткое Описание Время реагирования по ТЗ Время реагирования фактическое Время решения по ТЗ Время решения фактическое Результат соблюдения времени реагирования Результат соблюдения времени решения Примечание 1 Услуги по информационно-консультационной поддержке работников Заказчика 2 546782 Консультация по работе Модуля СЦ 1 2 10 часов 11 часов Нет Нет 567123 Консультация по схеме БД 1 1 10 часов 1 час Да Да 2 … … Заказчик Подрядчик /Должность/ /Должность/ ____________________ /Ф.И.О/ ___________________ /Ф.И.О/ М.П. М.П. «_____»_______________________202_г. «_____»_______________________202_г - - Значение характеристики не может изменяться участником закупки - Приложение 1 к Отчету об оказанных услугах Журнал обращений (заявок) на оказание услуги по информационно-консультационной поддержке пользователей Системы (шаблон) Наименование Исполнителя в этапе «наименование этапа» в период с ________________ по _______________ оказал(о) Услугу по поддержке пользователей Системы в объеме, указанном в Таблице 1 Таблица 1 - Журнал обращений (заявок) пользователей Системы № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. ИТОГО зарегистрировано: Всего обращений (заявок): ________ ИТОГО решено: Всего обращений (заявок): ________ - Приложение 2 к Отчету об оказанных услугах Журнал обращений (заявок) по решению инцидентов, связанных с работой ППО (шаблон) Наименование Исполнителя в этапе «наименование этапа» в период с ________________ по _______________ оказал(о) Услугу по решению инцидентов в объеме, указанном в Таблице 1. Таблица 1 - Журнал по решению инцидентов № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. ИТОГО зарегистрировано: Всего инцидентов: ________ ИТОГО решено: Всего инцидентов: ________ - Приложение 3 к Отчету об оказанных услугах Журнал обращений (заявок) выполнения адаптационного, конфигурационного и коррекционного сопровождения Системы (шаблон) Журнал выполнения адаптации, конфигурации и коррекции Системы сформирован за этап «наименование этапа» в период с «__» _________ по «__» ____________ и представлен в таблице ниже (Таблица 1). Таблица 1 - Журнал выполнения адаптации, конфигурации и коррекции сопровождения Системы № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. Количество выполненных заявок за этап: ________ - Приложение 4 к Отчету об оказанных услугах Журнал обращений (заявок) по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности (шаблон) Журнал обращений (заявок) по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности сформирован за этап «наименование этапа» в период с «__» _________ по «__» ____________ и представлен в таблице ниже (Таблица 1). Таблица 1 - Журнал выполнения заявок по устранению уязвимостей в ППО № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. Количество выполненных заявок за этап: ________ - Термины и сокращения В настоящем регламенте используются следующие термины и сокращения на русском и английском языках: Термины/сокращения Полное наименование/описание БЗ (База знаний) База данных Системы регистрации обращений (заявок), созданная для сбора, хранения и поиска способов решения известных проблем в рамках Системы Жизненный цикл обращения (заявки) Совокупность статусов, по которым проходит обращение (заявка), и правила перехода обращения (заявки) из одного статуса в другой Заказчик ФГБУ «СИЦ Минтранса России» – Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» ЗНИ Запрос на изменение – тип заявки, предполагающий внесение изменений в прикладное программное обеспечение Системы ЗНО Запрос на обслуживание – тип заявки, предполагающий работы по предоставлению консультации, предоставление доступа к Системе или стандартизированные типовые изменения конфигураций Системы Инцидент Тип заявки, классифицируемый как нештатное событие в работе компонентов функциональных задач Системы, которое привело или может привести к нарушению или снижению качества функционирования Системы ИС Информационная система Исполнитель Организация, которая определяется по результатам конкурсных процедур Классификация Анализ и заполнение классификационных полей справочными значениями, определяющими последовательность действий и этапов жизненного цикла заявки, а также порядок рассмотрения заявок Консультация Разъяснения по алгоритму работы, требуемых настроек прикладного программного обеспечения и технологии обработки данных при работе с Системой, предоставление информации Маршрутизация Определение процесса движения обращения (заявки) в Системе управления заявками между уровнями технической поддержки и организационными структурами на уровнях поддержки путем назначения обращения (заявки) в соответствии с его классификацией и выставленным приоритетом - Обращение (заявка) Устное или письменное обращение пользователя АСУ ТК с вопросом, касающимся работоспособности АСУ ТК, по одному из определённых каналов связи: электронная почта, Система регистрации обращений (заявок) Пользователь Инициатор обращения (заявки) или пользователь Системы ППО Прикладное программное обеспечение Предмет обращения Справочник, классифицирующий типовые запросы в Системе регистрации обращений (заявок), характерные для Системы, выбранное значение определяет маршрутизацию обращения (заявки) (группу ответственных сотрудников) Приоритизация Значение, определяющее время, очередность решения обращений (заявок), ресурсы, привлекаемые для решения обращений (заявок), . Приоритет устанавливается в соответствии с масштабом выявленной проблемы, которая привела или может привести к нарушению или снижению качества функционирования Системы Релиз Выпуск версии прикладного программного обеспечения Системы, от разработки до тестирования и планового обновления Системы на продуктивной среде для установки изменений, связанных с развитием/улучшением/оптимизацией Системы Система, АСУ ТК, Информационно-аналитическая система регулирования на транспорте Информационно-аналитическая система, предназначенная для автоматизации и информационно-аналитического обеспечения процессов управления развитием транспортного комплекса Российской Федерации, обеспечения публичности деятельности органов государственного управления транспортным комплексом, а также обеспечения процессов оказания государственных услуг в электронном виде в сфере транспорта СМЭВ Система межведомственного электронного взаимодействия СПО Системное программное обеспечение СРО Система регистрации обращений (заявок) Статус обращения (заявки) Текущее состояние обращения (заявки) в жизненном цикле процесса оказания технической поддержки Системы СУБД Система управления базами данных - Таблица 1 - Типы обращений (заявок) Тип обращения (заявки) Описание Запрос на обслуживание Подготовка SQL запроса к СУБД для решения прикладной задачи и д р. – запрос на любое действие, не являющееся запросом информации и несовершенный на основе происшествия, прямо или косвенно влияющего на работу Системы Консультация (входит в тип обращения (заявки) «Запрос на обслуживание») «Где взять / куда обратиться...?», «Как сделать / выполнить…», «Как это работает…?» - запрос, имеющий своей целью получение информационной поддержки Инцидент Разбор ошибок/сбоев и подготовка материалов (корректировочных релизов, инструкций) для Заказчика для устранения ошибок/сбоев, которые приводят к частичному и полному нарушению работоспособности всех или отдельных функций ППО. Подготовка изменения и материалов, необходимых для проведения аварийно-восстановительных работ для возобновления работоспособности Системы. ЗНИ Подготовка изменений, связанных с изменением, улучшением/оптимизацией Системы и выводом новой модифицированной функциональности в штатном режиме. Подготовка изменений, связанных с модификацией существующих и/или реализация новых интеграционных механизмов для получения/обработки данных внешних систем. Подготовка изменений графического интерфейса по требованиям Заказчика - 3.2 Участники технической поддержки, осуществляющие сопровождение обращений (заявок) Техническая поддержка Системы должна быть организована на трех уровнях: 1. Первый и второй уровни технической поддержки организуется Заказчиком. 2. Третий уровень технической поддержки организуется Исполнителем. Зона ответственности каждого уровня технической поддержки указана в Таблице 2. Таблица 2 - Зона ответственности каждого уровня технической поддержки Участники технической поддержки Описание - Первый уровень технической поддержки (далее – 1-й уровень) Группа ответственных сотрудников 1-го уровня Заказчика, осуществляющая прием и первичную обработку обращений (заявок) (описание предмета обращения, первичная классификация и приоритизация, определение назначения, маршрутизация обращений (заявок) по назначению), руководствуется в своей работе настоящим Регламентом и БЗ, наполняемой 2-м уровнем поддержки, самостоятельно решает часть обращений (заявок), связанных с недостаточной квалификацией пользователей или настройками в рамках своей компетенции. В случае невозможности решения обращений (заявок) на 1-ом уровне ответственный сотрудник передает ее на 2-й уровень - Второй уровень технической поддержки (далее – 2-й уровень) Группа ответственных сотрудников 2-го уровня Заказчика по установленным компетенциям (информационная безопасность, сопровождение и эксплуатация информационно-аналитических систем, развитие информационно-аналитических систем, техническая поддержка информационно-аналитических систем) отвечает за поддержание работоспособности Системы, обработку обращений (заявок) и их решение в регламентные сроки в соответствии с установленными приоритетами. Осуществляет информационно-консультационную поддержку пользователей Системы в рамках своей компетенции. Оказывает экспертную помощь ответственным сотрудникам 1-го уровня в части формирования БЗ, содержащей ответы на часто задаваемые вопросы пользователей, с целью передачи знаний, навыков и инструментария на 1-й уровень для ускорения решения обращений (заявок). В случае невозможности решения обращения (заявки) на 2-ом уровне ответственный сотрудник передает его на 3-й уровень. При выявлении необходимости изменений в ППО Системы инициирует формирование обращения (заявки) и направляет его на группу ответственных сотрудников 3-го уровня по соответствующему классификатору (ЗНО, ЗНИ, и т.д.) - Уровень технической поддержки Организационно-структурная часть технической поддержки, имеющая определённые организационно-нормативными документами зоны ответственности, обязанности, а также временные нормативы, в течение которых эти обязательства должны выполняться либо эскалироваться на следующий уровень технической поддержки Услуги Услуги по технической поддержке Информационно-аналитической системы регулирования на транспорте АСУ ТК ФИО Фамилия, имя, отчество Эскалация Процедура повышения внимания к обращению (заявке) путем повышения его приоритета и/или передачи на следующий уровень технической поддержки, а также привлечение ролей, которые могут принимать решения без передачи на следующий уровень технической поддержки API Англ. Application Programming Interface — программный интерфейс приложения, интерфейс прикладного программирования — описание способов (набор классов, процедур, функций, структур или констант), которыми одна компьютерная программа может взаимодействовать с другой программой - CVSS Англ. Common Vulnerability Scoring System - открытый стандарт, используемый для расчета количественных оценок уязвимости в безопасности компьютерной системы, обычно с целью понять приоритет ее исправления. В современном инструментарии информационной безопасности используется версия 3.0 и выше с дополнительными метриками к базовым оценкам ID Англ. Identifier – идентификатор, уникальный признак объекта, позволяющий отличать его от других объектов, то есть, идентифицировать SLA Англ. Service Level Agreement - утвержденные условия по обработке обращения (заявки) с установленными метриками времени, которые определяют пороговые значения для эскалации в зависимости от статуса обращения (заявки) (например, время реакции – время от регистрации до осуществления первичной обработки, время решения – время от регистрации обращения (заявки) до его решения и т.д.) SQL Англ. Structured Query Language — «язык структурированных запросов», — декларативный язык программирования, применяемый для создания, модификации и управления данными в реляционной базе данных, управляемой соответствующей СУБД - 1 Общие сведения 1.1 Полное наименование Услуг Оказание услуг по технической поддержке Модуля СЦ АСУ ТК в 2026 году. 1.2 Предмет Регламента оказания услуг Требования Технического задания - 2 Общие положения 2.1 Цель и задачи оказания услуг Целью технической поддержки Системы является обеспечение ее стабильного и безопасного функционирования и эксплуатации, предупреждение, выявление и устранение сбоев в работе Системы и минимизация их неблагоприятного влияния. Для достижения поставленной цели требуется решение следующих задач: 1. Обеспечение информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы. 2. Поддержание параметров функционирования ППО Системы, удовлетворяющих требованиям производственных процессов, включая их непрерывность. 3. Обеспечение бесперебойного функционирования ППО и своевременное устранение сбоев и аварийных ситуаций в Системе. 4. Своевременное устранение уязвимостей при выявлении таковых, в соответствии с требованиями к обеспечению информационной безопасности. 5. Адаптация, конфигурирование, коррекция программного обеспечения в соответствии с изменениями нормативно-правовой базы и запросами уполномоченных сотрудников органов государственной власти, включая выполнение процедур тестирования и участие в обновлениях ППО на стендах Заказчика. 6. Обеспечение сохранения работоспособности ППО в изменяемой среде эксплуатации. 7. Ведение документации по настоящему контракту и инициирование актуализации документации на Систему по результатам обработки запросов Заказчика и внесения соответствующих изменений в ППО - Третий уровень технической поддержки (далее – 3-й уровень) Группа ответственных сотрудников Исполнителя, отвечающая за устранение сбоев и аварий, проведение информационно-консультационной поддержки пользователей Системы, проведение адаптации и конфигурирования Системы в объемах действующих контрактов на оказание технической поддержки - 3.3 Перечень и описание статусов обращений (заявок) В Таблице 3 приведен перечень статусов обращений (заявок), действующий в СРО, и их описание. Таблица 3 - Перечень статусов обращений (заявок) и их описание Статус Описание Зарегистрирован Обращение (заявка) принято и зарегистрировано Направлен в группу Присваивается при назначении ответственными сотрудниками 1-го уровня группе ответственных сотрудников 2-го уровня по тематике обращения (заявки) после заполнения всей необходимой информации и полей обращения (заявки), а также при его передаче между группами 2-го уровня Передан в группу Присваивается при передаче обращения (заявки) ответственными сотрудниками 2-го уровня на группу ответственных сотрудников 3-го уровня Назначен Присваивается при назначении обращения (заявки) на ответственного сотрудника для его решения в рамках компетенции В работе Присваивается при приеме обращения (заявки) в работу ответственным сотрудником для его решения Решен Присваивается ответственным сотрудником, выполнившим работы по обращению (заявке) Закрыт Присваивается автоматически при решении запроса по обращению (заявке), а также отсутствии дополнительных запросов пользователя в соответствии с действующим SLA, или при подтверждении решения обращения (заявки) со стороны пользователя Запрос доп. информации Присваивается при необходимости запроса дополнительной информации и/или уточнения предмета обращения по обращению (заявке) у пользователя Ответ предоставлен Присваивается после ответа пользователем на запрос дополнительной информации Отклонен Присваивается, если обращение (заявка) не актуальна (по информации от пользователя), отсутствует техническая возможность решения обращения (заявки), предмет обращения не входит в компетенции технической поддержки, или существует влияние доработки на другие компоненты, что нарушает общий порядок работы Системы - Согласование Присваивается при необходимости согласования направления обращения (заявки) ответственным сотрудником Заказчика на 3-й уровень Анализ Присваивается при проведении анализа на предмет возможности внесения изменений, связанных с развитием/улучшением/оптимизацией Системы и выводом новой функциональности и оценке ресурсоемкости Тестирование Присваивается Исполнителем при завершении разработки и проведенном предварительном тестировании для последующего осуществления приемочного тестирования Специалистом 2-го уровня Релиз Присваивается ответственным сотрудником Заказчика при принятии решения о возможности вывода доработки в продуктивную среду Утверждение заказчиком Присваивается при согласовании группой профильных специалистов на 2-м уровне поддержки с пользователем технического задания для внесения изменений, связанных с развитием/улучшением/оптимизацией Системы и выводом новой функциональности Доработка Присваивается в случае несогласования Заказчиком работ, проведенных Исполнителем в рамках контрактных обязательств, по внесению изменений, связанных с развитием/улучшением/оптимизацией Системы и выводом новой функциональности в штатном режиме, и необходимости последующего направления Исполнителю для ее доработки Отложен Присваивается в случае невозможности выполнения запроса, изложенного в обращении (заявке), в связи с необходимостью запроса дополнительной информации у третьих сторон - Изменение приоритета уже зарегистрированного обращения (заявки) используется в случае появления новых обстоятельств, которые ведут к изменению влияния и/или срочности существующего обращения (заявки). При регистрации обращения (заявки) необходимо провести его приоритизацию. В процессе управления обращениями (заявками) каждому обращению (заявке) присваивается приоритет, принимающий одно из значений: Низкий, Средний, Высокий или Критический. В соответствии с приоритетом определяется время, очередность устранения, , ресурсы, привлекаемые для работ по обращению (заявке), а также может определяться порядок/процедура действий при работе с обращением (заявкой). Заказчиком в зависимости от уровня сбоя в работе Системы обращению (заявке) присваивается приоритет с указанием максимального времени реакции и решения в соответствии с требованиями, указанными в Приложении 2 к настоящему Регламенту - 4 Формы обращений (заявок) на оказание услуг по технической поддержке Системы, заполняемые в СРО 4.1. Форма обращения (заявки) на оказание услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы При подаче обращения (заявки) типа «ЗНО» в СРО указывается (Таблица 5): Таблица 5 – Описание атрибутов формы обращения (заявки) на оказание услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 5) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 5) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 5) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 5) Категория обращения: информационно-консультационная поддержка Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 5) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 5) Текст запроса на оказание услуги по информационно-консультационной поддержке сотрудников Заказчика Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 5) - На рисунке 5 приведена форма обращения (заявки) типа «ЗНО» в СРО. Рисунок 5 - Форма обращения (заявки) типа «ЗНО» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы, заполненную в свободной форме. - Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 8) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 8) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 8) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 8) Категория обращения (заявки): инцидент Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 8) Приоритет Время, очередность решения обращения (заявки), ресурсы, привлекаемые для решения обращения (заявки), порядок/процедура действий при решении обращения (заявки) – поле СРО «Приоритет» (см. рисунок 8) Тип изменения Справочник, классифицирующий типовые запросы характерные для Системы – поле СРО «Предмет обращения» (см. рисунок 8) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 8) Текст запроса на оказание услуги по обновлению или удалению уязвимых компонентов (библиотек) ППО в соответствии с требованиями к обеспечению информационной безопасности Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 8) - На рисунке 8 приведена форма обращения (заявки) типа «Инцидент» в СРО. Рисунок 8 - Форма обращения (заявки) типа «Инцидент» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуги по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности, заполненную в свободной форме - Приложение 1 к Регламенту Матрица ответственных за взаимодействия в рамках выполнения работ по техническому сопровождению Системы Таблица 1 – Ответственные за взаимодействия в рамках выполнения работ по техническому сопровождению Системы со стороны Исполнителя ФИО Должность Адрес электронной почты Телефон — — — Общий контакт - Приложение 2 к Регламенту Приоритеты и регламентные сроки решения обращений (заявок) Приоритеты и регламентные сроки решения обращений (заявок) приведены в таблице 1. Таблица 1 – Приоритеты и регламентные сроки решения обращений (заявок) № п/п Приоритет Максимальное время реагирования Время решения (срок выполнения) Описание приоритета - По информационно-консультационной поддержке сотрудников Заказчика и пользователей Системы 1 – не более 1 часа не более 10 часов – - Приложение Д Форма Протокола проверки результатов организационно-штатных и подготовительных мероприятий (шаблон) Протокол проверки результатов организационно-штатных и подготовительных мероприятий Настоящий Протокол содержит результаты проверки организационно-штатных и подготовительных мероприятий, проведенных Исполнителем (Таблица Д.1). Таблица Д.1. Протокол проверки результатов № Мероприятия Подготовительного этапа Результат проверки 1. Определить и направить Заказчику документ «Ответственные за взаимодействия в рамках выполнения работ по техническому сопровождению Системы со стороны Исполнителя». Документ содержит контактную информацию (ФИО, должность, адрес электронной рабочей почты, номер телефона) не менее чем о 2 лицах, ответственных за оказание услуг со стороны Подрядчика Выполнено/Не выполнено 2. Обеспечить подключение специалистов Подрядчика к Системе Выполнено/Не выполнено 3. Обеспечить подключение специалистов Подрядчика к СРО Выполнено/Не выполнено Заказчик Подрядчик /Должность/ /Должность/ ____________________ /Ф.И.О/ ___________________ /Ф.И.О/ М.П. М.П. «_____»_______________________202_г. «_____»_______________________202_г - 2.2 Общее описание процесса оказания сопровождения (технической поддержки) Системы Процесс оказания технической поддержки Системы включает: 1. Поступление обращений (заявок) от пользователей и их регистрацию. 2. Сопровождение обращений (заявок) в соответствии с их классификацией и приоритизацией, в том числе, с их последующей эскалацией. 3. Определение ролей и регламент их взаимодействия при осуществлении деятельности по процессу. 4. Решение обращений (заявок) в установленные настоящим Регламентом сроки. 5. Взаимодействие между 1-м, 2-м и 3-м уровнями технической поддержки, в том числе, с формированием заданий для сопровождения Системы. 6. Контроль качества выполняемых Исполнителем работ, состоящий из проверки сценария, приводящего к ошибке, зафиксированной в Инциденте, и/или к ошибке воспроизведения, а также тестирование внесенных изменений в рамках ЗНИ. 7. Обеспечение мониторинга и проведение анализа процесса обработки поступающих в техническую поддержку обращений (заявок). Техническая поддержка реализуется путем проведения ответственными сотрудниками соответствующей информационно-консультационной деятельности в соответствии с определенными ролями, а также выполнения Исполнителем конкретных действий по своевременному выявлению причин сбоев и аварийных ситуаций и их устранению, а также по адаптации, конфигурированию, корректировке Системы, включая выполнение процедур тестирования и участия в обновлениях Системы. Все роли подразделяются на уровни поддержки, взаимодействующие между собой в соответствии с блок-схемой процесса технической поддержки. Общая схема процесса рассмотрения обращений (заявок) в соответствии с видами технической поддержки представлена на рисунке 1. . Рисунок 1 - Общая схема процесса рассмотрения обращений (заявок) в соответствии с видами технической поддержки - 2.3 Каналы связи Должна быть предусмотрена омниканальность в части приема обращений (заявок). Получение обращений (заявок) технической поддержкой происходит по следующим каналам связи: – СРО; – электронная почта; – телефонная линия. Исполнитель обеспечивает прием обращений (заявок) от Заказчика и предоставляет информацию в рамках оказания услуг по техническому сопровождению Системы, руководствуясь матрицей взаимодействия, приведенной в Приложении 1 к настоящему Регламенту - 3 Порядок оказания Услуг 3.1 Типы обращений (заявок) Обращения и заявки Заказчика классифицируются в соответствии с приоритетами и регламентными сроками, указанными в Приложении 2 к настоящему Регламенту. Регистрация обращений и заявок предусматривает создание новой записи в СРО с присвоением поступившему обращению или заявке (новой записи) уникального идентификатора. Запись в СРО должна содержать вопрос или проблему, которую требуется решить или оказать консультацию. Если обращение или заявка автоматически зарегистрированы в СРО при отправке представителем Заказчика, Исполнитель проверяет корректность указанного типа обращения (заявки) и может обратиться к Заказчику с просьбой корректировки, предоставив обоснования в соответствии с настоящей классификацией (Таблица 1) - 3.4 Порядок регистрации и сопровождения Заявок Порядок регистрации и сопровождения обращений (заявок) в рамках оказываемых услуг по технической поддержке Системы зависит от типа обращения (заявки): 1. Услуга по решению инцидентов, связанных с работой ППО – тип обращения (заявки) «Инцидент». 2. Услуга по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности – тип обращения (заявки) «Инцидент». 3. Услуга информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы – тип обращения (заявки) «Запрос на обслуживание» (в том числе, консультационный запрос). 4. Услуга адаптационного, конфигурационного и коррекционного сопровождения Системы (в рамках действующих программных модулей и функциональностей) – тип обращения (заявки) «Запрос на изменение». В случае недоступности СРО взаимодействие и информирование Исполнителем о ходе оказания услуги по обращению (заявке), изменению статусов обращений (заявок) осуществляется по согласованию с Заказчиком в соответствии с матрицей взаимодействия, представленной в Приложении 1 к настоящему Регламенту. - 3.4.1 Инцидент На рисунке 2 представлена функциональная схема регистрации и сопровождения обращений (заявок) типа «Инцидент». Рисунок 2 - Функциональная схема регистрации и сопровождения обращений (заявок) типа «Инцидент» 3.4.2 Запрос на обслуживание На рисунке 3 представлена функциональная схема регистрации и сопровождения обращения (заявки) типа «ЗНО». Рисунок 3 - Функциональная схема регистрации и сопровождения обращения (заявки) типа «ЗНО» 3.4.3 Запрос на изменение На рисунке 4 представлена функциональная схема регистрации и сопровождения обращений (заявок) типа «ЗНИ». Рисунок 4 - Функциональная схема регистрации и сопровождения обращений (заявок) типа «ЗНИ» - 3.5 Порядок классификации и приоритизации обращений (заявок) Классификация является начальной стадией процесса оказания технической поддержки, необходимой для идентификации обращения (заявки) и определения соответствующих действий для его обработки. Для проведения первичной классификации необходимо получить от пользователя и зафиксировать в описании обращения (заявки) подробные сведения о сути запроса, в том числе, для Инцидентов зафиксировать сценарий воспроизведения обнаруженной ошибки. Для проведения вторичной классификации необходимо провести анализ и диагностику для определения корневой причины и затронутой Инцидентом функциональной области (инфраструктура, сеть, ППО). В процессе классификации осуществляется первичная диагностика и оценка проблемы, описанной пользователем Системы в обращении (заявке), в части функционирования и/или удобства использования Системы. Корректная классификация позволяет увеличить скорость обработки обращения (заявки) и решения описанной в обращении (заявке) проблемы при минимальном привлечении ресурсов, в частности, за счет использования известных решений для типовых обращений (заявок), которые должны описываться в БЗ СРО. Классификация позволяет произвести первоначальное назначение обращения (заявки) на ответственного сотрудника и выставить приоритет с учетом приоритизации. Приоритизация применяется для определения критичности описанной в обращении (заявке) проблемы для функционирования ППО Системы. Приоритет рассмотрения обращения (заявки) определяется в процессе ее классификации на основании ряда параметров, вводимых при заполнении обращения (заявки). Приоритизация используется для того, чтобы при одновременном наличии нескольких обращений (заявок) в первую очередь рассматривалась обращения (заявки) с наивысшим приоритетом и не позднее установленных для данного приоритета сроков - 4.2. Форма обращения (заявки) на оказание услуги по решению инцидентов, связанных с работой ППО При подаче обращения (заявки) типа «Инцидент» в СРО указывается (Таблица 6): Таблица 6 – Описание атрибутов формы обращения (заявки) на оказание услуги по решению инцидентов, связанных с работой ППО Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 6) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 6) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 6,) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 6) Категория обращения (заявки): инцидент Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 6) Приоритет изменения Время - одно из значений: Низкий, Средний, Высокий или Критический. Определяет, очередность решения обращения (заявки), ресурсы, привлекаемые для решения обращения (заявки), порядок/процедура действий при решении обращения (заявки) – поле СРО «Приоритет» (см. рисунок 6,) - Тип изменения Справочник, классифицирующий типовые запросы характерные для Системы – поле СРО «Предмет обращения» (см. рисунок 6) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 6) Полное описание инцидента, включая скриншоты и описание шагов, приведших к неисправности Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 6) Однократность/неоднократность Круг пользователей или компьютеров, затронутых данным инцидентом Действия, предпринятые для самостоятельного решения инцидента (при наличии) Версии используемого программного обеспечения на клиентской рабочей станции, где воспроизводится ошибка (операционная система, прикладное программное обеспечение) Дополнительная информация - На рисунке 6 приведена форма обращения (заявки) типа «Инцидент» в СРО. Рисунок 6 - Форма обращения (заявки) типа «Инцидент» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуги по решению инцидентов, связанных с работой ППО, заполненную в свободной форме - По решению инцидентов, связанных с работой ППО 1 Критический не более 30 минут не более 4 часов – полная недоступность ППО; – недоступность ключевых функций; – ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО; – невозможность информационного обмена с ППО для ИС более 4 часов 2 Высокий не более 1 часа не более 8 часов – ошибки/сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; – снижение быстродействия СПО (время отклика ППО на операции превышает 30 секунд); – невозможность управления правами и ролями пользователей 3 Средний не более 4 часов не более 24 часов – невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым недоступность функции формирования отчетов 4 Низкий не более 8 часов не более 40 часов – отклонение в работе ППО, не влияющее на корректную работу функций; – другие сбои и ошибки, затрагивающие основные функции ППО - По адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) 1 Критический не более 40 минут не более 8 часов – изменения необходимые при проведении аварийно-восстановительных работ для возобновления работоспособности Системы; – изменения, связанные с критичными ошибками, блокирующими возможность оказания государственных услуг и/или чтение и внесение данных в Систему 2 Высокий не более 1 часа не более 40 часов – изменения относящиеся к обеспечению работоспособности основной функциональности Системы, устраняют выявленные дефекты в работе Системы, оказывающие существенное влияние на процесс оказания государственных услуг и работу пользователей в Системе; – изменения, затрагивающие три и более подсистемы/модуля Системы для адаптации 3 Средний не более 4 часов не более 72 часов – изменения, связанные с развитием/улучшением/оптимизацией Системы и выводом новой функциональности в штатном режиме для одного-двух модулей/подсистем; – изменения, связанные с развитием интеграционных механизмов Системы, например, обновление существующих и/или реализация новых видов сведений СМЭВ, обновление существующих и/или реализация новых API, адаптация и/или изменение механизмов импорта и экспорта данных Системы и т.д. 4 Низкий не более 8 часов не более 160 часов – изменения, связанные с ошибками/ корректировкой/изменение в отображении информации в пользовательском графическом интерфейсе Системы (графика, текст, органы управления, элементы интерфейса) - По устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности 1 Критический не более 30 минут не более 24 часов – критические уязвимости, влияющие на возможную полную недоступность ППО, ключевых функций Системы, ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО без возможности восстановления работоспособности Системы; – Критический уровень CVSS > 8.0 2 Высокий не более 1 часа не более 84 часов – критические уязвимости, влияющие на ошибки и сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; – Высокий уровень CVSS 5.0 - 8.0 3 Средний не более 4 часов не более 120 часов – уязвимости, влияющие на невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым; – Средний уровень CVSS 2.0 - 4.9 4 Низкий не более 8 часов не более 160 часов – уязвимости, влияющие на отклонение в работе ППО, не влияющее на корректную работу функций; – другие сбои и ошибки, затрагивающие основные функции ППО; – Низкий уровень CVSS < 2.0 - 4.3. Форма обращения (заявки) на оказание услуг по адаптационному конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) При подаче обращения (заявки) типа «ЗНИ» в СРО указывается (Таблица 7): Таблица 7 – Описание атрибутов формы обращения (заявки) на оказание услуг по адаптационному, конфигурационному и коррекционному сопровождению Системы Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 10) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 9) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 10) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 10) Категория обращения (заявки): запрос на изменение Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 7) Приоритет изменения Время, очередность решения обращения (заявки), ресурсы, привлекаемые для решения обращения (заявки), порядок/процедура действий при решении обращения (заявки) – поле СРО «Приоритет» (см. рисунок 7) Тип изменения Справочник, классифицирующий типовые запросы характерные для Системы – поле СРО «Предмет обращения» (см. рисунок 7) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 7) Текст запроса на оказание услуги по адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 7) - На рисунке 7 приведена форма обращения (заявки) типа «ЗНИ» в СРО. Рисунок 7 - Форма обращения (заявки) типа «ЗНИ» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуг по адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей), заполненную в свободной форме - 4.4. Форма обращения (заявки) на оказание услуги по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности При подаче обращения (заявки) типа «Инцидент» в СРО указывается (Таблица 8): Таблица 8 – Описание атрибутов формы обращения (заявки) на оказание услуг по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности

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

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

ФГБУ «СИЦ Минтранса России» Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации», Заказчик Федеральный закон № 44-ФЗ Федеральный закон от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» ФЗ Функциональная задача ФЗ «Реестр объектов» Функциональная задача «Формирование и ведение единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации» ФСБ России Федеральная служба безопасности Российской Федерации ФСТЭК России Федеральная служба по техническому и экспортному контролю ЧС Чрезвычайная ситуация ЭВМ Электронно-вычислительная машина API От англ. Application Programming Interface – интерфейс прикладного программирования – совокупность инструментов и функций в виде интерфейса для взаимодействия с программой CSS От англ. Cascading Style Sheets — каскадные таблицы стилей FPS От англ. frame per second - количество кадров в секунду HTML От англ. HyperText Markup Language - стандартный язык разметки документов, создающий основу и структуру всех веб-страниц JSON От англ. JavaScript Object Notation – текстовый формат обмена данными, основанный на JavaScript WebAssembly (Wasm) Открытый стандарт, представляющий собой низкоуровневый бинарный формат инструкций, который позволяет выполнять код, написанный на языках C++, Rust или Go, в браузерах с производительностью, близкой к нативной

Автоматизированная система (АС) Система, состоящая из комплекса средств автоматизации, реализующего информационную технологию выполнения установленных функций, и персонала, обеспечивающего его функционирование (ГОСТ Р 59853-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения») АРМ Автоматизированное рабочее место АСУ ТК, Система Информационно-аналитическая система регулирования на транспорте АТС Автоматическая телефонная станция БД База данных ГИС Государственная информационная система ГОСТ Государственный стандарт ГЦОД СИЦ Минтранса России, ГЦОД Головной центр обработки данных ФГБУ «СИЦ Минтранса России» Дашборд Интерактивная аналитическая панель, графический интерфейс. ЕИС Единая информационная система в сфере закупок ЕСИА Единая система идентификации и аутентификации Заказчик Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» КИИ Критическая информационная инфраструктура Кластер Кла?стер (англ. cluster) – объединение нескольких однородных элементов, которое может рассматриваться как самостоятельная единица, обладающая определёнными свойствами Компонент Часть АС, выделенная по определенному признаку или совокупности признаков и рассматриваемая как единое целое (ГОСТ Р 59853-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения») Контракт Контракт на выполнение работ по развитию и оказанию услуг по технической поддержке Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК в 2026 году, заключаемый по результатам проведения конкурентной процедуры закупки в соответствии с требованиями Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд»

1. ОБЩИЕ СВЕДЕНИЯ - 1.1. Наименование Системы Полное наименование системы: Информационно-аналитическая система регулирования на транспорте. Условное обозначение системы: АСУ ТК. Полное наименование модуля: Модуль сбора, ведения и анализа информации о нештатных ситуациях на транспорте. Условное обозначение модуля: Модуль СЦ. Модуль СЦ создан в рамках контракта от 05.08.2024 № ОК/24_04 на выполнение работ по развитию АСУ ТК в части создания модуля «Сбора, ведения и анализа информации о нештатных ситуациях на транспорте». Развитие Модуля СЦ осуществлено в рамках контракта от 19.05.2025 № ОК/25_09 на выполнение работ по развитию Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК - - Значение характеристики не может изменяться участником закупки

– ГОСТ Р 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.7. Сроки начала и окончания работ Начало работ: с даты заключения Контракта. Окончание работ: не позднее 15.12.2026. Работы выполняются в соответствии с этапами. Сроки выполнения этапов работ по развитию и технической поддержке Модуля СЦ определяются Календарным планом. Календарный план, приведен в разделе 5 настоящего ТЗ

1.2. Шифр темы или номер контракта Присваивается Заказчиком по результатам организации закупочных процедур. 1.2.1. Предмет контракта Выполнение работ по развитию Модуля СЦ. Код по ОКПД2: 62.01.11.000 – услуги по проектированию и разработке информационных технологий для прикладных задач и тестированию программного обеспечения. Оказание услуг по технической поддержке Модуля СЦ. Код по ОКПД2: 62.02.30.000 – услуги по технической поддержке информационных технологий. Выполнение работ по развитию Модуля СЦ предусмотрено с учетом ключевых результатов (ОКР) Ведомственной программы цифровой трансформации Минтранса России на 2026-2028 (далее - ВПЦТ Минтранса России) в составе мероприятия № 103.002 «АСУ ТК» ИТ расхода 103.26.000005 «Развитие Информационно-аналитической системы регулирования на транспорте (АСУ ТК)»: · «Обеспечено информационное взаимодействие с Минобороны о происшествиях на транспортных объектах»; · «Обеспечена автоматизация формирования отчетов о нештатных ситуациях на транспорте, в том числе по данным внешних систем». Выполнение работ по технической поддержке АСУ ТК предусмотрено ВПЦТ Минтранса России в составе мероприятия № 103.002 «АСУ ТК» ИТ расхода 103.26.000021 «Эксплуатация Информационно-аналитической системы регулирования на транспорте (АСУ ТК)»

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

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

1.5. Основания для выполнения работ Работы осуществляются на основании следующих документов: – постановление Правительства Российской Федерации от 30.12.2003 № 794 «О единой государственной системе предупреждения и ликвидации чрезвычайных ситуаций»; – постановление Правительства Российской Федерации от 08.11.2013 № 1007 «О силах и средствах единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций»; – распоряжение Правительства Российской Федерации от 27.11.2021 № 3363-р «О Транспортной стратегии Российской Федерации до 2030 года с прогнозом на период до 2035 года»; – Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 26.08.2025 №ЕФ-3; – Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 27.11.2025 №ЕФ-23;

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

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

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

– Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 19.02.2026 №ЕФ-1; – План мероприятий по профилактике случаев непроизводственного травматизма граждан на железнодорожном транспорте, являющийся приложением к постановлению коллегии Министерства транспорта Российской Федерации от 11.03.2026 № 2

1.6. Перечень документов, требования которых должны быть учтены при выполнении работ – Федеральный закон Российской Федерации от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации»; – Федеральный закон Российской Федерации от 27.07.2006 № 152-ФЗ «О персональных данных»; – Федеральный закон Российской Федерации от 06.04.2011 № 63-ФЗ «Об электронной подписи»; – Федеральный закон Российской Федерации от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации»; – Указ Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации»; – Указ Президента Российской Федерации от 01.05.2022 № 250 «О дополнительных мерах по обеспечению информационной безопасности Российской Федерации»; – Указ Президента Российской Федерации от 31.03.2010 № 403 «О создании комплексной системы обеспечения безопасности населения на транспорте»; – постановление Правительства Российской Федерации от 30.07.2004 № 395 «Об утверждении Положения о Министерстве транспорта Российской Федерации»; – постановление Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации»; – постановление Правительства Российской Федерации от 16.11.2015 № 1236 «Об установлении запрета на допуск программного обеспечения, происходящего из иностранных государств, для целей осуществления закупок для обеспечения государственных и муниципальных нужд»; – постановление Правительства Российской Федерации от 23.12.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 Федерального закона «Об электронной подписи»;

– постановление Правительства Российской Федерации от 08.06.2011 № 451 «Об инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг и исполнения государственных и муниципальных функций в электронной форме»; – постановление Правительства Российской Федерации от 30.01.2013 № 62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин»; – приказ ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации»; – приказ ФСТЭК России от 11.04.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений»; – приказ ФСБ России от 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 «Национальный стандарт Российской Федерации. Интеллектуальная собственность. Патентные исследования. Содержание и порядок проведения»;

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

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

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

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

3. ХАРАКТЕРИСТИКА ОБЪЕКТА АВТОМАТИЗАЦИИ - 3.3. Состав используемого ПО Модуля СЦ Программная архитектура Модуля СЦ разработана как трехуровневая клиент-серверная архитектура. Архитектура включает в себя следующие уровни: • уровень представления – презентационный уровень, обеспечивающий взаимодействие с пользователя с клиентскими приложениями с использованием веб-браузера («тонкий» клиент); • уровень приложений – реализован в виде сервисов, обеспечивает обработку запросов, поступающих от клиентских приложений, формирование ответов на запрос в доступном пользователю виде (формирование пользовательских интерфейсов); • уровень хранения данных – реализуется как сервер БД и обеспечивает хранение и целостность хранимых данных, создание резервных копий, ведение журнала транзакций, восстановление данных после сбоев. Программная архитектура Модуля СЦ включает в себя сервисы и интерфейсы, указанные в Таблице 3. Таблица 3. Программная архитектура Модуля СЦ Программный сервис/интерфейс Технологии реализации Уровень представления Интерфейс пользователя и администратора (front-end) Javascript Уровень приложений Сервис (GateWay) Kotlin Сервис геокодирования (geocoding-service) Kotlin Сервис уведомлений (notifiсation-service) Kotlin Сервис работы с файлами (file-service) Kotlin Сервис отчетности (report-service) Kotlin Сервис управления событиями (event-service) Kotlin Сервис информирования через мессенджер (messenger-notifier) Python Сервис внешних интеграций (integration-service) Сбор информации из внешних систем и сервисов Брокер сообщений Kafka Уровень хранения данных Файловое хранилище MinIO S3 СУБД Postgres Pro Enterprise - - Значение характеристики не может изменяться участником закупки

3.4. Информационное взаимодействие программных сервисов и интерфейсов Модуля СЦ Объект автоматизации функционирует в распределенной информационной среде. Обмен данными осуществляется по защищенным каналам связи (в том числе ведомственным сетям передачи данных). Источники информации включают: · внешние автоматизированные системы (органов государственной власти); · внутренние базы данных (реестры объектов транспортной инфраструктуры, паспорта регионов и пр.); · оперативная информация от персонала, поступающая через автоматизированные рабочие места (АРМ) и мобильные устройства. 3.4.1. Взаимодействие Модуля СЦ со смежными подсистемами АСУ ТК Модуль СЦ входит в состав АСУ ТК и взаимодействует со следующими ее функциональными задачами и подсистемами: · Функциональной задачей «Формирование и ведение единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации» (ФЗ «Реестр объектов»); · Геоинформационной подсистемой АСУ ТК (П-ГИС); · Подсистемой ведения нормативно-справочной информации и метаданных (П-НСИ); · Подсистемой сбора данных и централизованное хранилище данных (П-СД); · Подсистемой информационного взаимодействия (П-ИВ). 3.4.2. Взаимодействие с внешними информационными системами Список внешних информационных систем, с которыми осуществляется взаимодействие Модуля СЦ: · ЕСИА; · мессенджер; · Яндекс Геокодер; · Информационная система «Централизованная система сбора информации систем-112»; · ПВК «Поиск-Море», АИС РПТ; · облачная АТС

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

3.1. Описание объекта автоматизации АСУ ТК Объектом автоматизации являются процессы основной и обеспечивающей деятельности, направленные на управление транспортным комплексом, в том числе, процессы информационного взаимодействия с другими организациями и субъектами транспортного комплекса. АСУ ТК относится к государственным информационным системам, а также к информационным системам персональных данных и значимым объектам критической информационной инфраструктуры Российской Федерации. АСУ ТК соответствует требованиям, предъявляемым к: – ГИС второго класса защищенности в соответствии с приказом ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах»; – ИС персональных данных при обеспечении третьего уровня защищенности персональных данных в соответствии с требованиями постановления Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»; – значимым объектам КИИ Российской Федерации второй категории значимости с постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении Правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений». Модуль СЦ является подсистемой АСУ ТК. Перечень платформенных решений и функциональных задач АСУ ТК представлен в Таблице 1

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

8 Подсистема проектного архива АСУ ТК Подсистема проектного архива АСУ ТК предназначена для автоматизации деловых процессов должностных лиц Министерства транспорта Российской Федерации, подведомственных агентств и службы, в том числе, и процессов информационного взаимодействия внутреннего и внешнего характера 9 ФЗ «Реестр объектов» Функциональная задача предназначена для формирования и ведения единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации 10 ФЗ «СТП» Функциональная задача предназначена для организации информационно-аналитической поддержки процессов территориального планирования Российской Федерации в области федерального транспорта 11 ФЗ «МРТБ ПП» Функциональная задача предназначена для формирования и ведения межрегионального транспортного баланса пассажирских перевозок в дальнем (межрегиональном) сообщении 12 ФЗ «МДД» Функциональная задача предназначена для осуществления мониторинга дорожного движения 13 ФЗ «ТПР» Функциональная задача предназначена для формирования и ведения транспортного паспорта региона 14 ФЗ «Данные по грузообороту» Функциональная задача предназначена для обеспечения подсистем и пользователей АСУ ТК данными по грузообороту между Российской Федерацией и зарубежными странами 15 ФЗ «МЖТ» Функциональная задача предназначена для осуществления мониторинга железнодорожного транспорта 16 ФЗ «МГМП» Функциональная задача предназначена для осуществления мониторинга грузопотоков в морских портах с целью формирования единой цифровой среды мониторинга и планирования перевозок в/из портов Дальнего Востока

17 Модуль ГЭТ Модуль предназначен для получения, хранения данных инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по отдельно взятому предприятию-перевозчику. Формирования отчетов об инвентаризации с детальными данными по каждому разделу инвентаризации с маршрутизацией в муниципалитет / регион / Минтранс. Содержит агрегированные данные инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по всем перевозчикам, относящихся к данному муниципалитету. Формирует сводный отчет по муниципалитету по каждому разделу инвентаризации с маршрутизацией в регион / Минтранс. Формирует агрегированные данные инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по всем перевозчикам, относящиеся к данному региону и по всем муниципалитетам, относящимся к данному региону. Аналитические и статистические данные о состоянии ГЭТ региона. Содержит данные о видах транспорта, цифровых транспортных сервисах и платежных инструментах Региона. Формирует сводный отчет по каждому разделу инвентаризации с маршрутизацией в Минтранс. Формирует агрегированную статистику и аналитику по всем регионам страны в разрезе транспортных средств, маршрутов, пассажиропотоков, инфраструктуры ГЭТ. Данные о рейтинге регионов и перевозчиков на основании выбранных параметров, документооборот с участниками Системы: получение подписанных печатных форм, их утверждение, возврат на доработку. 18 Модуль iМинтранс Модуль создан для отчета по ключевым показателям транспортного комплекса России (Отраслевые и статистические показатели, исполнение бюджета, исполнение поручений, аналитика СМИ, происшествия по видам транспорта). 19 Модуль СЦ Модуль СЦ предназначен для оперативного мониторинга нештатных ситуаций транспортной отрасли, оповещения заинтересованных лиц и структур и предоставления данных о нештатных ситуациях

АСУ ТК осуществляет идентификацию и авторизацию посредством Единой системы идентификации и аутентификации (ЕСИА). Информационный обмен с внешними информационными системами осуществляется посредством СМЭВ 3 и СМЭВ 4. АСУ ТК развернута на вычислительных мощностях ГЦОД СИЦ Минтранса России

3.2. Описание и текущее состояние объекта автоматизации Модуля СЦ Объектом автоматизации является процесс организации мониторинга информации о НС и ЧС на транспорте. Предметом деятельности Учреждения являются следующие функции: – информационное обеспечение в области транспортной безопасности, защиты населения и территорий от чрезвычайных ситуаций природного и техногенного характера в транспортном комплексе; – подготовка справочных материалов при угрозе возникновения и возникновении чрезвычайных ситуаций и иных происшествий в транспортном комплексе; – взаимодействие и обмен оперативной информацией с органами управления Единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций; – организация оперативного мониторинга обстановки на объектах транспорта при угрозе и возникновении чрезвычайных ситуаций и иных происшествий. Перечень компонентов Модуля СЦ и выполняемые ими функции представлены в Таблице 2

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

3 Информирование – ведение справочника способов оповещения (веб-интерфейс, мессенджер); – формирование сценария выполнения оповещения (настройка условий, способа, параметров оповещения); – выполнение оповещений пользователей 4 Отчетность – формирование отчета и справки о событиях; – фильтрация событий для выгрузки в справку о событиях или в отчет о событиях 5 Администрирование – ведение ролей пользователей; – ведение учетных данных пользователей; – ведение справочника организаций; – ведение справочника групп системы мгновенного обмена сообщениями; – выполнение исходящего звонка на контактный телефонный номер организации; – формирование матрицы эскалации событий Архитектура Модуля СЦ представлена на рисунке 1. Рисунок 1. Архитектура Модуля СЦ

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

4.3. Требования к оказанию услуг по технической поддержке Модуля СЦ 4.3.1. Общие требования к оказанию Услуг Техническая поддержка Модуля СЦ должна осуществляться с учетом требований постановления Правительства Российской Федерации от 06.07.2015 N 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации». Подрядчик обязан выполнять требования законодательства в сфере защиты информации, требования по защите информации, информационной безопасности, указанные в локальных нормативных актах ФГБУ «СИЦ Минтранса России», регламентирующих условия информационного взаимодействия, защиты информации и подключения к информационным ресурсам ФГБУ «СИЦ Минтранса России», участвующих в информационном взаимодействии в рамках оказания услуг по технической поддержке АСУ ТК в 2026 году

4.3.1.1. Требования к составу и содержанию услуг третьего уровня технической поддержки Оказание услуг по технической поддержке Системы осуществляется в рамках этапов в соответствии с календарным планом. Подрядчик в течение 5 рабочих дней с даты заключения Контракта должен предоставить со своей стороны, а Заказчик со своей стороны Матрицу ответственных за взаимодействия в соответствии с Приложением 1 к Регламенту оказания услуг по третьему уровню технической поддержки Модуля СЦ (далее – Регламент, Приложение В). Подрядчик в течение 10 рабочих дней с даты заключения Контракта должен провести мероприятия по организации третьего уровня технической поддержки в соответствии с Регламентом. Услуги по третьему уровню технической поддержки Модуля СЦ должны включать: – организацию Подрядчиком третьего уровня технической поддержки; – информационно-консультационную поддержку работников Заказчика; – решение инцидентов, связанных с работой ППО; – адаптационное, конфигурационное и коррекционное сопровождение Модуля СЦ (в рамках действующих программных модулей и функциональности); – устранение уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности

Таблица 6. Категории обращений и заявок Категория Примеры Запрос на обслуживание Подготовка SQL запроса к СУБД для решения прикладной задачи и д.р. – запрос на любое действие, не являющееся запросом информации и несовершенный на основе происшествия, прямо или косвенно влияющего на работу Модуля СЦ Консультация «Где взять / куда обратиться...?», «Как сделать / выполнить…», «Как это работает…?» - запрос, имеющий своей целью получение информационной поддержки Инцидент Разбор ошибок/сбоев и подготовка материалов (корректировочных релизов, инструкций) для Заказчика для устранения ошибок/сбоев, которые приводят к частичному и полному нарушению работоспособности всех или отдельных функций ППО. Подготовка изменения и материалов, необходимых для проведения аварийно-восстановительных работ для возобновления работоспособности Модуля СЦ ЗНИ Подготовка изменений, связанных с изменением, улучшением/оптимизацией Модуля СЦ и выводом новой модифицированной функциональности в штатном режиме. Подготовка изменений, связанных с модификацией существующих и/или реализация новых интеграционных механизмов для получения/обработки данных внешних систем. Подготовка изменений графического интерфейса по требованиям Заказчика. Перечень статусов обращений (заявок) приведен в пункте 3.3. Регламента оказания Услуг. Назначение обращению (заявке) статуса «Закрыто» осуществляется Заказчиком только после получения от инициатора обращения (заявки) подтверждения о его исполнении или нахождения обращения (заявки) в статусе «Выполнено» и отсутствия повторных вопросов/запросов по данному обращению (заявки) в течение 5 рабочих дней. Категории и статусы обращений (заявок) могут быть скорректированы в процессе оказания услуг исключительно по согласованию с Заказчиком

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

4.1. Требования к структуре Модуля СЦ В процессе работ по развитию Системы должны сохраниться основные требования к построению архитектуры Системы в соответствии с принципами трехуровневой архитектуры: 1. уровень хранения данных или уровень базы данных (сервер СУБД); 2. уровень сервера приложений (сервер аналитической обработки); 3. презентационный уровень, обеспечивающий взаимодействие с клиентскими приложениями. В состав Системы должны входить следующие основные компоненты: 4. сервер баз данных; 5. сервер приложений; 6. веб-сервер. Сервер баз данных должен обеспечивать хранение и целостность хранимых данных, создание резервных копий, ведение журнала транзакций, восстановление данных после сбоев. Сервер приложений должен обеспечивать обработку запросов, поступающих от клиентских приложений (через веб-сервер), формирование ответов на запрос в доступном пользователю виде (формирование пользовательских интерфейсов). Веб-сервер должен обеспечивать взаимодействие с оператором и внешними системами по HTTP / HTTPS протоколу в режиме «запрос-ответ» (получения запросов от пользователя и передачи ответа в виде соответствующей информации, обработанной серверами приложений). Взаимодействие Системы с пользователем должно отвечать требованиям модели «тонкого клиента» (т.е. представлять на стороне клиента (пользователя) лишь графический пользовательский интерфейс). Все составляющие Системы должны использовать единую методологию и отвечать единым принципам взаимодействия, надежности и управления. Перечень компонентов Модуля СЦ представлен в Таблице 4. Таблица 4. Перечень компонентов Модуля СЦ, в отношении которых выполняются работы по развитию № п.п. Наименование компонента Модуля СЦ Раздел ТЗ 1 Компонент регистрации событий 4.2.1. 2 Компонент отчетности 4.2.2 3 Компонент визуализации 4.2.3 4 «Интерактивная карта» (компонент создается) 4.2.4 5 Компонент администрирования 4.2.5

4.2. Требования к дорабатываемым функциям модуля СЦ 4.2.1. Развитие компонента регистрации событий (1 очередь) Должны быть выполнены следующие доработки: – обеспечение логирования действий пользователя, связанных с карточкой события; – доработка объектной модели в части создания новых типов сущностей (карточек) с учетом реализуемых интеграций с информационными ресурсами (силы и средства предупреждения и ликвидации ЧС и нештатных ситуаций на транспорте, ТС, ограничения воздушного пространства, неблагоприятные и опасные природные явления); – реализация механизма установления связи между сущностями в Модуле СЦ автоматизированным и ручным способами (события, природные явления, силы и средства предупреждения и ликвидации ЧС и нештатных ситуаций на транспорте, ограничения воздушного пространства, ОТИ, ТС и др.); – отображение в карточке установленных связей между сущностями.

4.3.1.2. Требования к общему порядку оказания услуг Техническая поддержка Модуля СЦ должна быть организована на трех уровнях: – первый и второй уровни технической поддержки организуется Заказчиком; – третий уровень технической поддержки организуется Подрядчиком. Перечень действий на каждом уровне технической поддержки указан в Таблице 5: Таблица 5 – Перечень действий на каждом уровне технической поддержки Уровень технической поддержки Доступные действия Условия передачи задачи на следующий уровень Первый уровень технической поддержки (далее – 1-й уровень) – принимает обращения (заявки) пользователей Модуля СЦ и работников Заказчика; – регистрирует обращения в Модуле СЦ регистрации обращений; – присваивает уникальный идентификационный номер, классифицирует обращения; – самостоятельно решает обращения, которые связаны с недостаточной квалификацией пользователей или настройками в рамках своей компетенции; – взаимодействует с пользователями Модуля СЦ при решении проблемы Передает обращение на второй уровень поддержки в случае невозможности решения на своем уровне Второй уровень технической поддержки (далее – 2-й уровень) – принимает обращения от 1-го уровня; – уточняет классификацию обращения в результате дополнительного анализа; – самостоятельно решает обращения в рамках своей компетенции; – осуществляет техническую и консультационную поддержку Модуля СЦ; – взаимодействует с сотрудниками 1-го и 3-го уровня и пользователями Модуля СЦ; – формирует заявки для 3-го уровня и контролирует исполнение Передает обращение на третий уровень поддержки в случае невозможности решения на своем уровне Третий уровень технической поддержки (далее – 3-й уровень) – принимает обращения от 2-го уровня; – обеспечивает выполнение требований, предъявляемых Контрактом и настоящим Техническим заданием к Услугам, оказываемым Подрядчиком Все поступающие обращения должны быть исполнены Подрядчиком

Для обеспечения взаимодействия с Заказчиком Подрядчик со своей стороны определяет ответственных лиц, уполномоченных в структуре Подрядчика за своевременное и качественное оказание Услуг в рамках настоящего ТЗ, а также контактную информацию ответственных лиц (телефон, электронную почту). Подрядчик должен предоставить Заказчику единый адрес электронной почты для приема обращений (заявок) в течение 3 (трех) рабочих дней после заключения Контракта. Указанный в настоящем пункте адрес электронной почты (способ направления обращений (заявок) применяется в случае сбоя в работе СРО Заказчика. Со своей стороны, Заказчик предоставляет Подрядчику перечень и контактную информацию (телефон, электронную почту) уполномоченных лиц для осуществления взаимодействия с указанием зон ответственности. О любых изменениях в контактной информации ответственных лиц Стороны должны уведомить друг друга в течение 1 (одного) рабочего дня с момента возникновения таких изменений посредством уведомления на электронную почту ответственных лиц и/или в письменной форме. В результате оказания услуг по настоящему ТЗ не должны быть изменены исходные коды, дистрибутивы и иные компоненты Модуля СЦ вне согласованных с Заказчиком изменений. Любые изменения исходных кодов, дистрибутивов и иных компонентов Модуля СЦ должны производиться только после согласования с Заказчиком уполномоченными лицами по электронной почте или иным заранее согласованным способом. Не должна быть ухудшена надежность и производительность Модуля СЦ. Оказание услуг по Контракту не должно нарушать требования к информационной безопасности, описанной в документации на Модуль СЦ

4.3.6.2. Требования к услугам информационно-консультационной поддержки работников Заказчика и пользователей Модуля СЦ Услуги информационно-консультационной поддержки сотрудников Заказчика включают: – обработку обращений и заявок, поступивших от сотрудников Заказчика; – консультирование сотрудников Заказчика и пользователей Модуля СЦ; – актуализацию документации, и других материалов по работе с Модулем СЦ при необходимости. – консультирование и разработку рекомендаций по настройке Модуля СЦ (без изменения программного кода), включая изменение настроек функционирования; – консультации по вопросам использования, настройки и возможностям Модуля СЦ; – консультации по проведению превентивных мер для недопущения аварийных ситуаций в Модуле СЦ; – консультации по предварительной диагностике и локализации возникшей неисправности Модуля СЦ; – консультации по вопросам обеспечения информационной безопасности Модуля СЦ и настройки функций, обеспечивающих корректную работу программного обеспечения для совершения юридически значимых действий в Модуле СЦ; – другие вопросы, связанные с работой Модуля СЦ. 4.3.6.2.1. Требования к порядку оказания услуг информационно-консультационной поддержки работников Заказчика и пользователей Модуля СЦ Подрядчик выполняет консультирование сотрудников Заказчика и пользователей Модуля СЦ. Консультация может быть предоставлена по согласованным с представителем Заказчика каналам коммуникации с регистрацией результата консультации в СРО Подрядчиком. Детальный порядок оказания консультационных услуг определен в Регламенте оказания Услуг

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

4.3.6.4.2. Требования к изменению настроек функционирования Изменение настроек функционирования может проводиться в рамках допустимых пределов изменения функционирования, заложенных в архитектуру Модуля СЦ. Изменение настроек функционирования включает в себя изменение данных и справочников, изменение форм документов, формируемых Модулем СЦ, изменение и настройку форматов и версий передачи данных в смежные системы. Доработка программного кода Модуля СЦ может допускаться (в случае необходимости) при выполнении работ по адаптации функций Модуля СЦ в части изменения формата передачи данных в смежные информационные системы при условии соблюдения требований пункта 29.3 приказа ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации»

4.3.6.5. Требования к услугам по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности По запросу Заказчика Подрядчик должен провести работу по приведению ППО в соответствие с требованиями по обеспечению информационной безопасности. Критичность уязвимости оценивается в соответствии в соответствии с Методическим документом ФСТЭК России «Методика оценки уровня критичности уязвимостей программных, программно-аппаратных средств» (утвержден ФСТЭК России 30.06.2025), а также с учетом ГОСТ 56545-2015 и международными стандартами (CVSS 3.0 и выше), и задает необходимый срок устранения. В процессе проведения Заказчиком обследования Модуля СЦ и выявления уязвимостей в ППО, связанных с исходным кодом Модуля СЦ и/или используемыми компонентами (библиотеками), Заказчик направляет Подрядчику обращение (заявку) на устранение, с указанием критичности и срочности принятия мер по устранению в СРО.

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

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

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

4.5.3. Требования по диагностированию Модуля СЦ Диагностирование Модуля СЦ должно осуществляться путем анализа записей в системных журналах СУБД, операционных систем серверов, а также с помощью встроенных средств диагностирования общего программного обеспечения Модуля СЦ. Диагностированию подлежат: – сбои и нарушения функционирования технического обеспечения (серверов) Модуля СЦ; – сбои и нарушения функционирования системного программного обеспечения серверов, используемых для работы Модуля СЦ; – сбои и нарушения функционирования прикладного программного обеспечения серверов, используемых для работы Модуля СЦ; – случаи недоступности (отсутствия ответа) или некорректные ответы внешних систем; – сбои и нарушения функционирования СУБД; – сбои при выполнении регламентных операций резервного копирования. При возникновении аварийных ситуаций либо ошибок в программном обеспечении диагностические инструменты должны позволять сохранять набор информации, необходимой для идентификации и устранения проблемы. Модуль СЦ и ее компоненты должны обеспечивать возможность диагностики своей работоспособности с возможностью интеграции с модулем мониторинга АСУ ТК. Набор передаваемых журналов и метрик должен быть определен на этапе технического проектирования

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

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

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

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

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

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

4.4. Требования к видам обеспечения 4.4.1. Требования к лингвистическому обеспечению Документация на Модуль СЦ должна разрабатываться на русском языке. Взаимодействие пользователей с Модулем СЦ посредством графического интерфейса должно происходить на русском языке за исключением сообщений, зависящих от настроек системного программного обеспечения, установленного на рабочих местах пользователей. При разработке программных решений Модуля СЦ должно быть предусмотрено использование языков программирования высокого уровня, приведенных в Таблице 7. Таблица 7. Языки и средства разработки, специального программного обеспечения Модуля СЦ Категория Наименование Назначение Языки программирования Kotlin Разработка серверной логики и сервисов (backend) JavaScript / TypeScript Разработка клиентской части (frontend) Python Разработка скриптов интеграции, обработки данных и автоматизации Фреймворки и библиотеки Vue.JS Разработка пользовательских интерфейсов (веб-интерфейсы компонентов визуализации и отчетности) React Разработка пользовательских интерфейсов (при необходимости создания сложных интерактивных компонентов) Решения по лингвистическому обеспечению, включая перечень используемых языков программирования, должны быть согласованы с Заказчиком на этапе технического проектирования

4.4.2. Требования к математическому обеспечению Требования к математическому обеспечению не предъявляются. 4.4.3. Требования к метрологическому обеспечению Требования к метрологическому обеспечению не предъявляются. 4.4.4. Требования к организационному обеспечению Требования к организационному обеспечению не предъявляются. 4.4.5. Требования к методическому обеспечению Задачи методического обеспечения Модуля СЦ должны быть обеспечены за счет использования технологических и методических документов касающихся вопросов функционирования транспортного комплекса и разработки и эксплуатации ПО. 4.4.6. Требования к информационному обеспечению Состав, структура и способы организации информационного обеспечения в Модуле СЦ должны быть определены на этапе технического проектирования. Факты информационного обмена с внешними системами должны фиксироваться в соответствующем журнале

4.5.5. Требования к информационной безопасности Работы по защите информации/информационной безопасности, не включенные в состав настоящего раздела, требуемые в соответствии с требованиями постановления Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации», а также нормативно правовых актов в области защиты персональных данных и обеспечения безопасности объектов критической информационной инфраструктуры, будут проведены в рамках исполнения отдельного контракта, заключенного по результатам отдельной закупочной процедуры (не является частью данного ТЗ), включающего: – определение актуальных угроз безопасности информации и актуализация модели угроз безопасности информации (при необходимости); – выполнение требований о согласовании технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России в установленном порядке; – выполнение требований по устранению Подрядчиком замечаний и недостатков, в случае их выявления при согласовании Заказчиком технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России; – выполнение требований к классу защищенности ГИС, уровню защищенности персональных данных и категории значимости объекта КИИ РФ, установленных для Головного центра обработки данных ФГБУ «СИЦ Минтранса России» (далее – ГЦОД);

– определение перечня объектов защиты информационной системы; – описание (актуализированных) требований к системе защиты информации, а также к мерам защиты информации информационной системы в зависимости от установленных классов защищенности, уровня защищенности персональных данных и категории значимости объектов КИИ РФ (приказы ФСТЭК России № 21, 117, 239); – выполнение требований к мерам по защите ГИС от атак, направленных на отказ в обслуживании, в соответствии с пунктами 30, 34, 59, 63 Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений, утвержденных приказом ФСТЭК России от 11.04.2025 № 117; – описание (актуализированных) требований по защите информации, подлежащих реализации в информационно телекоммуникационной инфраструктуре ГЦОД; – выполнение требований о применении сертифицированных средств защиты информации, включая их классы защиты и уровни доверия; – выполнение требований о запрете использования с 01.01.2025 органами (организациями) средств защиты информации странами происхождения, которых являются иностранные государства в соответствии с пунктом 6 Указа Президента Российской Федерации от 01.05.2022 № 250; – выполнение требований по обеспечению непрерывного взаимодействия с ГосСОПКА в установленном порядке;

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

4.5.8. Требования к защите от влияния внешних воздействий Требования к защите от влияния внешних воздействий не предъявляются

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

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

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

4.4.7.1. Требования к инструментам разработки и процессу контроля версий программного обеспечения 4.4.7.1.1. Система контроля версий Для управления исходным кодом должна использоваться система контроля версий кода, развернутая в инфраструктуре Заказчика. 4.4.7.1.2. Правила именования веток Имя ветки должно соответствовать следующему формату: / / Категории веток: ? feature/ — разработка новой функциональности, а также рефакторинг или удаление существующей; ? fix/ — исправление ошибок; ? hotfix/ — срочные исправления, применяемые в обход стандартного процесса разработки; ? test/ — для проведения экспериментов, не влияющих на основную разработку. Идентификатор задачи: после категории указывается ссылка на задачу (issue) в системе контроля версий кода. Описание: добавляется краткое описание решаемой задачи в формате kebab-case (слова разделяются дефисами, например, add-user-auth). Примеры именования веток: ? feature/#123/add-payment-integration; ? fix/#45/correct-calculation-logic; ? hotfix/#67/urgent-database-connection-patch. 4.4.7.1.3. Правила именования коммитов Сообщение коммита должно соответствовать соглашению Conventional Commits и состоять из категории и описания: : ? fix — исправление ошибки. Примеры сообщений коммитов: ? feat: добавление формы регистрации пользователя; ? fix: исправление ошибки валидации email-адреса; ? refactor: оптимизация алгоритма сортировки данных; ? chore: обновление версий в файле dependencies. 4.4.7.1.4. Модель ветвления В процессе разработки используются следующие основные ветви: ? main / master — стабильная ветка, содержит только код, прошедший полное тестирование и развернутый в продуктивных контурах; ? dev — ветка для интеграции завершенных задач, предназначенная для сборки и тестирования в тестовых средах. Попадание кода в main осуществляется только через Merge Request (MR) из dev

– выполнение требований по обеспечению в автоматизированном режиме с Национальной системой противодействия DDoS-атакам (НСПА) Центра мониторинга и управления сетью связи общего пользования ФГУП «ГРЧЦ» в рамках реализации мер по защите ГИС от атак, направленных на отказ в обслуживании; – детализированные требования к составу и содержанию работ по аттестации, а также к их результатам в соответствии с пунктами 13, 15 и 16 требований приказа ФСТЭК России от 29.04.2021 № 77 «Об утверждении Порядка организации и проведения работ по аттестации объектов информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну»

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

Подрядчик должен обеспечить реализацию и проведение внутренних проверок мер по разработке безопасного ПО, приведенных в Руководстве. Подрядчик должен провести анализ угроз безопасности информации программного обеспечения в соответствии с ГОСТ 58412-2019 «Защита информации. Разработка безопасного программного обеспечения. Угрозы безопасности информации при разработке программного обеспечения». Подрядчик должен провести испытания по выявлению уязвимостей в программном обеспечении Системы: · проведение статического анализа исходного кода программы; · проведение динамического анализа исходного кода программы; · проведение композитного анализа исходного кода и образов программы; · проведение фаззинг-тестирования программы, направленного на выявление в ней уязвимостей. Испытания по выявлению уязвимостей в программном обеспечении Системы должны быть проведены в рамках: · предварительных испытаний; · опытной эксплуатации; · приемочных испытаний

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

Лицензионное (сублицензионное) соглашение (договор) не может возлагать на Заказчика какие-либо обязанности (в т.ч. в части конфиденциальности, предоставления отчетности), не предусмотренные Контрактом. 4.5.9.7. Передача Заказчику исключительных прав, или простых (неисключительных) прав не может повлечь увеличение стоимости Контракта и/или изменение иных существенных условий Контракта. 4.5.9.8. Функциональность Модуля СЦ передается в объеме и в сроки, установленные Техническим заданием. 4.5.9.9. Нарушение условий настоящего раздела Технического задания, в т.ч. отсутствие соответствующего лицензионного (сублицензионного) соглашения (или договора), либо предоставление лицензионного (сублицензионного) соглашения (или договора), не соответствующего требованиям действующего законодательства Российской Федерации или требованиям Контракта, является нарушением существенных условий Контракта. 4.5.9.10. В случае, если в соответствии с пунктом 4.5.9.6 Заказчику передается исключительное право, такая передача осуществляется в порядке, установленном Гражданским кодексом Российской Федерации. 4.5.9.11. В случае, если при выполнении Работ положения пунктов 4.5.9.5-4.5.9.6 не применялись, Подрядчик в составе отчетной документации предоставляет об этом декларацию в свободной форме. Декларация должна содержать сведения о полном соответствии результата Работ требованиям Контракта, а также о неприменении при выполнении работ готового программного обеспечения (платформ, подсистем, СУБД и т.д.), которое стало частью (компонентом) Системы

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

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

4.2.2. Развитие компонента отчетности (3 очередь) Должна быть обеспечена автоматизация процессов формирования отчетов о ЧС и нештатных ситуациях на транспорте, в т.ч. на основе данных из внешних систем. Включает следующие доработки: – разработка шаблонов отчетов в различных форматах (табличный, текстовый); – реализация выбора фотоматериалов для включения в справку; – форматирование содержимого справок с учетом правил русского языка в отношении окончаний слов (в зависимости от падежа, склонения, числа и рода); – автоматизированное формирование выводов к содержимому справки на основе настраиваемых критериев; – создание интерфейса выбора параметров (фильтрации) для формирования отчетов: o состав полей для включения в отчёт; o настройка диапазонов значений характеристик и дат; o порядок отображения полей; o настройка заголовка. – реализация способа подготовки отчётов в асинхронном режиме (очереди); – реализация интерфейса компонента формирования отчетности для отображения очереди формирования отчетов и статусов их подготовки; – экспорт отчётов в форматы xlsx, csv и справок в форматы pdf, docx. Необходимо разработать не менее 10 шаблонов отчетов и/или справок. Перечень, структура и содержание шаблонов должны быть согласованы с Заказчиком на этапе технического проектирования.

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

– отображение на карте связанных сущностей и ОТИ; – реализация функции выбора темного и светлого стилей отображения элементов интерфейса, карточек сущностей, картографической основы и объектов, отображаемых на карте; – реализация механизма для выбора картографической основы в одном из распространенных форматов WMTS, TMS, MVT и др. Должна быть предусмотрена возможность настройки перечня картографических основ и параметров доступа к ним; – настройка базового набора дашбордов, содержащих преднастроенные виджеты о количестве событий в разрезе видов транспорта с возможностью перехода к исходным данным (карточкам событий, ОТИ и т.д.), с фильтрацией по параметрам. Параметры фильтрации должны быть определены на этапе технического проектирования. Должно быть обеспечено автоматическое и принудительное обновление данных, отображаемых на дашбордах

4.2.4. Создание компонента «Интерактивная карта» (2 очередь) В составе создаваемого компонента должны отображаться данные, доступные в компоненте визуализации. Требования к интерфейсу интерактивной карты: – интерактивная карта должна быть представлена в виде объемной карты с учетом макетов, представленных в Приложении А к ТЗ; – интерфейс должен корректно отображаться на экранах мониторов (разрешение Full HD 1920?1080), телевизоров (разрешение 4К 3840?2160), жидкокристаллических панелей для видеостены, используемой Заказчиком, с параметрами каждой панели: диагональ 55 дюймов, разрешение 1920x1080; – интерфейс должен корректно отображаться на планшетных устройствах с диагональю экрана 10-12 дюймов, конкретные требования должны быть уточнены на этапе технического проектирования; – должна быть обеспечена кластеризация и генерализация отображения объектов на карте при изменении масштаба; – должно быть обеспечено отображение основных характеристик объектов при выборе их на карте; – должно быть обеспечено управление отображением слоев на карте; – должна быть обеспечена настройка цветовой индикации отображаемых объектов транспортной инфраструктуры; – должно быть обеспечено отображение легенды карты, содержащей отображаемые объекты на карте; – должна быть обеспечена возможность одновременного отображения не менее 5 000 ОТИ и ТС на карте.

На интерактивной карте должны быть отображены подвижные объекты совместно с объектами транспортной инфраструктуры (ОТИ), включая следующие возможности: § отображение местоположения транспортных средств (воздушный, водный и автомобильный транспорт) на карте в режиме реального времени (с заданным периодом обновления данных); § отображение маршрутов движения всех ТС за выбранный период времени, в том числе с использованием эффектов анимации; § отображение маршрутов движения ТС, связанных с карточкой события: ТС, являющихся участниками события, и ТС, находящиеся в заданном радиусе от события; § управление отображением сущностей и ОТИ на карте, включая настройку состава отображаемых объектов, поиск, фильтрацию, с использованием соответствующей панели управления и наглядным представлением результатов; § автоматическое изменение вида отображения объектов (цветовая индикация) по заданным условиям (например, при достижении критических значений параметров, характеризующих функционирование объекта); Должна обеспечиваться производительность обновления изображения на экране в 30 кадров в секунду на тестовой конфигурации пользовательского устройства (модель Бештау AIO2402/B560, входящая в Реестр российской промышленной продукции под номером 10394100 или аналог) при одновременном отображении не менее 5 000 объектов и 200 уникальных моделей объектов. Макеты интерфейсов Модуля СЦ должны быть предварительно согласованы с Заказчиком и разработаны с учетом требований ГОСТ Р ИСО 9241-161-2016 «Элементы графического пользовательского интерфейса»

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

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

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

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

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

4.3.6.4. Требования к услугам адаптационного, конфигурационного и коррекционного сопровождения и доработки Модуля СЦ (в рамках действующих программных модулей и функциональностей) Услуги адаптационного, конфигурационного и коррекционного сопровождения и доработки Модуля СЦ включают: – управление изменениями и адаптация функций Модуля СЦ; – изменение настроек функционирования Модуля СЦ; – внесение изменений и/или модификаций Модуля СЦ (в рамках действующих программных модулей и функциональностей), направленных на улучшение их работоспособности и функциональных возможностей; – подготовка и передача Заказчику SQL запросов в СУБД для получения агрегированной информации из Модуля СЦ, которую невозможно получить с использованием графического пользовательского интерфейса; – адаптация модулей интеграций со смежными информационными системами

4.4.7.1.5. Требования к используемым зависимостям (библиотекам) Все внешние зависимости проекта должны быть зафиксированы с указанием точных версий. Для контроля версий зависимостей в репозиторий обязательно должны быть включены следующие файлы: · Для JavaScript: package-lock.json или yarn.lock; · Для Python: requirements.txt (с зафиксированными версиями) или Pipfile.lock; · Для Go: go.mod и go.sum; Загрузка всех зависимостей должна производиться исключительно через внутренний прокси-репозиторий Заказчика, настроенный в соответствующем системе менеджере пакетов. Запрещается: · Использование плавающих версий (например, ^1.2.3, ~4.5.0, latest); · Использование библиотек, содержащих критические уязвимости, в том числе зарегистрированные в реестре CVE (Common Vulnerabilities and Exposures). 4.4.7.1.6. Требования к процессу непрерывной интеграции (CI) Сборка программного обеспечения, включая этапы компиляции, тестирования и анализа кода, должна выполняться исключительно в инфраструктуре непрерывной интеграции Заказчика. 4.4.7.1.7. Требования к хранению артефактов сборки Все артефакты сборки (результирующие пакеты, Docker-образы и т.д.) подлежат обязательному хранению в предназначенной для этого инфраструктуре Заказчика (артефакторий). Запрещается размещение финальных артефактов сборки на сторонних ресурсах

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

4.5. Общие технические требования 4.5.1. Требования к численности и квалификации персонала и пользователей Модуля СЦ Программное обеспечение Модуля СЦ не должно требовать изменения штатной численности персонала Заказчика. Программное обеспечение Модуля СЦ не должно требовать наличия у пользователей дополнительной квалификации в сфере информационных технологий, кроме базовых знаний в обращении с персональным компьютером, базовых навыков работы в интернет-обозревателях и знаний о Модуле СЦ в объеме документов Руководство пользователя, Руководство администратора

4.2.4.1. Требования к технической реализации компонента «Интерактивная карта» При реализации компонента «Интерактивная карта» должны учитываться требования, указанные ниже. 4.2.4.1.1. Требования к отображению элементов Повторяющихся элементы карты (ТС, ОТИ, события и пр.) должны отрисовываться с использованием аппаратного создания экземпляров объектов на пользовательском устройстве (WebGL/WebGPU)). Отрисовка каждого объекта отдельным запросом не допускается, должна обеспечиваться возможность одновременного отображения не менее 5 000 объектов без снижения производительности (30 кадров в секунду на тестовой конфигурации). 4.2.4.1.2. Уровни детализации объектов Для управления отображением сложных объектов должно быть создано не менее 3-х уровней детализации, отображаемых при изменении масштаба с возможностью автоматического переключения между уровнями. Все отображаемые объекты должны масштабироваться с учетом разрешения экрана пользователя с сохранением качества детализации. 4.2.4.1.3. Полигональная оптимизация и текстурирование При реализации компонента «Интерактивная карта» должна обеспечиваться технология рельефного тестурирования объектов. Не должны использоваться высокополигональные трехмерные модели. Все повторяющиеся элементы должны генерироваться единоразово и повторно использоваться при последующих отображениях. 4.2.4.1.4. Управление памятью Требуется реализовать потоковую загрузку на устройство пользователя элементов карты и текстур. Загрузка данных целиком при старте приложения не допускается. Необходимо реализовать механизм очистки памяти от элементов, которые находятся вне области видимости камеры в течение заданного времени. 4.2.4.1.5. Требования к взаимодействию пользователя с интерфейсом компонента «Интерактивная карта» Программная реализация механизмов управление камерой (масштабирование и навигация) должна быть выполнена с поддержкой технологии WebAssembly (WASM). Элементы управления должны являться неотъемлемой частью интерактивной карты.

4.2.5. Развитие компонента администрирования (3 очередь) Должна быть выполнена доработка ролевой модели. Ролевая модель должна обеспечивать управление доступом к отдельным объектам Модуля СЦ и их элементам (атрибутам) с разграничением по видам транспорта, регионам и пр., в частности: – определение набора конкретных действий, доступных пользователям (выполняемых над объектом доступа, например, удаление записи, редактирование записи, формирование отчета и др.); – реализация возможности объединения пользователей в группы; – определение прав доступа для групп пользователей; – реализация интерфейса визуальной настройки прав доступа пользователей к объектам Модуля СЦ

4.3.4. Требования к документированию результатов оказываемых услуг Для обеспечения контроля оказываемых услуг по поддержке Модуля СЦ со стороны Заказчика, по окончании каждого отчетного периода по контракту в соответствии с календарным планом, Подрядчик обязан предоставить Заказчику Отчет об оказанных услугах. Отчет должен содержать детальную информацию об оказанных услугах с указанием даты выполненных мероприятий и приложением обосновывающих документов (заявок, запросов, требований) или ссылкой на такие документы, если они содержатся в Модуле СЦ. Информация о выполненных мероприятиях по заявкам должна быть сформирована на основании соответствующих записей СРО по каждому этапу исполнения Контракта. В случае оказания услуги адаптационного, конфигурационного и коррекционного сопровождения Модуля СЦ, должны быть предоставлены документы, подтверждающие выполнение требований п. 29.3 приказа ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации». Фактическое время реагирования и время решения по всем обращениям, поступившим в СРО, формируется в СРО по итогам отчетного периода в разделе «Отчеты». Фактическое время реагирования и время решения по обращениям учитывает суммарное время, затраченное на реагирование и, соответственно, на работу по обращению с момента назначения обращения специалисту Подрядчика или группе исполнителей, ответственным за оказание услуг технической поддержки 3 уровня от начала до завершения работ Подрядчиком. При этом принимается суммарное время нахождения заявки в соответствующих статусах заявки СРО на стороне Подрядчика

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

4.3.6.4.1. Требования к проведению изменений Основанием для внесения изменений является запрос от Заказчика. Все активности по внесению изменений должны быть согласованы с Заказчиком, а действия Подрядчика при оказании данной услуги должны быть зафиксированы. В рамках данного Технического задания изменениями считаются локальные доработки функционала Модуля СЦ, которые не должны приводить к необходимости выполнения дополнительных аттестационных испытаний или переаттестации АСУ ТК в соответствии с п. 33 приказа от 29.04.2021 № 77 «Об утверждении Порядка организации и проведения работ по аттестации объектов информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну». При необходимости внесения изменений в Модуль СЦ, не связанных с критичным инцидентом, существенно нарушающим работоспособность Модуля СЦ, Заказчик направляет Подрядчику обращение (заявку), в котором излагает суть изменения, которое требуется внести в Модуль СЦ. Исполнитель, в течение 3 (трех) рабочих дней с момента поступления соответствующего обращения (заявки), оценивает техническую возможность реализации запрашиваемого изменения и варианты реализации. По итогу проведения оценки Подрядчик направляет Заказчику заключение о возможности реализации данного изменения с описанием возможных вариантов реализации и согласует с Заказчиком проведение данного изменения

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

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

В аварийном режиме осуществляется поиск неисправностей и проведение работ по их устранению. Перевод в аварийный режим должен осуществляться при возникновении сбоев, аварий и прочих незапланированных воздействий, сразу после наступления одной или нескольких аварийных ситуаций, с последующим возвратом в штатный режим функционирования сразу после окончания восстановительных работ. ПО Модуля СЦ должно обладать надежностью, обеспечивающей работу пользователей в произвольном режиме и оперативное восстановление работоспособности при сбоях. В целях обеспечения надежного функционирования ПО должно предусматривать: – сохранение целостности данных при нештатном завершении работы компонентов Модуля СЦ; – сохранение работоспособности программного обеспечения при некорректных действиях пользователя; – резервное копирование базы данных Модуля СЦ. – время восстановления работоспособности Модуля СЦ после отказа не более 4 часов. – отказоустойчивость на уровне 99% при единовременной количестве не менее 200 пользовательских сессий в Модуле СЦ. Указанные характеристики приведены без учета характеристик надежности инфраструктуры и времени передачи информации по каналам связи. При возникновении сбоев в аппаратном обеспечении, включая аварийное отключение электропитания, Модуль СЦ должен автоматически восстанавливать свою работоспособность (не требовать перенастройки) после устранения сбоев и корректного перезапуска аппаратного обеспечения

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

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

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

4.5.11. Требования к показателям назначения 4.5.11.1. Требования к показателям назначения мероприятий по развитию Модуля СЦ В рамках выполнения работ по развитию Модуля СЦ, предусмотренных ТЗ, показатель назначения «Количество пользователей» должен соответствовать значениям, приведенным в данном разделе. Пояснения по показателям, связанным с количеством пользователей, приведены в Таблице 8. Таблица 8. Определения показателей, связанных с количеством пользователей в Модуле СЦ № Показатель Определение Расчетное количество пользователей Количество пользователей, работу которых должен обеспечить Модуль СЦ к моменту сдачи работ по Контракту с учетом достижения всех показателей назначения Расчетное количество одновременно работающих пользователей Количество одновременно работающих пользователей, работу которых должен обеспечивать Модуль СЦ к моменту сдачи работ по Контракту с учетом достижения всех показателей назначения Значения показателей количества пользователей, достижение которых необходимо обеспечить, представлено в Таблице 9

Таблица 9. Значения показателей количества пользователей № Показатель Значение 1. Расчетное количество пользователей 1 000 2. Расчетное среднее количество одновременно работающих пользователей 200 Развитие Модуля СЦ должно быть направлено на достижение следующего эффекта (показателя), подставленного в мероприятии 103.002 «Информационно-аналитическая система регулирования на транспорте (АСУ ТК)» ВПЦТ Минтранса России: Выполнение работ по развитию Модуля СЦ предусмотрено мероприятием по развитию АСУ ТК, приведенном в ВПЦТ Минтранса России на 2026-2028 гг: № 103.002 «АСУ ТК» в составе ИТ расхода 103.26.000005 «Развитие предусматривает реализацию ОКР и эффектов, приведенных в Таблице 10. Таблица 10. ОКР и эффекты, приведенные в ВПЦТ Минтранса России на 2026 г. № ОКР Дата ОКР Эффекты 1 Обеспечено информационное взаимодействие с Минобороны России о происшествиях на транспортных объектах 25.12.2026 Сокращено время сбора и передачи сведений для Минобороны России о ЧС и НС на транспорте с 120 до 10 минут 2 Обеспечена автоматизация формирования отчетов о нештатных ситуациях на транспорте, в том числе по данным внешних систем 25.12.2026 Сокращено время на подготовку отчетов о нештатных ситуациях на транспорте с 20 до 5 минут Реализация остальных ОКР не является предметом данного ТЗ и проводится в рамках отдельного технического задания.

4.5.11.2. Требования к показателям назначения мероприятий по эксплуатации Модуля СЦ. Работы по эксплуатации Модуля СЦ не должны обеспечивать режимы функционирования Модуля СЦ, приведенные в разделе 4.5.2 данного ТЗ

5. СОСТАВ И СОДЕРЖАНИЕ РАБОТ ПО РАЗВИТИЮ И ТЕХНИЧЕСКОЙ ПОДДЕРЖКЕ МОДУЛЯ СЦ (КАЛЕНДАРНЫЙ ПЛАН) - 1 Техническое проектирование Сопроводительным письмом предоставляются Заказчику: · Технический проект, включая следующие документы: – Ведомость технического проекта; – Ведомость машинных носителей информации – Пояснительная записка; – Описание информационного обеспечения системы; – Описание автоматизируемых функций; – Схема функциональной структуры; – Описание организации информационной базы; – Описание программного обеспечения; · Макеты экранных форм компонента «Интерактивная карта»; · Руководство по безопасной разработке программного обеспечения; · Документ о приемке Начало: с даты заключения контракта Окончание: не позднее 31.07.2026 - - Значение характеристики не может изменяться участником закупки

2 Услуги по технической поддержке Модуля СЦ (с даты заключения контракта по 10.09.2026) По окончании оказания Услуг сопроводительным письмом предоставляются Заказчику: – Отчет об оказанных Услугах по технической поддержке; – Актуальные на дату окончания оказания Услуг по данному этапу исходные коды прикладного ПО на электронном носителе (в случае внесения изменений); – Инструкция по сборке и развертыванию (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство пользователя (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство администратора (в случае внесения изменений); – Документ о приемке Начало: с даты заключения контракта Окончание: не позднее 10.09.2026

3 Разработка программного обеспечения (1 очередь, пп. 4.2.1, 4.2.6 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ; – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 1 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 1 очереди; – Руководство по резервному копированию; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 16.09.2026

4 Разработка программного обеспечения (2 очередь, пп. 4.2.3, 4.2.4 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ. – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 2 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 2 очереди; – Руководство по резервному копированию; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 25.09.2026

5 Разработка программного обеспечения (3 очередь, пп. 4.2.2, 4.2.5 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ; – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 3 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 3 очереди; – Руководство по резервному копированию; – Описание ролевой модели; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 09.10.2026

6 Опытная эксплуатация (1 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акт о завершении опытной эксплуатации 1 очереди; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке 17.09.2026 Окончание: не позднее 26.10.2026

7 Опытная эксплуатация (2 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акт о завершении опытной эксплуатации 2 очереди; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке 26.09.2026 Окончание: не позднее 26.10.2026

8 Опытная эксплуатация (3 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Акт о завершении опытной эксплуатации 3 очереди; – Документ о приемке Начало: с 10.10.2026 Окончание: не позднее 26.10.2026

9 Приемочные испытания Сопроводительным письмом предоставляются Заказчику: – Программа и методика приёмочных испытаний; – Протокол приемочных испытаний; – Исходные коды и дистрибутивы на электронном носителе (при условии внесения изменений, с учетом доработок по результатам опытной эксплуатации и проведенных испытаний); – Комплект рабочей документации на Модуль СЦ (при условии внесения изменений, с учетом доработок по результатам опытной эксплуатации и проведенных испытаний); – Акт приемки Системы в эксплуатацию; – Акт приемки-передачи исключительных прав на объект; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке; – Документы в соответствии с разделом 4.5.9 ТЗ; – Обеспечение гарантийных обязательств Начало: с 27.10.2026 Окончание: не позднее 10.11.2026

10 Услуги по технической поддержке Модуля СЦ (с 11.09.2026 по 15.12.2026) По окончании оказания Услуг сопроводительным письмом предоставляются Заказчику: – Отчет об оказанных Услугах по технической поддержке; – Актуальные на дату окончания оказания Услуг по данному этапу исходные коды прикладного ПО на электронном носителе (в случае внесения изменений); – Инструкция по сборке и развертыванию (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство пользователя (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство администратора (в случае внесения изменений); – Документ о приемке Начало: с 11.09.2026 Окончание: не позднее 15.12.2026

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

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

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

6.1. Сведения о гарантийном обслуживании Модуля СЦ Под гарантией понимается устранение Подрядчиком своими силами и за свой счет допущенных по его вине недостатков, выявленных после приемки выполненных Работ, как в работе самой Модуля СЦ, так и недостатков в отчетной документации. Если в период гарантийного срока обнаружатся недостатки, то Подрядчик обязан устранить их за свой счет, в сроки, установленные Заказчиком. Гарантийный срок в этом случае продлевается на период устранения недостатков. Срок гарантии: 1 год с даты приемки Заказчиком результатов исполнения Этапа № 9 контракта. Подрядчиком должны быть внесены соответствующие исправления в техническую и рабочую документацию (указанную в пунктах 5 и 6 настоящего ТЗ), связанные с устранением замечаний к работе Модуля СЦ или в случае выявления Заказчиком недостатков в такой документации в период гарантийного срока. Внесение изменений в документацию технического и рабочего проектирования осуществляется в соответствии с ГОСТ 2.503-2023 и ГОСТ Р 2.504-2021.

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

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

8. ТРЕБОВАНИЯ К СОСТАВУ И СОДЕРЖАНИЮ РАБОТ ПО ПОДГОТОВКЕ МОДУЛЯ СЦ К ВВОДУ В ЭКСПЛУАТАЦИЮ - По результатам проведения приемочных испытаний оформляется Протокол приемочных испытаний и Акт приемки в эксплуатацию. В случае, если взаимодействие с внешними системами не может быть проверено на средах постоянной эксплуатации взаимодействующих систем (по причине неготовности со стороны внешней системы или иным причинам), функции взаимодействия, разработанные в соответствии с требованиями ТЗ, должны быть проверены на тестовых данных с использованием программ-имитаторов взаимодействия. По результатам выполнения этапа приемочных испытаний должны быть подготовлены материалы для регистрации доработанной версии Модуля СЦ (объекта учета) в НФАП в соответствии с требованиями постановления Правительства Российской Федерации от 30 января 2013?г. №?62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин» (с изменениями и дополнениями) в части обязательности размещения результатов работ в национальном фонде алгоритмов и программ для электронных вычислительных машин. Сдача-приемка результатов выполнения Работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная, техническая документация, а также программное обеспечение предоставляется Заказчику в порядке, предусмотренном Контрактом и ТЗ до размещения Подрядчиком в Единой информационной системе в сфере закупок документа о приемке. Результаты проведения опытной эксплуатации, предварительных и приемочных испытаний должны быть зафиксированы в соответствующих протоколах и актах. Выявленные отклонения от настоящего ТЗ, оформляются как недостатки Модуля СЦ - - Значение характеристики не может изменяться участником закупки

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

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

9. ТРЕБОВАНИЯ К ДОКУМЕНТИРОВАНИЮ - 9.1. Общие требования Документация на Модуль СЦ должна быть разработана в составе, указанном в разделах 5-8 данного ТЗ, и должна удовлетворять требованиям комплекса стандартов и руководящих документов на автоматизированные системы: – ГОСТ Р 2.105-2019 в части оформления текстовых документов; – ГОСТ 34.201-2020 в части наименования и обозначения документов. Документация на Модуль СЦ должны оформляться на листах формата А4. Допускается для размещения рисунков и таблиц использование листов формата А3 с подшивкой по короткой стороне листа. Документы объемом более 25 (двадцати пяти) листов должны содержать информационную часть, состоящую из аннотации и содержания. Исходные коды должны быть представлены в 1 (одном) экземпляре на электронном носителе, отчетные материалы должны быть представлены в 2 (двух) экземплярах на бумажном носителе (по одному экземпляру для Заказчика и Подрядчика) и в 1 (одном) экземпляре на электронном носителе в формате документов DOCX и PDF. При разработке документов на Модуль СЦ допускается отклонение от требований комплекса стандартов, описанных выше. Документам на Модуль СЦ должны в обязательном порядке присваиваться уникальные децимальные номера в соответствии с порядком, установленном в ГОСТ 34.201-2020. Документ «Программа и методика предварительных испытаний» должен включать приложения с формой протокола предварительных испытаний и формой акта приемки в опытную эксплуатацию. Документ «Программа опытной эксплуатации» должен включать приложение с формой журнала опытной эксплуатации. Документ «Программа и методика приемочных испытаний» должен включать приложения с формой протокола приемочных испытаний и формой акта приемки в эксплуатацию - - Значение характеристики не может изменяться участником закупки

10. ИСТОЧНИКИ РАЗРАБОТКИ - 10.1. Список литературы Специальная литература для разработки ТЗ не использовалась. 10.2. Нормативно-методические документы Список используемых нормативно-методических документов представлен в разделе 1.6 технического задания. ? Приложение А Эскизы визуального оформления компонента «Интерактивная карта» - - Значение характеристики не может изменяться участником закупки

Приложение Б Параметры оказания услуг - 1 Режим работы Системы Круглосуточно (24х7) 2 Режим доступности информационно-консультационной поддержки пользователей Системы 2.1 Прием и регистрация обращений (заявок) в СРО Регистрация обращений (заявок) производится круглосуточно в режиме 24х7, без праздников и выходных дней. Обработка заявок первой линией поддержки осуществляется в рабочие дни с 9 до 18 часов 2.2 Консультирование сотрудников Заказчика и пользователей Системы в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 3 Режим доступности по решению инцидентов, связанных с работой ППО: 3.1 - приоритет «Критический» Круглосуточно (24х7) 3.2 - приоритет «Высокий» Круглосуточно (24х7) 3.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 3.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4 Режим доступности услуг по адаптации, конфигурации и коррекционному сопровождению Системы 4.1 - приоритет «Критический» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.2 - приоритет «Высокий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 5 Режим доступности по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности 5.1 - приоритет «Критический» Круглосуточно (24х7) 5.2 - приоритет «Высокий» Круглосуточно (24х7) 5.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 5.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) - - Значение характеристики не может изменяться участником закупки

Таблица Б.1.2. Сроки предоставления отчетности, с момента получения запроса № п/п Параметр Значение 1 Предоставление отчета об оказанных услугах за произвольный период 10 рабочих дней 2 Предоставление подробной информации по инциденту с приоритетом «Критический» 16 рабочих часов 3 Предоставление актуализированной документации 10 рабочих дней

Б.1. Базовые параметры оказания Услуг Базовые параметры оказания Услуг приведены ниже: – режимы оказания Услуг (таблица Б.1.1); – сроки предоставления отчетности (таблица Б.1.2). Таблица Б.1.1 - Режимы оказания Услуг № п/п Параметр Значение

Б.2. Приоритеты и регламентные сроки решения обращений (заявок) В зависимости от уровня сбоя в работе Системы обращению (заявке) присваивается один из следующих приоритетов, а также в зависимости от приоритета обращения (заявки) устанавливаются следующие контрольные сроки решения в соответствии с таблицей ниже (Таблица Б.2.1). Таблица Б.2.1 – Приоритеты и регламентные сроки решения обращений (заявок) № п/п Приоритет Максимальное время реагирования Время решения (срок выполнения) Описание приоритета По информационно-консультационной поддержке сотрудников Заказчика и пользователей Системы 1 - не более 1 часа не более 10 часов - По решению инцидентов, связанных с работой ППО: 1 Критический не более 30 минут не более 4 часов - полная недоступность ППО; - недоступность ключевых функций - ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО; - невозможность информационного обмена с ППО для ИС более 4 часов 2 Высокий не более 1 часа не более 8 часов - ошибки/сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; - снижение быстродействия СПО (время отклика ППО на операции превышает 30 секунд); - недоступность управления правами и ролями пользователей 3 Средний не более 4 часов не более 24 часов - невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым -недоступность функции формирования отчетов 4 Низкий не более 8 часов не более 40 часов - отклонение в работе ППО, не влияющее на корректную работу функций; - другие сбои и ошибки, затрагивающие основные функции ППО

По адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) 1 Критический не более 40 минут не более 8 часов - изменения, необходимые при проведении аварийно-восстановительных работ для возобновления работоспособности Системы; - изменения, связанные с критичными ошибками, блокирующими возможность оказания государственных услуг и/или чтение и внесение данных в Систему 2 Высокий не более 1 часа не более 40 часов - изменения, относящиеся к обеспечению работоспособности основной функциональности Системы, устраняют выявленные дефекты в работе Системы, оказывающие существенное влияние на работу пользователей в Системе; - изменения, затрагивающие три и более подсистемы/модуля Системы для адаптации 3 Средний не более 4 часов не более 72 часов - изменения, связанные с развитием/улучшением/оптимизацией Системы и выводом новой функциональности в штатном режиме для одного-двух модулей/подсистем; - изменения, связанные с развитием интеграционных механизмов Системы, например обновление существующих и/или реализация новых видов сведений СМЭВ, обновление существующих и/или реализация новых API, адаптация и/или изменение механизмов импорта и экспорта данных Системы и т.д. 4 Низкий не более 8 часов не более 160 часов - изменения, связанные с ошибками/корректировкой/изменением в отображении информации в пользовательском графическом интерфейсе Системы (графика, текст, органы управления, элементы интерфейса)

По устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности 1 Критический не более 30 минут не более 24 часов - критические уязвимости, влияющие на возможную полную недоступность ППО, ключевых функций Системы, ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО без возможности восстановления работоспособности Системы. - Критический уровень CVSS > 8.0 2 Высокий не более 1 часа не более 84 часов - критические уязвимости, влияющие на ошибки и сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО. - Высокий уровень CVSS 5.0 - 8.0 3 Средний не более 4 часов не более 120 часов - уязвимости, влияющие на невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым - Средний уровень CVSS 2.0 - 4.9 4 Низкий не более 8 часов не более 160 часов - уязвимости, влияющие на отклонение в работе ППО, не влияющее на корректную работу функций; - другие сбои и ошибки, затрагивающие основные функции ППО - Низкий уровень CVSS < 2.0

Взаимодействие Заказчика и Подрядчика в части регистрации и контроля времени реагирования и решения обращения (заявки) осуществляется через СРО. Заказчик предоставляет Подрядчику доступ к СРО после заключения Контракта. Поступившие от разных пользователей заявки по поводу однотипных инцидентов или имеющие общую причину должны объединяться в одну заявку. Срок выполнения включает время диагностики инцидента, в ходе которого определяется причина инцидента (проблемы) и способ его устранения. Подрядчик должен обеспечить функционирование Модуля СЦ в соответствии с требованиями и параметрами, указанными в настоящем ТЗ и Регламенте оказании услуг. Основные параметры быстродействия типовых операций в Модуле СЦ указаны в таблице ниже (таблица Б.2.2). Таблица Б.2.2 - Параметры быстродействия Модуля СЦ № п/п Наименование параметра Значение (секунд) 1 Среднее время получения сообщения из очереди сообщений 10 2 Среднее время получения ответа от Системы 5 3 Среднее время открытия карточки реестра 5

Приложение В Регламент оказания услуг - Приложение Г Форма Отчета об оказанных услугах Отчет об оказанных услугах за этап «наименование этапа» в период с «__» _________ по «__» _________. № п/п Наименование услуги Общее количество Номер ОРС Краткое Описание Время реагирования по ТЗ Время реагирования фактическое Время решения по ТЗ Время решения фактическое Результат соблюдения времени реагирования Результат соблюдения времени решения Примечание 1 Услуги по информационно-консультационной поддержке работников Заказчика 2 546782 Консультация по работе Модуля СЦ 1 2 10 часов 11 часов Нет Нет 567123 Консультация по схеме БД 1 1 10 часов 1 час Да Да 2 … … Заказчик Подрядчик /Должность/ /Должность/ ____________________ /Ф.И.О/ ___________________ /Ф.И.О/ М.П. М.П. «_____»_______________________202_г. «_____»_______________________202_г - - Значение характеристики не может изменяться участником закупки

Приложение 1 к Отчету об оказанных услугах Журнал обращений (заявок) на оказание услуги по информационно-консультационной поддержке пользователей Системы (шаблон) Наименование Исполнителя в этапе «наименование этапа» в период с ________________ по _______________ оказал(о) Услугу по поддержке пользователей Системы в объеме, указанном в Таблице 1 Таблица 1 - Журнал обращений (заявок) пользователей Системы № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. ИТОГО зарегистрировано: Всего обращений (заявок): ________ ИТОГО решено: Всего обращений (заявок): ________

Приложение 2 к Отчету об оказанных услугах Журнал обращений (заявок) по решению инцидентов, связанных с работой ППО (шаблон) Наименование Исполнителя в этапе «наименование этапа» в период с ________________ по _______________ оказал(о) Услугу по решению инцидентов в объеме, указанном в Таблице 1. Таблица 1 - Журнал по решению инцидентов № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. ИТОГО зарегистрировано: Всего инцидентов: ________ ИТОГО решено: Всего инцидентов: ________

Приложение 3 к Отчету об оказанных услугах Журнал обращений (заявок) выполнения адаптационного, конфигурационного и коррекционного сопровождения Системы (шаблон) Журнал выполнения адаптации, конфигурации и коррекции Системы сформирован за этап «наименование этапа» в период с «__» _________ по «__» ____________ и представлен в таблице ниже (Таблица 1). Таблица 1 - Журнал выполнения адаптации, конфигурации и коррекции сопровождения Системы № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. Количество выполненных заявок за этап: ________

Приложение 4 к Отчету об оказанных услугах Журнал обращений (заявок) по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности (шаблон) Журнал обращений (заявок) по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности сформирован за этап «наименование этапа» в период с «__» _________ по «__» ____________ и представлен в таблице ниже (Таблица 1). Таблица 1 - Журнал выполнения заявок по устранению уязвимостей в ППО № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. Количество выполненных заявок за этап: ________

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

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

Таблица 1 - Типы обращений (заявок) Тип обращения (заявки) Описание Запрос на обслуживание Подготовка SQL запроса к СУБД для решения прикладной задачи и д р. – запрос на любое действие, не являющееся запросом информации и несовершенный на основе происшествия, прямо или косвенно влияющего на работу Системы Консультация (входит в тип обращения (заявки) «Запрос на обслуживание») «Где взять / куда обратиться...?», «Как сделать / выполнить…», «Как это работает…?» - запрос, имеющий своей целью получение информационной поддержки Инцидент Разбор ошибок/сбоев и подготовка материалов (корректировочных релизов, инструкций) для Заказчика для устранения ошибок/сбоев, которые приводят к частичному и полному нарушению работоспособности всех или отдельных функций ППО. Подготовка изменения и материалов, необходимых для проведения аварийно-восстановительных работ для возобновления работоспособности Системы. ЗНИ Подготовка изменений, связанных с изменением, улучшением/оптимизацией Системы и выводом новой модифицированной функциональности в штатном режиме. Подготовка изменений, связанных с модификацией существующих и/или реализация новых интеграционных механизмов для получения/обработки данных внешних систем. Подготовка изменений графического интерфейса по требованиям Заказчика

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

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

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

Уровень технической поддержки Организационно-структурная часть технической поддержки, имеющая определённые организационно-нормативными документами зоны ответственности, обязанности, а также временные нормативы, в течение которых эти обязательства должны выполняться либо эскалироваться на следующий уровень технической поддержки Услуги Услуги по технической поддержке Информационно-аналитической системы регулирования на транспорте АСУ ТК ФИО Фамилия, имя, отчество Эскалация Процедура повышения внимания к обращению (заявке) путем повышения его приоритета и/или передачи на следующий уровень технической поддержки, а также привлечение ролей, которые могут принимать решения без передачи на следующий уровень технической поддержки API Англ. Application Programming Interface — программный интерфейс приложения, интерфейс прикладного программирования — описание способов (набор классов, процедур, функций, структур или констант), которыми одна компьютерная программа может взаимодействовать с другой программой

CVSS Англ. Common Vulnerability Scoring System - открытый стандарт, используемый для расчета количественных оценок уязвимости в безопасности компьютерной системы, обычно с целью понять приоритет ее исправления. В современном инструментарии информационной безопасности используется версия 3.0 и выше с дополнительными метриками к базовым оценкам ID Англ. Identifier – идентификатор, уникальный признак объекта, позволяющий отличать его от других объектов, то есть, идентифицировать SLA Англ. Service Level Agreement - утвержденные условия по обработке обращения (заявки) с установленными метриками времени, которые определяют пороговые значения для эскалации в зависимости от статуса обращения (заявки) (например, время реакции – время от регистрации до осуществления первичной обработки, время решения – время от регистрации обращения (заявки) до его решения и т.д.) SQL Англ. Structured Query Language — «язык структурированных запросов», — декларативный язык программирования, применяемый для создания, модификации и управления данными в реляционной базе данных, управляемой соответствующей СУБД

1 Общие сведения 1.1 Полное наименование Услуг Оказание услуг по технической поддержке Модуля СЦ АСУ ТК в 2026 году. 1.2 Предмет Регламента оказания услуг Требования Технического задания

2 Общие положения 2.1 Цель и задачи оказания услуг Целью технической поддержки Системы является обеспечение ее стабильного и безопасного функционирования и эксплуатации, предупреждение, выявление и устранение сбоев в работе Системы и минимизация их неблагоприятного влияния. Для достижения поставленной цели требуется решение следующих задач: 1. Обеспечение информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы. 2. Поддержание параметров функционирования ППО Системы, удовлетворяющих требованиям производственных процессов, включая их непрерывность. 3. Обеспечение бесперебойного функционирования ППО и своевременное устранение сбоев и аварийных ситуаций в Системе. 4. Своевременное устранение уязвимостей при выявлении таковых, в соответствии с требованиями к обеспечению информационной безопасности. 5. Адаптация, конфигурирование, коррекция программного обеспечения в соответствии с изменениями нормативно-правовой базы и запросами уполномоченных сотрудников органов государственной власти, включая выполнение процедур тестирования и участие в обновлениях ППО на стендах Заказчика. 6. Обеспечение сохранения работоспособности ППО в изменяемой среде эксплуатации. 7. Ведение документации по настоящему контракту и инициирование актуализации документации на Систему по результатам обработки запросов Заказчика и внесения соответствующих изменений в ППО

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

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

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

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

4 Формы обращений (заявок) на оказание услуг по технической поддержке Системы, заполняемые в СРО 4.1. Форма обращения (заявки) на оказание услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы При подаче обращения (заявки) типа «ЗНО» в СРО указывается (Таблица 5): Таблица 5 – Описание атрибутов формы обращения (заявки) на оказание услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 5) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 5) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 5) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 5) Категория обращения: информационно-консультационная поддержка Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 5) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 5) Текст запроса на оказание услуги по информационно-консультационной поддержке сотрудников Заказчика Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 5)

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

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

На рисунке 8 приведена форма обращения (заявки) типа «Инцидент» в СРО. Рисунок 8 - Форма обращения (заявки) типа «Инцидент» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуги по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности, заполненную в свободной форме

Приложение 1 к Регламенту Матрица ответственных за взаимодействия в рамках выполнения работ по техническому сопровождению Системы Таблица 1 – Ответственные за взаимодействия в рамках выполнения работ по техническому сопровождению Системы со стороны Исполнителя ФИО Должность Адрес электронной почты Телефон — — — Общий контакт

Приложение 2 к Регламенту Приоритеты и регламентные сроки решения обращений (заявок) Приоритеты и регламентные сроки решения обращений (заявок) приведены в таблице 1. Таблица 1 – Приоритеты и регламентные сроки решения обращений (заявок) № п/п Приоритет Максимальное время реагирования Время решения (срок выполнения) Описание приоритета

По информационно-консультационной поддержке сотрудников Заказчика и пользователей Системы 1 – не более 1 часа не более 10 часов –

Приложение Д Форма Протокола проверки результатов организационно-штатных и подготовительных мероприятий (шаблон) Протокол проверки результатов организационно-штатных и подготовительных мероприятий Настоящий Протокол содержит результаты проверки организационно-штатных и подготовительных мероприятий, проведенных Исполнителем (Таблица Д.1). Таблица Д.1. Протокол проверки результатов № Мероприятия Подготовительного этапа Результат проверки 1. Определить и направить Заказчику документ «Ответственные за взаимодействия в рамках выполнения работ по техническому сопровождению Системы со стороны Исполнителя». Документ содержит контактную информацию (ФИО, должность, адрес электронной рабочей почты, номер телефона) не менее чем о 2 лицах, ответственных за оказание услуг со стороны Подрядчика Выполнено/Не выполнено 2. Обеспечить подключение специалистов Подрядчика к Системе Выполнено/Не выполнено 3. Обеспечить подключение специалистов Подрядчика к СРО Выполнено/Не выполнено Заказчик Подрядчик /Должность/ /Должность/ ____________________ /Ф.И.О/ ___________________ /Ф.И.О/ М.П. М.П. «_____»_______________________202_г. «_____»_______________________202_г

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

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

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

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

3.4.1 Инцидент На рисунке 2 представлена функциональная схема регистрации и сопровождения обращений (заявок) типа «Инцидент». Рисунок 2 - Функциональная схема регистрации и сопровождения обращений (заявок) типа «Инцидент» 3.4.2 Запрос на обслуживание На рисунке 3 представлена функциональная схема регистрации и сопровождения обращения (заявки) типа «ЗНО». Рисунок 3 - Функциональная схема регистрации и сопровождения обращения (заявки) типа «ЗНО» 3.4.3 Запрос на изменение На рисунке 4 представлена функциональная схема регистрации и сопровождения обращений (заявок) типа «ЗНИ». Рисунок 4 - Функциональная схема регистрации и сопровождения обращений (заявок) типа «ЗНИ»

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

4.2. Форма обращения (заявки) на оказание услуги по решению инцидентов, связанных с работой ППО При подаче обращения (заявки) типа «Инцидент» в СРО указывается (Таблица 6): Таблица 6 – Описание атрибутов формы обращения (заявки) на оказание услуги по решению инцидентов, связанных с работой ППО Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 6) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 6) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 6,) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 6) Категория обращения (заявки): инцидент Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 6) Приоритет изменения Время - одно из значений: Низкий, Средний, Высокий или Критический. Определяет, очередность решения обращения (заявки), ресурсы, привлекаемые для решения обращения (заявки), порядок/процедура действий при решении обращения (заявки) – поле СРО «Приоритет» (см. рисунок 6,)

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

На рисунке 6 приведена форма обращения (заявки) типа «Инцидент» в СРО. Рисунок 6 - Форма обращения (заявки) типа «Инцидент» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуги по решению инцидентов, связанных с работой ППО, заполненную в свободной форме

По решению инцидентов, связанных с работой ППО 1 Критический не более 30 минут не более 4 часов – полная недоступность ППО; – недоступность ключевых функций; – ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО; – невозможность информационного обмена с ППО для ИС более 4 часов 2 Высокий не более 1 часа не более 8 часов – ошибки/сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; – снижение быстродействия СПО (время отклика ППО на операции превышает 30 секунд); – невозможность управления правами и ролями пользователей 3 Средний не более 4 часов не более 24 часов – невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым недоступность функции формирования отчетов 4 Низкий не более 8 часов не более 40 часов – отклонение в работе ППО, не влияющее на корректную работу функций; – другие сбои и ошибки, затрагивающие основные функции ППО

По адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) 1 Критический не более 40 минут не более 8 часов – изменения необходимые при проведении аварийно-восстановительных работ для возобновления работоспособности Системы; – изменения, связанные с критичными ошибками, блокирующими возможность оказания государственных услуг и/или чтение и внесение данных в Систему 2 Высокий не более 1 часа не более 40 часов – изменения относящиеся к обеспечению работоспособности основной функциональности Системы, устраняют выявленные дефекты в работе Системы, оказывающие существенное влияние на процесс оказания государственных услуг и работу пользователей в Системе; – изменения, затрагивающие три и более подсистемы/модуля Системы для адаптации 3 Средний не более 4 часов не более 72 часов – изменения, связанные с развитием/улучшением/оптимизацией Системы и выводом новой функциональности в штатном режиме для одного-двух модулей/подсистем; – изменения, связанные с развитием интеграционных механизмов Системы, например, обновление существующих и/или реализация новых видов сведений СМЭВ, обновление существующих и/или реализация новых API, адаптация и/или изменение механизмов импорта и экспорта данных Системы и т.д. 4 Низкий не более 8 часов не более 160 часов – изменения, связанные с ошибками/ корректировкой/изменение в отображении информации в пользовательском графическом интерфейсе Системы (графика, текст, органы управления, элементы интерфейса)

По устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности 1 Критический не более 30 минут не более 24 часов – критические уязвимости, влияющие на возможную полную недоступность ППО, ключевых функций Системы, ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО без возможности восстановления работоспособности Системы; – Критический уровень CVSS > 8.0 2 Высокий не более 1 часа не более 84 часов – критические уязвимости, влияющие на ошибки и сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; – Высокий уровень CVSS 5.0 - 8.0 3 Средний не более 4 часов не более 120 часов – уязвимости, влияющие на невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым; – Средний уровень CVSS 2.0 - 4.9 4 Низкий не более 8 часов не более 160 часов – уязвимости, влияющие на отклонение в работе ППО, не влияющее на корректную работу функций; – другие сбои и ошибки, затрагивающие основные функции ППО; – Низкий уровень CVSS < 2.0

4.3. Форма обращения (заявки) на оказание услуг по адаптационному конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) При подаче обращения (заявки) типа «ЗНИ» в СРО указывается (Таблица 7): Таблица 7 – Описание атрибутов формы обращения (заявки) на оказание услуг по адаптационному, конфигурационному и коррекционному сопровождению Системы Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 10) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 9) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 10) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 10) Категория обращения (заявки): запрос на изменение Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 7) Приоритет изменения Время, очередность решения обращения (заявки), ресурсы, привлекаемые для решения обращения (заявки), порядок/процедура действий при решении обращения (заявки) – поле СРО «Приоритет» (см. рисунок 7) Тип изменения Справочник, классифицирующий типовые запросы характерные для Системы – поле СРО «Предмет обращения» (см. рисунок 7) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 7) Текст запроса на оказание услуги по адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 7)

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

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

- 62.01.11.000 - Этап№7: Опытная эксплуатация (2 очередь) ОКПД2: 62.01.11.000 ОПРЕДЕЛЕНИЯ, ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ Автоматизированная система (АС) Система, состоящая из комплекса средств автоматизации, реализующего информационную технологию выполнения установленных функций, и персонала, обеспечивающего его функционирование (ГОСТ Р 59853-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения») АРМ Автоматизированное рабочее место АСУ ТК, Система Информационно-аналитическая система регулирования на транспорте АТС Автоматическая телефонная станция БД База данных ГИС Государственная информационная система ГОСТ Государственный стандарт ГЦОД СИЦ Минтранса России, ГЦОД Головной центр обработки данных ФГБУ «СИЦ Минтранса России» Дашборд Интерактивная аналитическая панель, графический интерфейс. ЕИС Единая информационная система в сфере закупок ЕСИА Единая система идентификации и аутентификации Заказчик Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» КИИ Критическая информационная инфраструктура Кластер Кла?стер (англ. cluster) – объединение нескольких однородных элементов, которое может рассматриваться как самостоятельная единица, обладающая определёнными свойствами Компонент Часть АС, выделенная по определенному признаку или совокупности признаков и рассматриваемая как единое целое (ГОСТ Р 59853-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения») Контракт Контракт на выполнение работ по развитию и оказанию услуг по технической поддержке Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК в 2026 году, заключаемый по результатам проведения конкурентной процедуры закупки в соответствии с требованиями Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» ... 1. ОБЩИЕ СВЕДЕНИЯ – Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 19.02.2026 №ЕФ-1; – План мероприятий по профилактике случаев непроизводственного травматизма граждан на железнодорожном транспорте, являющийся приложением к постановлению коллегии Министерства транспорта Российской Федерации от 11.03.2026 № 2 ... 2. ЦЕЛИ И НАЗНАЧЕНИЕ ВЫПОЛНЕНИЯ РАБОТ 2.2. Назначение и цели развития и технической поддержки Модуля СЦ Назначение Модуля СЦ: – оперативный мониторинг нештатных и чрезвычайных ситуаций на транспорте ; – оповещение заинтересованных лиц и структур о нештатных и чрезвычайных ситуациях; – сбор, обработка и хранение данных о нештатных и чрезвычайных ситуациях. Целями развития Модуля СЦ являются: – расширение состава данных об оперативной обстановке на транспорте; – оптимизация процесса сбора данных об оперативной обстановке на транспорте; – повышение информированности пользователей за счет визуализация данных Модуля СЦ; – автоматизация процесса формирования отчетов о ЧС и нештатной ситуации на транспорте; – обеспечение информационного взаимодействия с заинтересованными организациями по вопросам ведения. ... - Условная единица - 1,00 - 2 339 999,81 - 2 339 999,81

- Наименование характеристики Значение характеристики Единица измерения характеристики Инструкция по заполнению характеристик в заявке ОПРЕДЕЛЕНИЯ, ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ Автоматизированная система (АС) Система, состоящая из комплекса средств автоматизации, реализующего информационную технологию выполнения установленных функций, и персонала, обеспечивающего его функционирование (ГОСТ Р 59853-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения») АРМ Автоматизированное рабочее место АСУ ТК, Система Информационно-аналитическая система регулирования на транспорте АТС Автоматическая телефонная станция БД База данных ГИС Государственная информационная система ГОСТ Государственный стандарт ГЦОД СИЦ Минтранса России, ГЦОД Головной центр обработки данных ФГБУ «СИЦ Минтранса России» Дашборд Интерактивная аналитическая панель, графический интерфейс. ЕИС Единая информационная система в сфере закупок ЕСИА Единая система идентификации и аутентификации Заказчик Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» КИИ Критическая информационная инфраструктура Кластер Кла?стер (англ. cluster) – объединение нескольких однородных элементов, которое может рассматриваться как самостоятельная единица, обладающая определёнными свойствами Компонент Часть АС, выделенная по определенному признаку или совокупности признаков и рассматриваемая как единое целое (ГОСТ Р 59853-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения») Контракт Контракт на выполнение работ по развитию и оказанию услуг по технической поддержке Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК в 2026 году, заключаемый по результатам проведения конкурентной процедуры закупки в соответствии с требованиями Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» Значение характеристики не может изменяться участником закупки Модуль iМинтранс Модуль сбора данных и представления показателей деятельности Министерства транспорта Российской Федерации iМинтранс АСУ ТК Модуль СЦ Модуль сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК НС Нештатная ситуация НСИ Нормативно-справочная информация ОТИ Объект транспортной инфраструктуры П-ГИС Геоинформационная подсистема П-ИВ Подсистема информационного взаимодействия П-НСИ Подсистема ведения нормативно-справочной информации и метаданных ПО Программное обеспечение Подрядчик, Исполнитель Организация, с которой будет заключен контракт на выполнение работ по развитию Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК П-СД Подсистема сбора данных Работы Работы по развитию Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК СЗИ Средство защиты информации СМЭВ Система межведомственного электронного взаимодействия СУБД Система управления базами данных ТЗ Техническое задание (настоящий документ) ТС Транспортное средство ТК Транспортный комплекс Учреждение Учреждения в области информационной безопасности ФГБУ «СИЦ Минтранса России» Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации», Заказчик Федеральный закон № 44-ФЗ Федеральный закон от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» ФЗ Функциональная задача ФЗ «Реестр объектов» Функциональная задача «Формирование и ведение единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации» ФСБ России Федеральная служба безопасности Российской Федерации ФСТЭК России Федеральная служба по техническому и экспортному контролю ЧС Чрезвычайная ситуация ЭВМ Электронно-вычислительная машина API От англ. Application Programming Interface – интерфейс прикладного программирования – совокупность инструментов и функций в виде интерфейса для взаимодействия с программой CSS От англ. Cascading Style Sheets — каскадные таблицы стилей FPS От англ. frame per second - количество кадров в секунду HTML От англ. HyperText Markup Language - стандартный язык разметки документов, создающий основу и структуру всех веб-страниц JSON От англ. JavaScript Object Notation – текстовый формат обмена данными, основанный на JavaScript WebAssembly (Wasm) Открытый стандарт, представляющий собой низкоуровневый бинарный формат инструкций, который позволяет выполнять код, написанный на языках C++, Rust или Go, в браузерах с производительностью, близкой к нативной 1. ОБЩИЕ СВЕДЕНИЯ – Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 19.02.2026 №ЕФ-1; – План мероприятий по профилактике случаев непроизводственного травматизма граждан на железнодорожном транспорте, являющийся приложением к постановлению коллегии Министерства транспорта Российской Федерации от 11.03.2026 № 2 Значение характеристики не может изменяться участником закупки 1.6. Перечень документов, требования которых должны быть учтены при выполнении работ – Федеральный закон Российской Федерации от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации»; – Федеральный закон Российской Федерации от 27.07.2006 № 152-ФЗ «О персональных данных»; – Федеральный закон Российской Федерации от 06.04.2011 № 63-ФЗ «Об электронной подписи»; – Федеральный закон Российской Федерации от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации»; – Указ Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации»; – Указ Президента Российской Федерации от 01.05.2022 № 250 «О дополнительных мерах по обеспечению информационной безопасности Российской Федерации»; – Указ Президента Российской Федерации от 31.03.2010 № 403 «О создании комплексной системы обеспечения безопасности населения на транспорте»; – постановление Правительства Российской Федерации от 30.07.2004 № 395 «Об утверждении Положения о Министерстве транспорта Российской Федерации»; – постановление Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации»; – постановление Правительства Российской Федерации от 16.11.2015 № 1236 «Об установлении запрета на допуск программного обеспечения, происходящего из иностранных государств, для целей осуществления закупок для обеспечения государственных и муниципальных нужд»; – постановление Правительства Российской Федерации от 23.12.2024 № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц»; 1.8. Общие сведения об источниках и порядке финансирования работ Источником финансирования являются средства субсидии федерального бюджета Российской Федерации, предоставленной в соответствии с абзацем вторым пункта 1 статьи 78.1 Бюджетного кодекса Российской Федерации (код цели 08-01) 1.9. Порядок оформления и предъявления результатов работ Подрядчик должен передать Заказчику результаты работ в порядке, определенном Контрактом в сроки, установленные п. 5 настоящего ТЗ, в соответствии с Календарным планом 1.10. Место выполнения Работ Работы выполняются удаленно на комплексе технических средств Заказчика. Адрес размещения комплекса технических средств Заказчика: Московская обл., Богородский район, пос. Горбуша, Радиоцентр. Техническая возможность удаленного подключения обеспечивается Заказчиком (в части предоставления параметров доступа). Оплата телематических и иных услуг, технических и программных средств, необходимых Подрядчику для удаленного подключения и для выполнения требований по информационной безопасности, осуществляется Подрядчиком самостоятельно за свой счет 1.1. Наименование Системы Полное наименование системы: Информационно-аналитическая система регулирования на транспорте. Условное обозначение системы: АСУ ТК. Полное наименование модуля: Модуль сбора, ведения и анализа информации о нештатных ситуациях на транспорте. Условное обозначение модуля: Модуль СЦ. Модуль СЦ создан в рамках контракта от 05.08.2024 № ОК/24_04 на выполнение работ по развитию АСУ ТК в части создания модуля «Сбора, ведения и анализа информации о нештатных ситуациях на транспорте». Развитие Модуля СЦ осуществлено в рамках контракта от 19.05.2025 № ОК/25_09 на выполнение работ по развитию Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК – постановление Правительства Российской Федерации от 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 Федерального закона «Об электронной подписи»; – постановление Правительства Российской Федерации от 08.06.2011 № 451 «Об инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг и исполнения государственных и муниципальных функций в электронной форме»; – постановление Правительства Российской Федерации от 30.01.2013 № 62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин»; – приказ ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации»; – приказ ФСТЭК России от 11.04.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений»; – приказ ФСБ России от 18.03.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений, с использованием шифровальных (криптографических) средств»; – приказ ФСБ России от 10.07.2014 № 378 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных с использованием средств криптографической защиты информации, необходимых для выполнения установленных Правительством Российской Федерации требований к защите персональных данных»; 1.2. Шифр темы или номер контракта Присваивается Заказчиком по результатам организации закупочных процедур. 1.2.1. Предмет контракта Выполнение работ по развитию Модуля СЦ. Код по ОКПД2: 62.01.11.000 – услуги по проектированию и разработке информационных технологий для прикладных задач и тестированию программного обеспечения. Оказание услуг по технической поддержке Модуля СЦ. Код по ОКПД2: 62.02.30.000 – услуги по технической поддержке информационных технологий. Выполнение работ по развитию Модуля СЦ предусмотрено с учетом ключевых результатов (ОКР) Ведомственной программы цифровой трансформации Минтранса России на 2026-2028 (далее - ВПЦТ Минтранса России) в составе мероприятия № 103.002 «АСУ ТК» ИТ расхода 103.26.000005 «Развитие Информационно-аналитической системы регулирования на транспорте (АСУ ТК)»: · «Обеспечено информационное взаимодействие с Минобороны о происшествиях на транспортных объектах»; · «Обеспечена автоматизация формирования отчетов о нештатных ситуациях на транспорте, в том числе по данным внешних систем». Выполнение работ по технической поддержке АСУ ТК предусмотрено ВПЦТ Минтранса России в составе мероприятия № 103.002 «АСУ ТК» ИТ расхода 103.26.000021 «Эксплуатация Информационно-аналитической системы регулирования на транспорте (АСУ ТК)» 1.3. Заказчик Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» (ФГБУ «СИЦ Минтранса России»). Адрес: 107078, Москва, Садовая-Спасская ул., д.18, стр. 1. Оператором Системы является Заказчик - Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» (ФГБУ «СИЦ Минтранса России) 1.4. Подрядчик Определяется по результатам проведения конкурентной процедуры закупки в соответствии с требованиями Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (далее – Федеральный закон № 44-ФЗ) 1.5. Основания для выполнения работ Работы осуществляются на основании следующих документов: – постановление Правительства Российской Федерации от 30.12.2003 № 794 «О единой государственной системе предупреждения и ликвидации чрезвычайных ситуаций»; – постановление Правительства Российской Федерации от 08.11.2013 № 1007 «О силах и средствах единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций»; – распоряжение Правительства Российской Федерации от 27.11.2021 № 3363-р «О Транспортной стратегии Российской Федерации до 2030 года с прогнозом на период до 2035 года»; – Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 26.08.2025 №ЕФ-3; – Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 27.11.2025 №ЕФ-23; – приказ Минкомсвязи России от 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.7. Сроки начала и окончания работ Начало работ: с даты заключения Контракта. Окончание работ: не позднее 15.12.2026. Работы выполняются в соответствии с этапами. Сроки выполнения этапов работ по развитию и технической поддержке Модуля СЦ определяются Календарным планом. Календарный план, приведен в разделе 5 настоящего ТЗ 2. ЦЕЛИ И НАЗНАЧЕНИЕ ВЫПОЛНЕНИЯ РАБОТ 2.2. Назначение и цели развития и технической поддержки Модуля СЦ Назначение Модуля СЦ: – оперативный мониторинг нештатных и чрезвычайных ситуаций на транспорте ; – оповещение заинтересованных лиц и структур о нештатных и чрезвычайных ситуациях; – сбор, обработка и хранение данных о нештатных и чрезвычайных ситуациях. Целями развития Модуля СЦ являются: – расширение состава данных об оперативной обстановке на транспорте; – оптимизация процесса сбора данных об оперативной обстановке на транспорте; – повышение информированности пользователей за счет визуализация данных Модуля СЦ; – автоматизация процесса формирования отчетов о ЧС и нештатной ситуации на транспорте; – обеспечение информационного взаимодействия с заинтересованными организациями по вопросам ведения. Значение характеристики не может изменяться участником закупки Целями оказания услуг по технической поддержке являются: – обеспечение информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы; – поддержание параметров функционирования ППО Системы, удовлетворяющих требованиям производственных процессов, включая их непрерывность; – обеспечение бесперебойного функционирования ППО и своевременное устранение сбоев и аварийных ситуаций в Системе; – своевременное устранение уязвимостей при выявлении таковых, в соответствии с требованиями к обеспечению информационной безопасности; – адаптация, конфигурирование, коррекция программного обеспечения в соответствии с изменениями нормативно-правовой базы и запросами уполномоченных сотрудников органов государственной власти, включая выполнение процедур тестирования и участие в обновлениях ППО на стендах Заказчика; – обеспечение сохранения работоспособности ППО в изменяемой среде эксплуатации; – ведение документации по настоящему ТЗ, инициирование и актуализация документации на Систему по результатам обработки запросов Заказчика и внесении соответствующих изменений в ППО. Модуль СЦ применяется в деятельности Министерства транспорта Российской Федерации, подведомственных агентств и службы и другими организациями в соответствии с соглашениями об информационном обмене 2.1. Назначение АСУ ТК АСУ ТК предназначена для автоматизации и информационно-аналитического обеспечения процессов управления развитием транспортного комплекса Российской Федерации, обеспечения публичности деятельности органов государственного управления транспортным комплексом. Основными целями АСУ ТК являются: – повышение эффективности процессов управления функционированием и развитием транспортного комплекса на основе создания единой информационной среды и комплекса информационно-аналитических услуг на уровне органов государственного управления ТК; – повышение уровня безопасности ТК на базе получения полной, достоверной и оперативной информации о происходящих изменениях, своевременного выявления негативных тенденций и для принятия соответствующих мер по их устранению и ликвидации последствий Основными задачами АСУ ТК являются: – автоматизация процессов прогнозирования развития транспортного комплекса и поддержки принятия управленческих решений; – автоматизация процессов мониторинга безопасности и устойчивости транспортного комплекса, управления в чрезвычайных и нештатных ситуациях; – автоматизация процессов управления программами и проектами развития и модернизации транспортного комплекса; – автоматизация процессов мониторинга состояния транспортного комплекса, в том числе с использованием набора ключевых показателей эффективности деятельности транспортного комплекса; – информационно-технологическая поддержка взаимодействия субъектов транспортного комплекса Российской Федерации, органов государственного управления и контроля, международных организаций на основе создания единой технологической среды взаимодействия и управления движением данных (и связанных с ними документов) в транспортном комплексе; – использование в процессах управления транспортным комплексом РФ современных технологий электронного документооборота и электронного обмена данными; – организация межведомственного электронного взаимодействия подразделений Министерства транспорта Российской Федерации, подведомственных агентств и службы с другими организациями 3. ХАРАКТЕРИСТИКА ОБЪЕКТА АВТОМАТИЗАЦИИ АСУ ТК осуществляет идентификацию и авторизацию посредством Единой системы идентификации и аутентификации (ЕСИА). Информационный обмен с внешними информационными системами осуществляется посредством СМЭВ 3 и СМЭВ 4. АСУ ТК развернута на вычислительных мощностях ГЦОД СИЦ Минтранса России Значение характеристики не может изменяться участником закупки 3.2. Описание и текущее состояние объекта автоматизации Модуля СЦ Объектом автоматизации является процесс организации мониторинга информации о НС и ЧС на транспорте. Предметом деятельности Учреждения являются следующие функции: – информационное обеспечение в области транспортной безопасности, защиты населения и территорий от чрезвычайных ситуаций природного и техногенного характера в транспортном комплексе; – подготовка справочных материалов при угрозе возникновения и возникновении чрезвычайных ситуаций и иных происшествий в транспортном комплексе; – взаимодействие и обмен оперативной информацией с органами управления Единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций; – организация оперативного мониторинга обстановки на объектах транспорта при угрозе и возникновении чрезвычайных ситуаций и иных происшествий. Перечень компонентов Модуля СЦ и выполняемые ими функции представлены в Таблице 2 Таблица 2. Перечень компонентов Модуля СЦ и их функции № п/п Компонент Выполняемые функции 1 Регистрация событий – ведение карточки события; – удаление комментария; – динамическое отображение существующих событий в заданном радиусе и за заданный период; – возможность автоматической проверки вводимых данных в части количества пострадавших; – отображение карточки ОТИ, ТС в соответствии с ФЗ Реестр объектов; – сохранение и отображение версии карточки события; – привязка события к координатам по картографической основе; – указание признака выполнения действия по отработке события; – перевод статуса события; – закрытие карточки события; – публикация информации о событии в канале мессенджера; – возможность перехода из карточки события на картографическую основу для просмотра местоположения события 2 Визуализация – отображение событий на картографической основе в виде пиктограмм; – масштабирование карты; – отображение краткой карточки события при выборе события на картографической основе; – отображение списка событий; – отображение карточки события; – отображение журнала действий пользователя; – отображение дополнительной информации (текстовая информация и приложенные файлы); – отображение справки о событиях и отчета о событиях; – отображение фильтров и количества отфильтрованных объектов; – отображение результатов поиска; – отображение статистики по событиям на экране; – возможность создания события с картографической основы; – отображения картографических слоев в зависимости от примененных фильтров; – возможность настройки шага картографической сети; – возможность настройки географической точки центра карты; – отображение количества непрочитанных сообщений; – возможность перехода к детальной карточке события из краткой карточки события при выборе события на картографической основе 3.1. Описание объекта автоматизации АСУ ТК Объектом автоматизации являются процессы основной и обеспечивающей деятельности, направленные на управление транспортным комплексом, в том числе, процессы информационного взаимодействия с другими организациями и субъектами транспортного комплекса. АСУ ТК относится к государственным информационным системам, а также к информационным системам персональных данных и значимым объектам критической информационной инфраструктуры Российской Федерации. АСУ ТК соответствует требованиям, предъявляемым к: – ГИС второго класса защищенности в соответствии с приказом ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах»; – ИС персональных данных при обеспечении третьего уровня защищенности персональных данных в соответствии с требованиями постановления Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»; – значимым объектам КИИ Российской Федерации второй категории значимости с постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении Правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений». Модуль СЦ является подсистемой АСУ ТК. Перечень платформенных решений и функциональных задач АСУ ТК представлен в Таблице 1 Таблица 1 – Перечень платформенных решений и функциональных задач АСУ ТК № Наименование подсистемы/ функциональной задачи/ модуля Назначение 1 Подсистема сбора данных и централизованного хранилища данных Подсистема обеспечивает выполнение сбора данных в АСУ ТК, и в т. ч., в рамках функциональных задач «Формирование и ведение межрегионального транспортного баланса пассажирских перевозок в дальнем (межрегиональном) сообщении» и «Формирование и ведение транспортного паспорта региона» 2 Подсистема информационного взаимодействия Подсистема информационного предназначена для обеспечения информационного взаимодействия подсистем АСУ ТК, а также, взаимодействия АСУ ТК с АС федеральных органов исполнительной власти 3 Подсистема ведения нормативно-справочной информации и метаданных Подсистема предназначена для автоматизации функций формирования и актуализации справочников, классификаторов, реестров и регистров, необходимых для обеспечения информационной поддержки пользователей НСИ и интеграции подсистем АСУ ТК в части применения НСИ 4 Модуль СМЭВ Модуль взаимодействия со СМЭВ представляет собой набор сервисов взаимодействия: сервис синхронного взаимодействия и сервис отправки, осуществляющих дополнительную обработку сообщений, отправляемых в СМЭВ и принимаемых из СМЭВ 5 Геоинформационная подсистема Программное обеспечение геоинформационной подсистемы предназначено для обеспечения смежных подсистем АСУ ТК возможностью работы с картографической информацией, в том числе, отображения на электронных картах объектов транспортной инфраструктуры и получения информации о местоположении, характеристиках контролируемых транспортных объектов 6 Подсистема информационного портала АСУ ТК Подсистема информационного портала предназначена для отображения и входа в функциональные задачи АСУ ТК 7 Подсистема технического портала АСУ ТК Подсистема технического портала АСУ ТК предназначена для управления заявками пользователей и технологического документооборота заявок 3 Информирование – ведение справочника способов оповещения (веб-интерфейс, мессенджер); – формирование сценария выполнения оповещения (настройка условий, способа, параметров оповещения); – выполнение оповещений пользователей 4 Отчетность – формирование отчета и справки о событиях; – фильтрация событий для выгрузки в справку о событиях или в отчет о событиях 5 Администрирование – ведение ролей пользователей; – ведение учетных данных пользователей; – ведение справочника организаций; – ведение справочника групп системы мгновенного обмена сообщениями; – выполнение исходящего звонка на контактный телефонный номер организации; – формирование матрицы эскалации событий Архитектура Модуля СЦ представлена на рисунке 1. Рисунок 1. Архитектура Модуля СЦ 3.3. Состав используемого ПО Модуля СЦ Программная архитектура Модуля СЦ разработана как трехуровневая клиент-серверная архитектура. Архитектура включает в себя следующие уровни: • уровень представления – презентационный уровень, обеспечивающий взаимодействие с пользователя с клиентскими приложениями с использованием веб-браузера («тонкий» клиент); • уровень приложений – реализован в виде сервисов, обеспечивает обработку запросов, поступающих от клиентских приложений, формирование ответов на запрос в доступном пользователю виде (формирование пользовательских интерфейсов); • уровень хранения данных – реализуется как сервер БД и обеспечивает хранение и целостность хранимых данных, создание резервных копий, ведение журнала транзакций, восстановление данных после сбоев. Программная архитектура Модуля СЦ включает в себя сервисы и интерфейсы, указанные в Таблице 3. Таблица 3. Программная архитектура Модуля СЦ Программный сервис/интерфейс Технологии реализации Уровень представления Интерфейс пользователя и администратора (front-end) Javascript Уровень приложений Сервис (GateWay) Kotlin Сервис геокодирования (geocoding-service) Kotlin Сервис уведомлений (notifiсation-service) Kotlin Сервис работы с файлами (file-service) Kotlin Сервис отчетности (report-service) Kotlin Сервис управления событиями (event-service) Kotlin Сервис информирования через мессенджер (messenger-notifier) Python Сервис внешних интеграций (integration-service) Сбор информации из внешних систем и сервисов Брокер сообщений Kafka Уровень хранения данных Файловое хранилище MinIO S3 СУБД Postgres Pro Enterprise 3.4. Информационное взаимодействие программных сервисов и интерфейсов Модуля СЦ Объект автоматизации функционирует в распределенной информационной среде. Обмен данными осуществляется по защищенным каналам связи (в том числе ведомственным сетям передачи данных). Источники информации включают: · внешние автоматизированные системы (органов государственной власти); · внутренние базы данных (реестры объектов транспортной инфраструктуры, паспорта регионов и пр.); · оперативная информация от персонала, поступающая через автоматизированные рабочие места (АРМ) и мобильные устройства. 3.4.1. Взаимодействие Модуля СЦ со смежными подсистемами АСУ ТК Модуль СЦ входит в состав АСУ ТК и взаимодействует со следующими ее функциональными задачами и подсистемами: · Функциональной задачей «Формирование и ведение единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации» (ФЗ «Реестр объектов»); · Геоинформационной подсистемой АСУ ТК (П-ГИС); · Подсистемой ведения нормативно-справочной информации и метаданных (П-НСИ); · Подсистемой сбора данных и централизованное хранилище данных (П-СД); · Подсистемой информационного взаимодействия (П-ИВ). 3.4.2. Взаимодействие с внешними информационными системами Список внешних информационных систем, с которыми осуществляется взаимодействие Модуля СЦ: · ЕСИА; · мессенджер; · Яндекс Геокодер; · Информационная система «Централизованная система сбора информации систем-112»; · ПВК «Поиск-Море», АИС РПТ; · облачная АТС 8 Подсистема проектного архива АСУ ТК Подсистема проектного архива АСУ ТК предназначена для автоматизации деловых процессов должностных лиц Министерства транспорта Российской Федерации, подведомственных агентств и службы, в том числе, и процессов информационного взаимодействия внутреннего и внешнего характера 9 ФЗ «Реестр объектов» Функциональная задача предназначена для формирования и ведения единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации 10 ФЗ «СТП» Функциональная задача предназначена для организации информационно-аналитической поддержки процессов территориального планирования Российской Федерации в области федерального транспорта 11 ФЗ «МРТБ ПП» Функциональная задача предназначена для формирования и ведения межрегионального транспортного баланса пассажирских перевозок в дальнем (межрегиональном) сообщении 12 ФЗ «МДД» Функциональная задача предназначена для осуществления мониторинга дорожного движения 13 ФЗ «ТПР» Функциональная задача предназначена для формирования и ведения транспортного паспорта региона 14 ФЗ «Данные по грузообороту» Функциональная задача предназначена для обеспечения подсистем и пользователей АСУ ТК данными по грузообороту между Российской Федерацией и зарубежными странами 15 ФЗ «МЖТ» Функциональная задача предназначена для осуществления мониторинга железнодорожного транспорта 16 ФЗ «МГМП» Функциональная задача предназначена для осуществления мониторинга грузопотоков в морских портах с целью формирования единой цифровой среды мониторинга и планирования перевозок в/из портов Дальнего Востока 17 Модуль ГЭТ Модуль предназначен для получения, хранения данных инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по отдельно взятому предприятию-перевозчику. Формирования отчетов об инвентаризации с детальными данными по каждому разделу инвентаризации с маршрутизацией в муниципалитет / регион / Минтранс. Содержит агрегированные данные инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по всем перевозчикам, относящихся к данному муниципалитету. Формирует сводный отчет по муниципалитету по каждому разделу инвентаризации с маршрутизацией в регион / Минтранс. Формирует агрегированные данные инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по всем перевозчикам, относящиеся к данному региону и по всем муниципалитетам, относящимся к данному региону. Аналитические и статистические данные о состоянии ГЭТ региона. Содержит данные о видах транспорта, цифровых транспортных сервисах и платежных инструментах Региона. Формирует сводный отчет по каждому разделу инвентаризации с маршрутизацией в Минтранс. Формирует агрегированную статистику и аналитику по всем регионам страны в разрезе транспортных средств, маршрутов, пассажиропотоков, инфраструктуры ГЭТ. Данные о рейтинге регионов и перевозчиков на основании выбранных параметров, документооборот с участниками Системы: получение подписанных печатных форм, их утверждение, возврат на доработку. 18 Модуль iМинтранс Модуль создан для отчета по ключевым показателям транспортного комплекса России (Отраслевые и статистические показатели, исполнение бюджета, исполнение поручений, аналитика СМИ, происшествия по видам транспорта). 19 Модуль СЦ Модуль СЦ предназначен для оперативного мониторинга нештатных ситуаций транспортной отрасли, оповещения заинтересованных лиц и структур и предоставления данных о нештатных ситуациях 3.5. Требования к эксплуатации Применяемое в Системе программное обеспечение, программно-аппаратные и аппаратные комплексы должны соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации» 4. ТРЕБОВАНИЯ К МОДУЛЮ СЦ 4.5.9.4. Подрядчик подтверждает, что обладает всеми правами на передачу Заказчику исключительных прав в соответствии с требованиями настоящего раздела Технического задания. В случае, если к Заказчику по вине Подрядчика будут предъявлены претензии в этой части, иски третьих лиц, связанные с нарушением их прав, Подрядчик принимает на себя такие претензии и иски и возмещает Заказчику все расходы и весь ущерб, понесенный в связи с ними. 4.5.9.5. Подрядчик обязан согласовать с Заказчиком необходимость использования при выполнении работ охраняемых результатов интеллектуальной деятельности, права на которые принадлежат Подрядчику или третьим лицам. 4.5.9.6. В случае, если при выполнении Работ используется готовое программное обеспечение (платформа, подсистема, СУБД и т.д.), которое становится частью (компонентом) Системы, Заказчику передаются полные исключительные права, или неисключительные права (путем заключения лицензионного/сублицензионного договора/соглашения) на такое программное обеспечение со следующими возможностями: – права передаются бессрочно (на весь срок действия исключительных прав); – территория действия Российская Федерация; – должно быть обеспечено право Российской Федерации (в лице Заказчика) передавать, дорабатывать, распространять, развивать результаты работ, созданные в процессе исполнения Контракта, а также перерабатывать такое программное обеспечение. Лицензионное (сублицензионное) соглашение (договор), Акт передачи прав, подписанные Подрядчиком, согласие правообладателя, оформленное в соответствии с положениями Гражданского кодекса Российской Федерации (в случае, если Подрядчик не является правообладателем такого программного обеспечения), инструкция по инсталляции, руководство администратора, руководство пользователя передаются Заказчику в сроки, установленные Техническим заданием для соответствующего функционала Системы Значение характеристики не может изменяться участником закупки Лицензионное (сублицензионное) соглашение (договор) не может возлагать на Заказчика какие-либо обязанности (в т.ч. в части конфиденциальности, предоставления отчетности), не предусмотренные Контрактом. 4.5.9.7. Передача Заказчику исключительных прав, или простых (неисключительных) прав не может повлечь увеличение стоимости Контракта и/или изменение иных существенных условий Контракта. 4.5.9.8. Функциональность Модуля СЦ передается в объеме и в сроки, установленные Техническим заданием. 4.5.9.9. Нарушение условий настоящего раздела Технического задания, в т.ч. отсутствие соответствующего лицензионного (сублицензионного) соглашения (или договора), либо предоставление лицензионного (сублицензионного) соглашения (или договора), не соответствующего требованиям действующего законодательства Российской Федерации или требованиям Контракта, является нарушением существенных условий Контракта. 4.5.9.10. В случае, если в соответствии с пунктом 4.5.9.6 Заказчику передается исключительное право, такая передача осуществляется в порядке, установленном Гражданским кодексом Российской Федерации. 4.5.9.11. В случае, если при выполнении Работ положения пунктов 4.5.9.5-4.5.9.6 не применялись, Подрядчик в составе отчетной документации предоставляет об этом декларацию в свободной форме. Декларация должна содержать сведения о полном соответствии результата Работ требованиям Контракта, а также о неприменении при выполнении работ готового программного обеспечения (платформ, подсистем, СУБД и т.д.), которое стало частью (компонентом) Системы 4.2.4.1. Требования к технической реализации компонента «Интерактивная карта» При реализации компонента «Интерактивная карта» должны учитываться требования, указанные ниже. 4.2.4.1.1. Требования к отображению элементов Повторяющихся элементы карты (ТС, ОТИ, события и пр.) должны отрисовываться с использованием аппаратного создания экземпляров объектов на пользовательском устройстве (WebGL/WebGPU)). Отрисовка каждого объекта отдельным запросом не допускается, должна обеспечиваться возможность одновременного отображения не менее 5 000 объектов без снижения производительности (30 кадров в секунду на тестовой конфигурации). 4.2.4.1.2. Уровни детализации объектов Для управления отображением сложных объектов должно быть создано не менее 3-х уровней детализации, отображаемых при изменении масштаба с возможностью автоматического переключения между уровнями. Все отображаемые объекты должны масштабироваться с учетом разрешения экрана пользователя с сохранением качества детализации. 4.2.4.1.3. Полигональная оптимизация и текстурирование При реализации компонента «Интерактивная карта» должна обеспечиваться технология рельефного тестурирования объектов. Не должны использоваться высокополигональные трехмерные модели. Все повторяющиеся элементы должны генерироваться единоразово и повторно использоваться при последующих отображениях. 4.2.4.1.4. Управление памятью Требуется реализовать потоковую загрузку на устройство пользователя элементов карты и текстур. Загрузка данных целиком при старте приложения не допускается. Необходимо реализовать механизм очистки памяти от элементов, которые находятся вне области видимости камеры в течение заданного времени. 4.2.4.1.5. Требования к взаимодействию пользователя с интерфейсом компонента «Интерактивная карта» Программная реализация механизмов управление камерой (масштабирование и навигация) должна быть выполнена с поддержкой технологии WebAssembly (WASM). Элементы управления должны являться неотъемлемой частью интерактивной карты. 4.2.5. Развитие компонента администрирования (3 очередь) Должна быть выполнена доработка ролевой модели. Ролевая модель должна обеспечивать управление доступом к отдельным объектам Модуля СЦ и их элементам (атрибутам) с разграничением по видам транспорта, регионам и пр., в частности: – определение набора конкретных действий, доступных пользователям (выполняемых над объектом доступа, например, удаление записи, редактирование записи, формирование отчета и др.); – реализация возможности объединения пользователей в группы; – определение прав доступа для групп пользователей; – реализация интерфейса визуальной настройки прав доступа пользователей к объектам Модуля СЦ 4.3.1.1. Требования к составу и содержанию услуг третьего уровня технической поддержки Оказание услуг по технической поддержке Системы осуществляется в рамках этапов в соответствии с календарным планом. Подрядчик в течение 5 рабочих дней с даты заключения Контракта должен предоставить со своей стороны, а Заказчик со своей стороны Матрицу ответственных за взаимодействия в соответствии с Приложением 1 к Регламенту оказания услуг по третьему уровню технической поддержки Модуля СЦ (далее – Регламент, Приложение В). Подрядчик в течение 10 рабочих дней с даты заключения Контракта должен провести мероприятия по организации третьего уровня технической поддержки в соответствии с Регламентом. Услуги по третьему уровню технической поддержки Модуля СЦ должны включать: – организацию Подрядчиком третьего уровня технической поддержки; – информационно-консультационную поддержку работников Заказчика; – решение инцидентов, связанных с работой ППО; – адаптационное, конфигурационное и коррекционное сопровождение Модуля СЦ (в рамках действующих программных модулей и функциональности); – устранение уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности 4.3.1.2. Требования к общему порядку оказания услуг Техническая поддержка Модуля СЦ должна быть организована на трех уровнях: – первый и второй уровни технической поддержки организуется Заказчиком; – третий уровень технической поддержки организуется Подрядчиком. Перечень действий на каждом уровне технической поддержки указан в Таблице 5: Таблица 5 – Перечень действий на каждом уровне технической поддержки Уровень технической поддержки Доступные действия Условия передачи задачи на следующий уровень Первый уровень технической поддержки (далее – 1-й уровень) – принимает обращения (заявки) пользователей Модуля СЦ и работников Заказчика; – регистрирует обращения в Модуле СЦ регистрации обращений; – присваивает уникальный идентификационный номер, классифицирует обращения; – самостоятельно решает обращения, которые связаны с недостаточной квалификацией пользователей или настройками в рамках своей компетенции; – взаимодействует с пользователями Модуля СЦ при решении проблемы Передает обращение на второй уровень поддержки в случае невозможности решения на своем уровне Второй уровень технической поддержки (далее – 2-й уровень) – принимает обращения от 1-го уровня; – уточняет классификацию обращения в результате дополнительного анализа; – самостоятельно решает обращения в рамках своей компетенции; – осуществляет техническую и консультационную поддержку Модуля СЦ; – взаимодействует с сотрудниками 1-го и 3-го уровня и пользователями Модуля СЦ; – формирует заявки для 3-го уровня и контролирует исполнение Передает обращение на третий уровень поддержки в случае невозможности решения на своем уровне Третий уровень технической поддержки (далее – 3-й уровень) – принимает обращения от 2-го уровня; – обеспечивает выполнение требований, предъявляемых Контрактом и настоящим Техническим заданием к Услугам, оказываемым Подрядчиком Все поступающие обращения должны быть исполнены Подрядчиком Работы по устранению неисправности приостанавливаются (по согласованию с Заказчиком) в следующих случаях: – если Подрядчиком в результате диагностики выявлено, что неисправность находится в зоне ответственности Заказчика. Подрядчик информирует Заказчика о выявленной неисправности в зоне его ответственности по согласованным каналам связи; – требуется действие со стороны Заказчика – до момента выполнения данного действия Заказчика. Заказчик информируется о необходимых действиях по согласованным каналам связи; – отсутствие возможности связаться со специалистами Заказчика, участие которых необходимо для устранения неисправности; – требуется доставить оборудование на объект – до момента доставки и установки оборудования. В случаях, представленных выше, время приостановки работ не входит в учет продолжительности устранения неисправности. Учет времени устранения неисправности Подрядчиком считается с момента назначения Инцидента специалисту Подрядчика, ответственному за оказание услуг технической поддержки 3 уровня. Подтверждение необходимости приостановления работ находится в зоне ответственности Подрядчика. Приостановление сроков выполнения задач в соответствии с настоящим пунктом подтверждается Заказчиком по мотивированному обращению Подрядчика в СРО, основанному на данных диагностики или на иных фактических обстоятельствах В случае непринятия Подрядчиком необходимых мер по информированию Заказчика (отсутствие надлежащего обращения от Подрядчика или отсутствие уведомления о необходимости осуществления каких-либо действий Заказчиком) не может являться основанием для приостановления работ по устранению неисправности. В отдельных случаях Подрядчику может потребоваться выполнение технологических работ для устранения причин неисправности или недопущения повторения их в будущем. Для обеспечения устранения неисправности Модуля СЦ Заказчиком проводится классификация в соответствии с приоритетами по степени срочности их устранения. Продолжительность устранения неисправности, а также периодичность информирования Подрядчиком Заказчика о ходе устранения неисправности, определены в Регламенте оказания услуг. При подаче обращения (заявки) наивысшего приоритета через СРО Заказчик должен дополнительно проинформировать службу поддержки Подрядчика о созданном обращении (заявки) по телефону уполномоченного сотрудника Подрядчика. При этом временем подачи обращения (заявки) считается время подачи обращения (заявки) через СРО 4.3.6.4.1. Требования к проведению изменений Основанием для внесения изменений является запрос от Заказчика. Все активности по внесению изменений должны быть согласованы с Заказчиком, а действия Подрядчика при оказании данной услуги должны быть зафиксированы. В рамках данного Технического задания изменениями считаются локальные доработки функционала Модуля СЦ, которые не должны приводить к необходимости выполнения дополнительных аттестационных испытаний или переаттестации АСУ ТК в соответствии с п. 33 приказа от 29.04.2021 № 77 «Об утверждении Порядка организации и проведения работ по аттестации объектов информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну». При необходимости внесения изменений в Модуль СЦ, не связанных с критичным инцидентом, существенно нарушающим работоспособность Модуля СЦ, Заказчик направляет Подрядчику обращение (заявку), в котором излагает суть изменения, которое требуется внести в Модуль СЦ. Исполнитель, в течение 3 (трех) рабочих дней с момента поступления соответствующего обращения (заявки), оценивает техническую возможность реализации запрашиваемого изменения и варианты реализации. По итогу проведения оценки Подрядчик направляет Заказчику заключение о возможности реализации данного изменения с описанием возможных вариантов реализации и согласует с Заказчиком проведение данного изменения При проведении работ по изменению и адаптации Подрядчик должен: – обеспечить выполнение требований безопасной разработки программного обеспечения; – обеспечить предварительное проектирование технических решений и согласование с Заказчиком проекта реализации изменения; – использовать семантическое версионирование (SemVer) в работе, передать Заказчику все артефакты разработки (исходный код и сторонние библиотеки, конфигурации, сборочные и собранные образы и др.); – подготовить полноценное описание функционала, включенного в релиз, с необходимыми схемами и пояснениями к обновлению на стендах Заказчика; – обеспечить тестирование разработанного функционала на стендах Заказчика силами Подрядчика; – решение о переносе измененного ППО на продуктивный стенд принимается Заказчиком по итогу результатов проведенного тестирования; – обеспечить техническое сопровождение процедуры тестирования ППО и переноса измененного ППО на продуктивный стенд Заказчика; – обеспечить экстренное внесение соответствующих изменений в случае выявления некорректной работы продуктивного стенда Заказчика после проведения обновления по итогам разработанного изменения в кратчайшие сроки; – актуализировать при необходимости комплект эксплуатационной документации: o руководство пользователя; o руководство администратора; o иные документы (при необходимости). Результат выполнения изменений должен быть отражен в Отчете по оказанию услуг. Типы и приоритеты изменений могут быть скорректированы в процессе оказания услуг исключительно по согласованию с Заказчиком 4.1. Требования к структуре Модуля СЦ В процессе работ по развитию Системы должны сохраниться основные требования к построению архитектуры Системы в соответствии с принципами трехуровневой архитектуры: 1. уровень хранения данных или уровень базы данных (сервер СУБД); 2. уровень сервера приложений (сервер аналитической обработки); 3. презентационный уровень, обеспечивающий взаимодействие с клиентскими приложениями. В состав Системы должны входить следующие основные компоненты: 4. сервер баз данных; 5. сервер приложений; 6. веб-сервер. Сервер баз данных должен обеспечивать хранение и целостность хранимых данных, создание резервных копий, ведение журнала транзакций, восстановление данных после сбоев. Сервер приложений должен обеспечивать обработку запросов, поступающих от клиентских приложений (через веб-сервер), формирование ответов на запрос в доступном пользователю виде (формирование пользовательских интерфейсов). Веб-сервер должен обеспечивать взаимодействие с оператором и внешними системами по HTTP / HTTPS протоколу в режиме «запрос-ответ» (получения запросов от пользователя и передачи ответа в виде соответствующей информации, обработанной серверами приложений). Взаимодействие Системы с пользователем должно отвечать требованиям модели «тонкого клиента» (т.е. представлять на стороне клиента (пользователя) лишь графический пользовательский интерфейс). Все составляющие Системы должны использовать единую методологию и отвечать единым принципам взаимодействия, надежности и управления. Перечень компонентов Модуля СЦ представлен в Таблице 4. Таблица 4. Перечень компонентов Модуля СЦ, в отношении которых выполняются работы по развитию № п.п. Наименование компонента Модуля СЦ Раздел ТЗ 1 Компонент регистрации событий 4.2.1. 2 Компонент отчетности 4.2.2 3 Компонент визуализации 4.2.3 4 «Интерактивная карта» (компонент создается) 4.2.4 5 Компонент администрирования 4.2.5 4.2. Требования к дорабатываемым функциям модуля СЦ 4.2.1. Развитие компонента регистрации событий (1 очередь) Должны быть выполнены следующие доработки: – обеспечение логирования действий пользователя, связанных с карточкой события; – доработка объектной модели в части создания новых типов сущностей (карточек) с учетом реализуемых интеграций с информационными ресурсами (силы и средства предупреждения и ликвидации ЧС и нештатных ситуаций на транспорте, ТС, ограничения воздушного пространства, неблагоприятные и опасные природные явления); – реализация механизма установления связи между сущностями в Модуле СЦ автоматизированным и ручным способами (события, природные явления, силы и средства предупреждения и ликвидации ЧС и нештатных ситуаций на транспорте, ограничения воздушного пространства, ОТИ, ТС и др.); – отображение в карточке установленных связей между сущностями. 4.2.2. Развитие компонента отчетности (3 очередь) Должна быть обеспечена автоматизация процессов формирования отчетов о ЧС и нештатных ситуациях на транспорте, в т.ч. на основе данных из внешних систем. Включает следующие доработки: – разработка шаблонов отчетов в различных форматах (табличный, текстовый); – реализация выбора фотоматериалов для включения в справку; – форматирование содержимого справок с учетом правил русского языка в отношении окончаний слов (в зависимости от падежа, склонения, числа и рода); – автоматизированное формирование выводов к содержимому справки на основе настраиваемых критериев; – создание интерфейса выбора параметров (фильтрации) для формирования отчетов: o состав полей для включения в отчёт; o настройка диапазонов значений характеристик и дат; o порядок отображения полей; o настройка заголовка. – реализация способа подготовки отчётов в асинхронном режиме (очереди); – реализация интерфейса компонента формирования отчетности для отображения очереди формирования отчетов и статусов их подготовки; – экспорт отчётов в форматы xlsx, csv и справок в форматы pdf, docx. Необходимо разработать не менее 10 шаблонов отчетов и/или справок. Перечень, структура и содержание шаблонов должны быть согласованы с Заказчиком на этапе технического проектирования. 4.2.3. Развитие компонента визуализации (2 очередь) В рамках развития компонента визуализации должны быть выполнены следующие доработки, обеспечивающие: – вывод перечней (списков) сил и средств предупреждения и ликвидации ЧС и нештатных ситуаций на транспорте с отображением мест их постоянного размещения (дислокации) на карте, включая: o отображение зон ответственности на карте; o возможность их фильтрации (по видам транспорта, регионам и пр.); o реализацию инструмента расчета расстояния (с использованием сети автомобильных и железных дорог) между местом события и местами дислокации сил и средств, а также вывода маршрутов на карте; – отображение зон (полигонов) с установленными ограничениями движения в воздушном пространстве на карте; – отображение термических точек; – реализация возможности отображения данных из паспорта региона, отображаемого в модуле iМинтранс (модуль АСУ ТК); – отображение краткой карточки сущностей и ОТИ (краткой информации и/или динамических характеристик объекта) при выборе объекта на карте с возможностью перехода в полную карточку сущности и ОТИ; – отображение данных от Росгидромета, предусматривающих: o отображение неблагоприятных и опасных природных явлений на карте (с заданным периодом обновления данных); o управление отображением явлений на карте, включая настройку состава отображаемых объектов, поиск, фильтрацию, с использованием соответствующей панели управления; o выведение краткой карточки явления при выборе объекта, с возможностью перехода в полную карточку объекта – отображение на карте связанных сущностей и ОТИ; – реализация функции выбора темного и светлого стилей отображения элементов интерфейса, карточек сущностей, картографической основы и объектов, отображаемых на карте; – реализация механизма для выбора картографической основы в одном из распространенных форматов WMTS, TMS, MVT и др. Должна быть предусмотрена возможность настройки перечня картографических основ и параметров доступа к ним; – настройка базового набора дашбордов, содержащих преднастроенные виджеты о количестве событий в разрезе видов транспорта с возможностью перехода к исходным данным (карточкам событий, ОТИ и т.д.), с фильтрацией по параметрам. Параметры фильтрации должны быть определены на этапе технического проектирования. Должно быть обеспечено автоматическое и принудительное обновление данных, отображаемых на дашбордах 4.2.4. Создание компонента «Интерактивная карта» (2 очередь) В составе создаваемого компонента должны отображаться данные, доступные в компоненте визуализации. Требования к интерфейсу интерактивной карты: – интерактивная карта должна быть представлена в виде объемной карты с учетом макетов, представленных в Приложении А к ТЗ; – интерфейс должен корректно отображаться на экранах мониторов (разрешение Full HD 1920?1080), телевизоров (разрешение 4К 3840?2160), жидкокристаллических панелей для видеостены, используемой Заказчиком, с параметрами каждой панели: диагональ 55 дюймов, разрешение 1920x1080; – интерфейс должен корректно отображаться на планшетных устройствах с диагональю экрана 10-12 дюймов, конкретные требования должны быть уточнены на этапе технического проектирования; – должна быть обеспечена кластеризация и генерализация отображения объектов на карте при изменении масштаба; – должно быть обеспечено отображение основных характеристик объектов при выборе их на карте; – должно быть обеспечено управление отображением слоев на карте; – должна быть обеспечена настройка цветовой индикации отображаемых объектов транспортной инфраструктуры; – должно быть обеспечено отображение легенды карты, содержащей отображаемые объекты на карте; – должна быть обеспечена возможность одновременного отображения не менее 5 000 ОТИ и ТС на карте. На интерактивной карте должны быть отображены подвижные объекты совместно с объектами транспортной инфраструктуры (ОТИ), включая следующие возможности: § отображение местоположения транспортных средств (воздушный, водный и автомобильный транспорт) на карте в режиме реального времени (с заданным периодом обновления данных); § отображение маршрутов движения всех ТС за выбранный период времени, в том числе с использованием эффектов анимации; § отображение маршрутов движения ТС, связанных с карточкой события: ТС, являющихся участниками события, и ТС, находящиеся в заданном радиусе от события; § управление отображением сущностей и ОТИ на карте, включая настройку состава отображаемых объектов, поиск, фильтрацию, с использованием соответствующей панели управления и наглядным представлением результатов; § автоматическое изменение вида отображения объектов (цветовая индикация) по заданным условиям (например, при достижении критических значений параметров, характеризующих функционирование объекта); Должна обеспечиваться производительность обновления изображения на экране в 30 кадров в секунду на тестовой конфигурации пользовательского устройства (модель Бештау AIO2402/B560, входящая в Реестр российской промышленной продукции под номером 10394100 или аналог) при одновременном отображении не менее 5 000 объектов и 200 уникальных моделей объектов. Макеты интерфейсов Модуля СЦ должны быть предварительно согласованы с Заказчиком и разработаны с учетом требований ГОСТ Р ИСО 9241-161-2016 «Элементы графического пользовательского интерфейса» Технические меры по обеспечению надежности должны предусматривать: – резервирование критически важных компонентов и данных Системы и отсутствие единой точки отказа; – использование программного резервирования (программной избыточности); – изменение конфигурации используемых средств и применение специализированного ПО, обеспечивающего высокую надёжность. Организационные меры по обеспечению надежности должны быть направлены на минимизацию ошибок пользователей (а также обслуживающего персонала при эксплуатации и проведении работ по обслуживанию), минимизацию времени ремонта или замены вышедших из строя компонентов за счёт: – обеспечения для обслуживающего персонала требуемого уровня квалификации; – регламентации и нормативного обеспечения выполнения работ обслуживающим персоналом; – своевременной диагностики неисправностей. Расчетное значение коэффициента доступности Модуля СЦ должно составлять не менее 0,95. 4.5.3. Требования по диагностированию Модуля СЦ Диагностирование Модуля СЦ должно осуществляться путем анализа записей в системных журналах СУБД, операционных систем серверов, а также с помощью встроенных средств диагностирования общего программного обеспечения Модуля СЦ. Диагностированию подлежат: – сбои и нарушения функционирования технического обеспечения (серверов) Модуля СЦ; – сбои и нарушения функционирования системного программного обеспечения серверов, используемых для работы Модуля СЦ; – сбои и нарушения функционирования прикладного программного обеспечения серверов, используемых для работы Модуля СЦ; – случаи недоступности (отсутствия ответа) или некорректные ответы внешних систем; – сбои и нарушения функционирования СУБД; – сбои при выполнении регламентных операций резервного копирования. При возникновении аварийных ситуаций либо ошибок в программном обеспечении диагностические инструменты должны позволять сохранять набор информации, необходимой для идентификации и устранения проблемы. Модуль СЦ и ее компоненты должны обеспечивать возможность диагностики своей работоспособности с возможностью интеграции с модулем мониторинга АСУ ТК. Набор передаваемых журналов и метрик должен быть определен на этапе технического проектирования 4.5.4. Требования к надежности Должно быть предусмотрено сохранение работоспособности Модуля СЦ при некорректных действиях пользователя и сохранение целостности данных при нештатном завершении работы Модуля СЦ (отказ рабочей станции, потеря сетевого доступа и т.п.). Модуль СЦ должен предоставлять механизмы обеспечения сохранности данных через применение процедур резервного копирования и восстановления, описанных в документации на Систему. Ключевые показатели надежности информационной системы — допустимое время на восстановление работоспособности Модуля СЦ (RTO - recovery time objective) и/или допустимый интервал времени потери изменений в данных при сбоях/отказах (RPO – recovery point objective) должны быть определены Подрядчиком и согласованы с Заказчиком на этапе технического проектирования 4.2.6. Взаимосвязи с внешними автоматизированными системами (1 очередь) Способы взаимодействия с внешними информационными системами должны быть определены на этапе технического проектирования. Должны быть выполнены следующие доработки: – интеграции с информационными ресурсами в целях получения данных о движении подвижных ТС (воздушные суда, суда водного транспорта); – интеграция с информационным ресурсом в целях получения данных о событиях на железнодорожном транспорте. Реализация интеграций должна включать проектирование и реализацию интеграционных механизмов обмена данными с учетом доступных вариантов реализации, обеспечение защищенных способов взаимодействия, настройку отображения отдельных данных на карте (настройка слоев). Взаимодействия, имеющие каналы связи, выходящие за пределы контролируемой зоны взаимодействующих систем, считаются защищенными, если для их защиты используются программные и/или программно-аппаратные шифровальные (криптографические) средства, сертифицированные ФСБ России (далее – СКЗИ). Выбор СКЗИ, схемы подключения и требуемого класса криптостойкости должен производиться в соответствии с Техническими условиями на подключение к информационным ресурсам ФГБУ «СИЦ Минтранса России» и инструкциями по подключению пользователей к ресурсам инфраструктуры Головного центра обработки данных, утвержденных приказом директора ФБГУ «СИЦ Минтранса России» от 24.05.2024 № 21-ОД 4.3. Требования к оказанию услуг по технической поддержке Модуля СЦ 4.3.1. Общие требования к оказанию Услуг Техническая поддержка Модуля СЦ должна осуществляться с учетом требований постановления Правительства Российской Федерации от 06.07.2015 N 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации». Подрядчик обязан выполнять требования законодательства в сфере защиты информации, требования по защите информации, информационной безопасности, указанные в локальных нормативных актах ФГБУ «СИЦ Минтранса России», регламентирующих условия информационного взаимодействия, защиты информации и подключения к информационным ресурсам ФГБУ «СИЦ Минтранса России», участвующих в информационном взаимодействии в рамках оказания услуг по технической поддержке АСУ ТК в 2026 году Для обеспечения взаимодействия с Заказчиком Подрядчик со своей стороны определяет ответственных лиц, уполномоченных в структуре Подрядчика за своевременное и качественное оказание Услуг в рамках настоящего ТЗ, а также контактную информацию ответственных лиц (телефон, электронную почту). Подрядчик должен предоставить Заказчику единый адрес электронной почты для приема обращений (заявок) в течение 3 (трех) рабочих дней после заключения Контракта. Указанный в настоящем пункте адрес электронной почты (способ направления обращений (заявок) применяется в случае сбоя в работе СРО Заказчика. Со своей стороны, Заказчик предоставляет Подрядчику перечень и контактную информацию (телефон, электронную почту) уполномоченных лиц для осуществления взаимодействия с указанием зон ответственности. О любых изменениях в контактной информации ответственных лиц Стороны должны уведомить друг друга в течение 1 (одного) рабочего дня с момента возникновения таких изменений посредством уведомления на электронную почту ответственных лиц и/или в письменной форме. В результате оказания услуг по настоящему ТЗ не должны быть изменены исходные коды, дистрибутивы и иные компоненты Модуля СЦ вне согласованных с Заказчиком изменений. Любые изменения исходных кодов, дистрибутивов и иных компонентов Модуля СЦ должны производиться только после согласования с Заказчиком уполномоченными лицами по электронной почте или иным заранее согласованным способом. Не должна быть ухудшена надежность и производительность Модуля СЦ. Оказание услуг по Контракту не должно нарушать требования к информационной безопасности, описанной в документации на Модуль СЦ Оказание услуг в рамках данного технического задания осуществляется Подрядчиком по обращению (заявке) Заказчика, направляемой посредством СРО Заказчика. Регистрация обращений, поступивших непосредственно в Модуль СЦ регистрации обращений Заказчика, производится сотрудниками Заказчика, которые обеспечивают первый уровень технической поддержки Модуля СЦ. В случае назначения приоритета «Критический» или «Высокий», информация о назначении также дублируется оповещением ответственных представителей Подрядчика посредством звонка на предоставленные номера телефонов. Обращение (заявка) должна содержать следующую информацию: – контакты пользователя/организации; – приоритет обращения, соответствующий Приложению 2 к Регламенту; – время обнаружения; – наименование компонента АСУ ТК - Модуль СЦ; Информация может быть расширена по согласованию с Заказчиком. Обращения (заявки) сотрудников Заказчика должны приниматься Подрядчиком через веб-интерфейс СРО. В процессе обработки обращений (заявок) Подрядчик должен обеспечить выполнение следующих процедур: – прием обращений(заявок) от сотрудников Заказчика; – оказание информационно-консультационной поддержки в соответствии с требованиями настоящего Технического задания; – информирование сотрудников Заказчика о статусе обработки и результатах обработки обращений(заявок). Подрядчик осуществляет обязательную регистрацию и учет всех обращений и заявок, поступивших к Подрядчику от представителей Заказчика в рамках оказания настоящих услуг Примечание: в случае приостановки работы по обращению или заявке (обращение или заявка находится в статусе «Приостановлено»), указываются причины, по которым работы по обращению или заявке приостановлены с указанием перечня действий/информации, запрошенных у инициатора обращения, а также даты, формы и адресата такого запроса. В случае отклонения обращения или заявки (заполняется в случае, если обращению или заявке присваивается статус «Отклонено»), указываются подробно причины такого отклонения, а также фиксируется дата и время перехода в статус «Отклонено». В случае, если обращение или заявка отклонены (отменены) самим Инициатором, то указывается дата и способ, которым от инициатора получено соответствующее уведомление. В случае невыполнения Подрядчиком регламентного времени реагирования или решения обращения (заявки) Заказчик вправе отозвать обращение и направить его Подрядчику повторно. При этом каждое отозванное обращение учитывается в Отчёте об оказанных услугах, как обращение с превышением времени реагирования или решения, но оплате не подлежит. В случае, если обращение (заявка) связано с некачественным выполнением Подрядчиком другой задачи, такое обращение решается в регламентное время, установленное Техническим заданием, при этом оплате такие обращения не подлежат, о чем указывается в Отчете об оказанных услугах в графе «Примечание» 4.3.1.3. Требования к регламенту оказания услуг Подрядчик должен руководствоваться Регламентом оказания услуг по технической поддержке Модуля СЦ. Регламент оказания услуг содержит следующую информацию: – порядок оказания услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Модуля СЦ; – порядок оказания услуги по решению инцидентов, связанных с работой ППО; – порядок оказания услуги адаптационного, конфигурационного и коррекционного сопровождения Модуля СЦ (в рамках действующих программных модулей и функциональностей); – порядок оказания услуги по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности. – Регламент содержит следующие формы заявок на оказание услуг: – форма заявки на оказание услуги по информационно-консультационной поддержке сотрудников Заказчика; – форма заявки на оказание услуги по решению инцидентов, связанных с работой ППО; – форма заявки на оказание услуг адаптационного, конфигурационного и коррекционного сопровождения Модуля СЦ (в рамках действующих программных модулей и функциональностей) (приоритет заявки определяется Заказчиком); – форма заявки на оказание услуги по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности 4.3.2. Требования к режиму обеспечения функционирования Модуля СЦ Режим оказания услуг определен в Приложении Б к настоящему ТЗ. По согласованию с Заказчиком, в целях недопущения остановки функционирования Модуля СЦ в период интенсивной работы пользователей в Модуле СЦ, отдельные услуги могут оказываться по специальному графику (в нерабочее время Подрядчика) в соответствии с заявками Заказчика 4.3.3. Требования к качеству оказываемых услуг Качество оказываемых услуг поддерживается Подрядчиком в соответствии с определяемыми данным ТЗ условиями и правилами и контролируется Заказчиком на постоянной основе, в том числе по соблюдению сроков исполнения и подтверждениям исполнения от инициаторов обращений и другим параметрам. По результатам выполнения работ по устранению инцидента должна быть устранена корневая причина инцидента с окончательным решением, устраняющим причину возникновения проблемы и исключающим вероятность повторного возникновения проблемы (инцидента). Время устранения корневых причин проблемы (инцидента) не должно составлять более 40 рабочих часов 4.3.4. Требования к документированию результатов оказываемых услуг Для обеспечения контроля оказываемых услуг по поддержке Модуля СЦ со стороны Заказчика, по окончании каждого отчетного периода по контракту в соответствии с календарным планом, Подрядчик обязан предоставить Заказчику Отчет об оказанных услугах. Отчет должен содержать детальную информацию об оказанных услугах с указанием даты выполненных мероприятий и приложением обосновывающих документов (заявок, запросов, требований) или ссылкой на такие документы, если они содержатся в Модуле СЦ. Информация о выполненных мероприятиях по заявкам должна быть сформирована на основании соответствующих записей СРО по каждому этапу исполнения Контракта. В случае оказания услуги адаптационного, конфигурационного и коррекционного сопровождения Модуля СЦ, должны быть предоставлены документы, подтверждающие выполнение требований п. 29.3 приказа ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации». Фактическое время реагирования и время решения по всем обращениям, поступившим в СРО, формируется в СРО по итогам отчетного периода в разделе «Отчеты». Фактическое время реагирования и время решения по обращениям учитывает суммарное время, затраченное на реагирование и, соответственно, на работу по обращению с момента назначения обращения специалисту Подрядчика или группе исполнителей, ответственным за оказание услуг технической поддержки 3 уровня от начала до завершения работ Подрядчиком. При этом принимается суммарное время нахождения заявки в соответствующих статусах заявки СРО на стороне Подрядчика 4.3.5. Требования к классификации обращений и заявок Обращения и заявки Заказчика классифицируются в соответствии с приоритетами и регламентными сроками, указанными в Приложении 2 к Регламенту. Регистрация обращений и заявок предусматривает создание новой записи в СРО с присвоением поступившему обращению или заявке (новой записи) уникального идентификатора. Запись в СРО должна содержать вопрос или проблему, которую требуется решить или оказать консультацию. Состав обязательной информации, которую должно содержать обращение или заявка, зафиксирован в Регламенте оказания Услуг. Если обращение или заявка автоматически зарегистрированы в СРО при отправке представителем Заказчика, Подрядчик проверяет корректность классификации обращения или заявки и может обратиться к Заказчику с просьбой корректировки, предоставив обоснования в соответствии с настоящей классификацией (Таблица 6) Таблица 6. Категории обращений и заявок Категория Примеры Запрос на обслуживание Подготовка SQL запроса к СУБД для решения прикладной задачи и д.р. – запрос на любое действие, не являющееся запросом информации и несовершенный на основе происшествия, прямо или косвенно влияющего на работу Модуля СЦ Консультация «Где взять / куда обратиться...?», «Как сделать / выполнить…», «Как это работает…?» - запрос, имеющий своей целью получение информационной поддержки Инцидент Разбор ошибок/сбоев и подготовка материалов (корректировочных релизов, инструкций) для Заказчика для устранения ошибок/сбоев, которые приводят к частичному и полному нарушению работоспособности всех или отдельных функций ППО. Подготовка изменения и материалов, необходимых для проведения аварийно-восстановительных работ для возобновления работоспособности Модуля СЦ ЗНИ Подготовка изменений, связанных с изменением, улучшением/оптимизацией Модуля СЦ и выводом новой модифицированной функциональности в штатном режиме. Подготовка изменений, связанных с модификацией существующих и/или реализация новых интеграционных механизмов для получения/обработки данных внешних систем. Подготовка изменений графического интерфейса по требованиям Заказчика. Перечень статусов обращений (заявок) приведен в пункте 3.3. Регламента оказания Услуг. Назначение обращению (заявке) статуса «Закрыто» осуществляется Заказчиком только после получения от инициатора обращения (заявки) подтверждения о его исполнении или нахождения обращения (заявки) в статусе «Выполнено» и отсутствия повторных вопросов/запросов по данному обращению (заявки) в течение 5 рабочих дней. Категории и статусы обращений (заявок) могут быть скорректированы в процессе оказания услуг исключительно по согласованию с Заказчиком 4.3.6. Требования к услугам технической поддержки 4.3.6.1. Требования к организации третьего уровня технической поддержки Основными задачами организации третьего уровня технической поддержки в рамках оказания услуг по технической поддержке Модуля СЦ являются организация эксплуатационной службы Подрядчика, проверка готовности технических и программных средств для обеспечения непрерывного функционирования ППО Модуля СЦ. Подрядчиком должны быть проведены организационно-штатные и подготовительные мероприятия (в т. ч. технические) в рамках организации технической поддержки Модуля СЦ. Подрядчик в течение 5 (пяти) рабочих дней с даты заключения Контракта должен: – определить и направить Заказчику документ «Перечень уполномоченных специалистов», содержащий контактную информацию (ФИО, должность, адрес рабочей электронной почты) лиц, ответственных за оказание услуг со стороны Подрядчика; – обеспечить подключение специалистов Подрядчика к Системе регистрации обращений (заявок) (СРО предоставляется Заказчиком) для оказания услуг; – согласовать с Заказчиком способ доступа Подрядчика к Модулю СЦ. Результат выполнения мероприятий фиксируется в Протоколе проверки результатов организационно-штатных и подготовительных мероприятий (см. Приложение Д к настоящему ТЗ) 4.3.6.2. Требования к услугам информационно-консультационной поддержки работников Заказчика и пользователей Модуля СЦ Услуги информационно-консультационной поддержки сотрудников Заказчика включают: – обработку обращений и заявок, поступивших от сотрудников Заказчика; – консультирование сотрудников Заказчика и пользователей Модуля СЦ; – актуализацию документации, и других материалов по работе с Модулем СЦ при необходимости. – консультирование и разработку рекомендаций по настройке Модуля СЦ (без изменения программного кода), включая изменение настроек функционирования; – консультации по вопросам использования, настройки и возможностям Модуля СЦ; – консультации по проведению превентивных мер для недопущения аварийных ситуаций в Модуле СЦ; – консультации по предварительной диагностике и локализации возникшей неисправности Модуля СЦ; – консультации по вопросам обеспечения информационной безопасности Модуля СЦ и настройки функций, обеспечивающих корректную работу программного обеспечения для совершения юридически значимых действий в Модуле СЦ; – другие вопросы, связанные с работой Модуля СЦ. 4.3.6.2.1. Требования к порядку оказания услуг информационно-консультационной поддержки работников Заказчика и пользователей Модуля СЦ Подрядчик выполняет консультирование сотрудников Заказчика и пользователей Модуля СЦ. Консультация может быть предоставлена по согласованным с представителем Заказчика каналам коммуникации с регистрацией результата консультации в СРО Подрядчиком. Детальный порядок оказания консультационных услуг определен в Регламенте оказания Услуг 4.3.6.3. Требования к услугам по решению инцидентов, связанных с работой ППО Подрядчик устраняет неисправности Модуля СЦ, связанные с работой ППО, выявленные в рамках оказания услуг согласно настоящему Техническому заданию, при этом в зону ответственности Подрядчика не входит устранение неисправностей, выявленных на стороне Заказчика и на стороне третьих лиц (провайдера связи, поставщика электропитания и т.д.). Первичная диагностика выявленной неисправности проводится на 1 и 2 уровнях технической поддержки и не входит в зону ответственности Подрядчика. Если при проведении первичной диагностики и попытке устранить неисправности на 1 и 2 уровнях технической поддержки, данную неисправность устранить не удалось и в процессе диагностики было выявлено, что проблема связана с работоспособностью ППО, обращение (заявка) назначается сотруднику Подрядчика, ответственному за оказание услуг технической поддержки 3 уровня. Инцидентами вне зоны ответственности Подрядчика являются: – работоспособность функциональности, выходящая за рамки текущей реализации функций в Модуле СЦ и/или являющаяся расширением требований Заказчика к функциям Модуля СЦ; – проведение профилактических и плановых работ, согласованных с Заказчиком; – нарушение работоспособности функций Модуля СЦ, вызванное проведением работ на стороне Заказчика 4.3.6.3.1. Требования к порядку оказания услуги по решению инцидентов, связанных с работой ППО При поступлении от Заказчика обращения (заявки), являющегося неисправностью в работе Модуля СЦ (инцидентом), Исполнитель реагирует на инцидент в СРО в срок не более 30 минут с момента поступления. В случае необходимости, для решения инцидента ответственный специалист должен связаться с инициатором обращения (заявки) для уточнения условий воспроизведения проблемы или для получения дополнительных сведений. После получения необходимых сведений от инициатора обращения (заявки) ответственный специалист производит диагностику с целью выявления причины инцидента и возможных путей устранения. В случае, если инцидент невозможно решить без получения дополнительных сведений от инициатора, и не удается связаться с инициатором в течение пяти рабочих дней, обращение (заявка) отклоняется в связи с недостатком данных для его решения, Заказчику направляется уведомление об отклонении обращения (заявки). Время, в течение которого невозможно связаться с инициатором, вычитается из общего времени обработки обращения (заявки). Все попытки связаться с инициатором должны фиксироваться с указанием даты и времени попытки, используемого способа связи (номер телефона, адрес электронной почты) и результата попытки (не удалось дозвониться, абонент недоступен, и т.д.) Факт и время решения инцидента должны быть зафиксированы и отражены в СРО. В случае, если причиной сбоя в работе Модуля СЦ является выход из строя аппаратного обеспечения или неработоспособность смежной информационной системы, время работы над инцидентом приостанавливается до момента устранения неисправности. В ходе решения инцидентов могут быть выявлены дефекты ППО Модуля СЦ. В случае обнаружения дефектов ППО, Подрядчик информирует об этом Заказчика. Исполнитель может быть привлечен к проверке результата устранения дефекта по инициативе Заказчика. Приоритеты инцидентов приведены в Приложении Б к ТЗ. Детальный порядок оказания услуги по решению инцидентов, связанных с работой ППО Модуля СЦ определен в Регламенте оказания Услуг 4.3.6.4. Требования к услугам адаптационного, конфигурационного и коррекционного сопровождения и доработки Модуля СЦ (в рамках действующих программных модулей и функциональностей) Услуги адаптационного, конфигурационного и коррекционного сопровождения и доработки Модуля СЦ включают: – управление изменениями и адаптация функций Модуля СЦ; – изменение настроек функционирования Модуля СЦ; – внесение изменений и/или модификаций Модуля СЦ (в рамках действующих программных модулей и функциональностей), направленных на улучшение их работоспособности и функциональных возможностей; – подготовка и передача Заказчику SQL запросов в СУБД для получения агрегированной информации из Модуля СЦ, которую невозможно получить с использованием графического пользовательского интерфейса; – адаптация модулей интеграций со смежными информационными системами 4.3.6.4.2. Требования к изменению настроек функционирования Изменение настроек функционирования может проводиться в рамках допустимых пределов изменения функционирования, заложенных в архитектуру Модуля СЦ. Изменение настроек функционирования включает в себя изменение данных и справочников, изменение форм документов, формируемых Модулем СЦ, изменение и настройку форматов и версий передачи данных в смежные системы. Доработка программного кода Модуля СЦ может допускаться (в случае необходимости) при выполнении работ по адаптации функций Модуля СЦ в части изменения формата передачи данных в смежные информационные системы при условии соблюдения требований пункта 29.3 приказа ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации» 4.3.6.5. Требования к услугам по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности По запросу Заказчика Подрядчик должен провести работу по приведению ППО в соответствие с требованиями по обеспечению информационной безопасности. Критичность уязвимости оценивается в соответствии в соответствии с Методическим документом ФСТЭК России «Методика оценки уровня критичности уязвимостей программных, программно-аппаратных средств» (утвержден ФСТЭК России 30.06.2025), а также с учетом ГОСТ 56545-2015 и международными стандартами (CVSS 3.0 и выше), и задает необходимый срок устранения. В процессе проведения Заказчиком обследования Модуля СЦ и выявления уязвимостей в ППО, связанных с исходным кодом Модуля СЦ и/или используемыми компонентами (библиотеками), Заказчик направляет Подрядчику обращение (заявку) на устранение, с указанием критичности и срочности принятия мер по устранению в СРО. Подрядчик при оказании услуг по обновлению или устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности должен: – провести анализ уязвимостей и связанных с ними исходным кодом и/или используемыми компонентами (библиотеками); – выработать варианты устранения указанных уязвимостей и согласовать с Заказчиком их реализацию; – своевременно внести изменения в исходный код Модуля СЦ и/или используемые компоненты (библиотеки) и подготовить соответствующее обновление; – провести обновление Модуля СЦ в тестовом контуре Заказчика и проинформировать Заказчика о готовности проведения тестирования; – протестировать успешность обновления или устранения уязвимостей в ППО и корректность функционирования Модуля СЦ на тестовом контуре, совместно с Заказчиком; – при невозможности незамедлительного устранения уязвимости приоритетов «Критический» и «Высокий» Подрядчик обязан предоставить исчерпывающий список причин и согласовать план достаточных компенсирующих мер с ответственными сотрудниками Заказчика. Результат внесения изменений отображается в соответствующей записи в СРО и в составе Отчета об оказанных услугах 4.3.6.5.1. Требования к порядку оказания услуг по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности Подрядчик в соответствии с приоритетами обращений и контрольными сроками исполнения (см. Приложение Б к ТЗ) оценивает техническую возможность и сроки устранения уязвимостей, и реализацию обновления Модуля СЦ. По итогу проведения оценки Подрядчик направляет в заявке СРО Заказчику заключение о возможности устранения уязвимостей и/или обновления в ППО и согласует с Заказчиком проведение данных работ При проведении работ по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности необходимо выполнить следующее: – Заказчику сформировать заявку на устранение (обновление) в СРО с полным списком обнаруженных уязвимостей и планируемыми работами; – согласовать в рабочем порядке время начала и завершения работ, перечень работ, выполняемых в рамках обновления или устранения уязвимостей в ППО с Заказчиком; – оповестить Заказчика о начале проведения работ на тестовом контуре; – провести работы по обновлению или устранению уязвимостей в ППО на тестовом контуре Модуля СЦ в установленные сроки; – протестировать выполнение работ в тестовом контуре и проинформировать Заказчика о готовности переноса ППО на продуктивный контур; – силами Заказчика обновить продуктивный контур Модуля СЦ, в соответствии с планом устранения и выполненными работами; – совместно с Заказчиком проверить корректность функционирования Модуля СЦ и устранения уязвимостей в продуктивном контуре Модуля СЦ по результатам обновления; – при необходимости актуализировать документацию (описание архитектуры, анкеты постановки на мониторинг и иные документы). Любые изменения в части обновления или устранения уязвимостей в ППО на промышленном контуре Модуля СЦ должны применяться только в случае успешного проведения аналогичных работ на тестовом контуре. Детальный порядок оказания услуги по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности определен в Регламенте оказания Услуг 4.4. Требования к видам обеспечения 4.4.1. Требования к лингвистическому обеспечению Документация на Модуль СЦ должна разрабатываться на русском языке. Взаимодействие пользователей с Модулем СЦ посредством графического интерфейса должно происходить на русском языке за исключением сообщений, зависящих от настроек системного программного обеспечения, установленного на рабочих местах пользователей. При разработке программных решений Модуля СЦ должно быть предусмотрено использование языков программирования высокого уровня, приведенных в Таблице 7. Таблица 7. Языки и средства разработки, специального программного обеспечения Модуля СЦ Категория Наименование Назначение Языки программирования Kotlin Разработка серверной логики и сервисов (backend) JavaScript / TypeScript Разработка клиентской части (frontend) Python Разработка скриптов интеграции, обработки данных и автоматизации Фреймворки и библиотеки Vue.JS Разработка пользовательских интерфейсов (веб-интерфейсы компонентов визуализации и отчетности) React Разработка пользовательских интерфейсов (при необходимости создания сложных интерактивных компонентов) Решения по лингвистическому обеспечению, включая перечень используемых языков программирования, должны быть согласованы с Заказчиком на этапе технического проектирования 4.4.2. Требования к математическому обеспечению Требования к математическому обеспечению не предъявляются. 4.4.3. Требования к метрологическому обеспечению Требования к метрологическому обеспечению не предъявляются. 4.4.4. Требования к организационному обеспечению Требования к организационному обеспечению не предъявляются. 4.4.5. Требования к методическому обеспечению Задачи методического обеспечения Модуля СЦ должны быть обеспечены за счет использования технологических и методических документов касающихся вопросов функционирования транспортного комплекса и разработки и эксплуатации ПО. 4.4.6. Требования к информационному обеспечению Состав, структура и способы организации информационного обеспечения в Модуле СЦ должны быть определены на этапе технического проектирования. Факты информационного обмена с внешними системами должны фиксироваться в соответствующем журнале 4.4.7. Требования к программному обеспечению Общесистемное ПО, используемое в составе Модуля СЦ, должно быть зарегистрировано в Едином реестре российских программ для электронных вычислительных машин и баз данных и соответствовать рекомендованным показателям эффективности и соответствующим им значениям индикаторов эффективности перехода подведомственных организаций на использование российского ПО, заданных Приказом Минцифры России от 18.01.2023 № 21 «Об утверждении методических рекомендаций по переходу на использование российского программного обеспечения, в том числе на значимых объектах критической информационной инфраструктуры Российской Федерации, и о реализации мер, направленных на ускоренный переход органов государственной власти и организаций на использование российского программного обеспечения в Российской Федерации». Применяемое в системе программное обеспечение должно соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации, постановления Правительства Российской Федерации от 23 декабря 2024 г. № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц» Прикладное программное обеспечение должно отвечать следующим требованиям: – совместимость программных продуктов в части используемых технических средств, системного программного обеспечения и общесистемной инфраструктуры в пределах требований к техническому обеспечению, а также их информационная совместимость в пределах требований к информационному обмену; – обеспечение трехуровневой архитектуры с разделением на уровень хранения данных (сервер БД), уровень бизнес-логики (сервер приложений) и уровень представления ( 4.4.7.1. Требования к инструментам разработки и процессу контроля версий программного обеспечения 4.4.7.1.1. Система контроля версий Для управления исходным кодом должна использоваться система контроля версий кода, развернутая в инфраструктуре Заказчика. 4.4.7.1.2. Правила именования веток Имя ветки должно соответствовать следующему формату: / / Категории веток: ? feature/ — разработка новой функциональности, а также рефакторинг или удаление существующей; ? fix/ — исправление ошибок; ? hotfix/ — срочные исправления, применяемые в обход стандартного процесса разработки; ? test/ — для проведения экспериментов, не влияющих на основную разработку. Идентификатор задачи: после категории указывается ссылка на задачу (issue) в системе контроля версий кода. Описание: добавляется краткое описание решаемой задачи в формате kebab-case (слова разделяются дефисами, например, add-user-auth). Примеры именования веток: ? feature/#123/add-payment-integration; ? fix/#45/correct-calculation-logic; ? hotfix/#67/urgent-database-connection-patch. 4.4.7.1.3. Правила именования коммитов Сообщение коммита должно соответствовать соглашению Conventional Commits и состоять из категории и описания: : ? fix — исправление ошибки. Примеры сообщений коммитов: ? feat: добавление формы регистрации пользователя; ? fix: исправление ошибки валидации email-адреса; ? refactor: оптимизация алгоритма сортировки данных; ? chore: обновление версий в файле dependencies. 4.4.7.1.4. Модель ветвления В процессе разработки используются следующие основные ветви: ? main / master — стабильная ветка, содержит только код, прошедший полное тестирование и развернутый в продуктивных контурах; ? dev — ветка для интеграции завершенных задач, предназначенная для сборки и тестирования в тестовых средах. Попадание кода в main осуществляется только через Merge Request (MR) из dev 4.4.7.1.5. Требования к используемым зависимостям (библиотекам) Все внешние зависимости проекта должны быть зафиксированы с указанием точных версий. Для контроля версий зависимостей в репозиторий обязательно должны быть включены следующие файлы: · Для JavaScript: package-lock.json или yarn.lock; · Для Python: requirements.txt (с зафиксированными версиями) или Pipfile.lock; · Для Go: go.mod и go.sum; Загрузка всех зависимостей должна производиться исключительно через внутренний прокси-репозиторий Заказчика, настроенный в соответствующем системе менеджере пакетов. Запрещается: · Использование плавающих версий (например, ^1.2.3, ~4.5.0, latest); · Использование библиотек, содержащих критические уязвимости, в том числе зарегистрированные в реестре CVE (Common Vulnerabilities and Exposures). 4.4.7.1.6. Требования к процессу непрерывной интеграции (CI) Сборка программного обеспечения, включая этапы компиляции, тестирования и анализа кода, должна выполняться исключительно в инфраструктуре непрерывной интеграции Заказчика. 4.4.7.1.7. Требования к хранению артефактов сборки Все артефакты сборки (результирующие пакеты, Docker-образы и т.д.) подлежат обязательному хранению в предназначенной для этого инфраструктуре Заказчика (артефакторий). Запрещается размещение финальных артефактов сборки на сторонних ресурсах 4.4.8. Требования к техническому обеспечению Количество серверов, подключаемых и настраиваемых сервисов, их параметров, схемы соединений и настройки межсетевого взаимодействия должны быть согласованы с Заказчиком на этапе № 1 Техническое проектирование. Доступ к комплексу технических средств предоставляется Заказчиком по письменному запросу Подрядчика. Применяемые в Системе программно-аппаратные и аппаратные комплексы должны соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации», требованиям Постановления Правительства Российской Федерации от 23 декабря 2024 г. № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц». Модуль СЦ, работающий в составе АСУ ТК, развернут на вычислительных мощностях ГЦОД СИЦ Минтранса России 4.5. Общие технические требования 4.5.1. Требования к численности и квалификации персонала и пользователей Модуля СЦ Программное обеспечение Модуля СЦ не должно требовать изменения штатной численности персонала Заказчика. Программное обеспечение Модуля СЦ не должно требовать наличия у пользователей дополнительной квалификации в сфере информационных технологий, кроме базовых знаний в обращении с персональным компьютером, базовых навыков работы в интернет-обозревателях и знаний о Модуле СЦ в объеме документов Руководство пользователя, Руководство администратора 4.5.2. Требования к режимам функционирования Модуля СЦ Модуль СЦ должен предусматривать наличие следующих режимов работы: – штатный; – регламентный (профилактический); – аварийный. Основным режимом функционирования является штатный. В штатном режиме все компоненты корректно и полностью выполняют свои функции. Перерывов в работе как Модуля СЦ в целом, так и одного, либо нескольких компонентов не предусмотрено. Режим регламентного (профилактического) обслуживания предназначен для проведения работ по обновлению и техническому обслуживанию компонентов Модуля СЦ, а также резервному копированию данных. При работе в данном режиме допускаются перерывы в работе Модуля СЦ с предварительным информированием пользователей. Состав процедур по регламентному обслуживанию Модуля СЦ и их периодичность определяются Подрядчиком в процессе выполнения работ по созданию Модуля СЦ. В режиме регламентного (профилактического) обслуживания Модуль СЦ может функционировать с частичным ограничением своих функциональных возможностей, либо без ограничения, но со снижением показателей надежности и производительности. Перевод в данный режим работы должен осуществляться сразу после начала выполнения любой операции, отнесенной к этому режиму, с последующим возвратом в штатный режим функционирования сразу после ее завершения. Перевод в указанный режим должен осуществляться при возникновении необходимости проведения работ по обновлению и техническому обслуживанию компонентов Модуля СЦ, а также резервному копированию данных с условием предварительного оповещения пользователей. Аварийный режим функционирования характеризуется отказом одной или нескольких подсистем, вызванных выходом из строя аппаратного и/или программного обеспечения, а также в случае временной неработоспособности каналов связи между серверами. В аварийном режиме осуществляется поиск неисправностей и проведение работ по их устранению. Перевод в аварийный режим должен осуществляться при возникновении сбоев, аварий и прочих незапланированных воздействий, сразу после наступления одной или нескольких аварийных ситуаций, с последующим возвратом в штатный режим функционирования сразу после окончания восстановительных работ. ПО Модуля СЦ должно обладать надежностью, обеспечивающей работу пользователей в произвольном режиме и оперативное восстановление работоспособности при сбоях. В целях обеспечения надежного функционирования ПО должно предусматривать: – сохранение целостности данных при нештатном завершении работы компонентов Модуля СЦ; – сохранение работоспособности программного обеспечения при некорректных действиях пользователя; – резервное копирование базы данных Модуля СЦ. – время восстановления работоспособности Модуля СЦ после отказа не более 4 часов. – отказоустойчивость на уровне 99% при единовременной количестве не менее 200 пользовательских сессий в Модуле СЦ. Указанные характеристики приведены без учета характеристик надежности инфраструктуры и времени передачи информации по каналам связи. При возникновении сбоев в аппаратном обеспечении, включая аварийное отключение электропитания, Модуль СЦ должен автоматически восстанавливать свою работоспособность (не требовать перенастройки) после устранения сбоев и корректного перезапуска аппаратного обеспечения 4.5.5. Требования к информационной безопасности Работы по защите информации/информационной безопасности, не включенные в состав настоящего раздела, требуемые в соответствии с требованиями постановления Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации», а также нормативно правовых актов в области защиты персональных данных и обеспечения безопасности объектов критической информационной инфраструктуры, будут проведены в рамках исполнения отдельного контракта, заключенного по результатам отдельной закупочной процедуры (не является частью данного ТЗ), включающего: – определение актуальных угроз безопасности информации и актуализация модели угроз безопасности информации (при необходимости); – выполнение требований о согласовании технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России в установленном порядке; – выполнение требований по устранению Подрядчиком замечаний и недостатков, в случае их выявления при согласовании Заказчиком технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России; – выполнение требований к классу защищенности ГИС, уровню защищенности персональных данных и категории значимости объекта КИИ РФ, установленных для Головного центра обработки данных ФГБУ «СИЦ Минтранса России» (далее – ГЦОД); – определение перечня объектов защиты информационной системы; – описание (актуализированных) требований к системе защиты информации, а также к мерам защиты информации информационной системы в зависимости от установленных классов защищенности, уровня защищенности персональных данных и категории значимости объектов КИИ РФ (приказы ФСТЭК России № 21, 117, 239); – выполнение требований к мерам по защите ГИС от атак, направленных на отказ в обслуживании, в соответствии с пунктами 30, 34, 59, 63 Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений, утвержденных приказом ФСТЭК России от 11.04.2025 № 117; – описание (актуализированных) требований по защите информации, подлежащих реализации в информационно телекоммуникационной инфраструктуре ГЦОД; – выполнение требований о применении сертифицированных средств защиты информации, включая их классы защиты и уровни доверия; – выполнение требований о запрете использования с 01.01.2025 органами (организациями) средств защиты информации странами происхождения, которых являются иностранные государства в соответствии с пунктом 6 Указа Президента Российской Федерации от 01.05.2022 № 250; – выполнение требований по обеспечению непрерывного взаимодействия с ГосСОПКА в установленном порядке; – выполнение требований по обеспечению в автоматизированном режиме с Национальной системой противодействия DDoS-атакам (НСПА) Центра мониторинга и управления сетью связи общего пользования ФГУП «ГРЧЦ» в рамках реализации мер по защите ГИС от атак, направленных на отказ в обслуживании; – детализированные требования к составу и содержанию работ по аттестации, а также к их результатам в соответствии с пунктами 13, 15 и 16 требований приказа ФСТЭК России от 29.04.2021 № 77 «Об утверждении Порядка организации и проведения работ по аттестации объектов информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну» 4.5.5.1. Требования к безопасности исходного кода Процесс разработки исходного кода должен соответствовать требованиям законодательства, нормативным правовым актам Российской Федерации, приказу ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по безопасности значимых объектов критической информационной инфраструктуры Российской Федерации», а также учитывать отраслевые практики безопасной разработки. Подрядчик должен предоставить Заказчику Руководство по безопасной разработке программного обеспечения (далее – Руководство), применяемое при разработке исходного кода Модуля СЦ. Руководство должно содержать: · описание процесса безопасной разработки и ролевой модели, отражающей зоны ответственности сотрудников Подрядчика; · описание процессов моделирования, оценки и формирования мер предотвращения угроз, применяемых Подрядчиком; · описание методик, применяемых Подрядчиком при разработке исходного кода (правила написания кода); · описание методик, периодичности проведения и инструментария статического, динамического, композитного и фаззинг тестирования исходного кода, включающего критерии отбора релизных версий ПО, применяемые Подрядчиком в процессе разработки; · описание механизмов безопасности в процессе сборки и доставки (безопасность образов, безопасность секретов, безопасность окружения и сборочной среды), применяемые Подрядчиком; · утвержденные шаблоны отчетной документации (в том числе акты), в соответствии с которыми Заказчик принимает результаты проверок (артефакты сборочного процесса), проведенных Подрядчиком; · описание процедур отслеживания и исправления обнаруженных ошибок и уязвимостей программного обеспечения; · описание способов и сроков доведения Подрядчиком до Заказчика информации об уязвимостях программного обеспечения, о компенсирующих мерах по защите информации или ограничениях по применению программного обеспечения, способов получения пользователями программного обеспечения его обновлений, проверки их целостности и подлинности Подрядчик должен обеспечить реализацию и проведение внутренних проверок мер по разработке безопасного ПО, приведенных в Руководстве. Подрядчик должен провести анализ угроз безопасности информации программного обеспечения в соответствии с ГОСТ 58412-2019 «Защита информации. Разработка безопасного программного обеспечения. Угрозы безопасности информации при разработке программного обеспечения». Подрядчик должен провести испытания по выявлению уязвимостей в программном обеспечении Системы: · проведение статического анализа исходного кода программы; · проведение динамического анализа исходного кода программы; · проведение композитного анализа исходного кода и образов программы; · проведение фаззинг-тестирования программы, направленного на выявление в ней уязвимостей. Испытания по выявлению уязвимостей в программном обеспечении Системы должны быть проведены в рамках: · предварительных испытаний; · опытной эксплуатации; · приемочных испытаний По результатам анализа угроз безопасности информации программного обеспечения и испытаний по выявлению уязвимостей в программном обеспечении Системы должна быть предоставлена отчетная документация по формам, утвержденным в Руководстве, и артефакты сборочной среды, подтверждающие проведение испытаний по выявлению уязвимостей в программном обеспечении Систем. Уязвимости подлежат устранению в сроки, обозначенные Заказчиком. В случае обнаружения уязвимого компонента Подрядчик должен заменить/обновить библиотеки. В случае, если уязвимость не подлежит исправлению на программном уровне, Подрядчик должен разработать меры предотвращения угроз безопасности, в том числе правила безопасности для наложенных средств защиты, рекомендации по безопасной настройке конфигурации для устранения потенциальных уязвимостей и снижения рисков информационной безопасности. Уязвимости, найденные ФСБ России, ФСТЭК России, Минцифры России, Роскомнадзором в ходе исполнения Контракта, а также в течение гарантийного периода, должны быть устранены Подрядчиком за свой счет в сроки, согласованные с Заказчиком 4.5.6. Требования к эргономике и технической эстетике Взаимодействие пользователей с Модулем СЦ должно осуществляться посредством визуального графического интерфейса. Ввод-вывод данных, прием управляющих команд и отображение результатов их исполнения должны выполняться в интерактивном режиме. Интерфейс должен быть рассчитан на преимущественное использование манипулятора типа «мышь», то есть управление Модулем СЦ должно осуществляться с помощью набора экранных меню, кнопок, значков и т. п. элементов. Клавиатурный режим ввода должен использоваться главным образом при заполнении и/или редактировании текстовых и числовых полей экранных форм. Все надписи экранных форм, а также сообщения, выдаваемые пользователю (кроме системных сообщений), должны быть на русском языке. Модуль СЦ должен обеспечивать проверку вводимых пользователем данных и предупреждать о некорректно введённых значениях Экранные формы должны проектироваться с учетом требований унификации: – все экранные формы пользовательского интерфейса должны быть выполнены в едином графическом дизайне, с одинаковым расположением основных элементов управления и навигации; – для обозначения сходных операций должны использоваться сходные графические элементы, кнопки и другие управляющие (навигационные) элементы. Термины, используемые для обозначения типовых операций, а также последовательности действий пользователя при их выполнении должны быть унифицированы; – внешнее поведение сходных элементов интерфейса (реакция на наведение указателя «мыши», переключение фокуса, нажатие кнопки) должно реализовываться одинаково. Структура размещения информации и представление этой структуры в Модуле СЦ должны соответствовать следующим требованиям: – пункты меню в пользовательском веб-интерфейсе должны быть сгруппированы в соответствии с тематикой информации, функциональными задачами и технологией работы; – каждому пункту меню должна соответствовать только одна выполняемая функция; – при совершении пользователями ошибочных действий должны выдаваться сообщения об ошибках. Эскизы визуального оформления компонента «Интерактивная карта» представлены в Приложении А. 4.5.7. Требования по сохранности информации при авариях В случае возникновения аварии или сбоя в процессе выполнения пользовательских задач должно быть обеспечено восстановление баз данных до состояния на момент последней завершенной Модулем СЦ транзакции, и структуры файлового хранилища. Все аварийные ситуации должны обрабатываться программно с выдачей соответствующих сообщений, с корректной обработкой ситуации (завершение транзакций, закрытие файлов и т.п.), без потери обрабатываемой информации. В Модуле СЦ должны быть предусмотрены меры, обеспечивающие целостность данных в случае отказа программного обеспечения или аппаратных средств, исключая случаи физического уничтожения носителя или нарушения функциональности носителя, операционной системы или СУБД по вине их производителя либо обслуживающего персонала. Используемые аппаратные и системные платформы должны обеспечивать сохранность и целостность информации в Модуле СЦ при полном или частичном отключении электропитания, аварии сетей телекоммуникации, полном или частичном отказе технических средств Модуля СЦ. Технические решения должны обеспечивать сохранность информации в случае возникновения следующих событий (аварий, отказов и т.п.): – отказ аппаратного обеспечения на сервере; – отключение питания на сервере; – отказ аппаратного обеспечения на рабочей станции; – отключение питания на рабочей станции администратора; – отказ линий связи, в том числе при осуществлении обмена данными 4.5.8. Требования к защите от влияния внешних воздействий Требования к защите от влияния внешних воздействий не предъявляются 4.5.9. Требования к патентной чистоте и патентоспособности 4.5.9.1. Исключительные права на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, базы данных, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, принадлежат Российской Федерации в лице Заказчика. Право собственности на результаты работ, отчетные документы и материалы, полученные в ходе выполнения работ по Контракту, принадлежат Российской Федерации в лице Заказчика и считаются переданными с момента подписания Сторонами Акта сдачи-приемки выполненных работ. Разработанное программное обеспечение поставляется вместе с исходными кодами. 4.5.9.2. Все проектные и технические решения должны отвечать требованиям четвертой части Гражданского кодекса Российской Федерации. Результаты Работ должны быть свободными от возможности предъявления любых прав и притязаний третьих лиц, основанных на промышленной, интеллектуальной или другой собственности. 4.5.9.3 Результаты выполненных Работ не должны повлечь необходимость осуществления Заказчиком закупок программного обеспечения (как исключительных, так и неисключительных прав) для обеспечения функциональности Системы в соответствии с Техническим заданием. При выполнении работ Подрядчик должен использовать только объекты интеллектуальной собственности, права на которые приобретены (получены) и используются без нарушений прав на интеллектуальную собственность третьих лиц или предоставлены Заказчиком 4.5.9.12. Передача Заказчику комплекта документов, материалов и сведений, предусмотренных нормативными правовыми актами Российской Федерации в сфере информационных технологий, защиты информации, правовой защиты интересов государства в области интеллектуальной собственности, включая документы, подтверждающие отказ авторов (разработчиков) от исключительных прав на передаваемые объекты интеллектуальной собственности в пользу Подрядчика, с проектами заявок на государственную регистрацию в установленном порядке прав Заказчика на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, базы данных, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, осуществляется Подрядчиком в составе отчетной документации, предусмотренной условиями Контракта. 4.5.9.13. По результатам выполнения работ по развитию системы должны быть подготовлены материалы для регистрации доработанной версии Системы (объекта учета) в НФАП в соответствии с требованиями постановления Правительства Российской Федерации от 30 января 2013?г. №?62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин» (с изменениями и дополнениями) в части обязательности размещения результатов работ в национальном фонде алгоритмов и программ для электронных вычислительных машин 4.5.10. Требования по стандартизации и унификации К Модулю СЦ предъявляются следующие требования в части стандартизации и унификации: – работы по развитию Модуля СЦ должны производиться в соответствии с действующими стандартами и нормами Российской Федерации; – при создании и модернизации элементов Модуля СЦ следует руководствоваться действующими в Российской Федерации национальными стандартами и другими нормативно-техническими документами; – используемые оборудование и материалы, подлежащие обязательной сертификации, должны иметь соответствующие сертификаты; – ПО Модуля СЦ должно проектироваться и разрабатываться с учётом обеспечения требований унификации; – применяемые при создании Модуля СЦ технические (форматы данных, протоколы передачи и прочие) и организационные (регламенты, требования, инструкции) решения должны быть доступны и документированы в виде, достаточном для независимой (без обращения к Подрядчику) реализации третьими сторонами; – термины, обозначения и наименования, используемые в ПО, должны быть стандартизованы и унифицированы, выполнены на русском языке; – взаимодействие элементов и их внешнее поведение должно быть реализовано одинаково и производиться по единым правилам 4.5.11. Требования к показателям назначения 4.5.11.1. Требования к показателям назначения мероприятий по развитию Модуля СЦ В рамках выполнения работ по развитию Модуля СЦ, предусмотренных ТЗ, показатель назначения «Количество пользователей» должен соответствовать значениям, приведенным в данном разделе. Пояснения по показателям, связанным с количеством пользователей, приведены в Таблице 8. Таблица 8. Определения показателей, связанных с количеством пользователей в Модуле СЦ № Показатель Определение Расчетное количество пользователей Количество пользователей, работу которых должен обеспечить Модуль СЦ к моменту сдачи работ по Контракту с учетом достижения всех показателей назначения Расчетное количество одновременно работающих пользователей Количество одновременно работающих пользователей, работу которых должен обеспечивать Модуль СЦ к моменту сдачи работ по Контракту с учетом достижения всех показателей назначения Значения показателей количества пользователей, достижение которых необходимо обеспечить, представлено в Таблице 9 Таблица 9. Значения показателей количества пользователей № Показатель Значение 1. Расчетное количество пользователей 1 000 2. Расчетное среднее количество одновременно работающих пользователей 200 Развитие Модуля СЦ должно быть направлено на достижение следующего эффекта (показателя), подставленного в мероприятии 103.002 «Информационно-аналитическая система регулирования на транспорте (АСУ ТК)» ВПЦТ Минтранса России: Выполнение работ по развитию Модуля СЦ предусмотрено мероприятием по развитию АСУ ТК, приведенном в ВПЦТ Минтранса России на 2026-2028 гг: № 103.002 «АСУ ТК» в составе ИТ расхода 103.26.000005 «Развитие предусматривает реализацию ОКР и эффектов, приведенных в Таблице 10. Таблица 10. ОКР и эффекты, приведенные в ВПЦТ Минтранса России на 2026 г. № ОКР Дата ОКР Эффекты 1 Обеспечено информационное взаимодействие с Минобороны России о происшествиях на транспортных объектах 25.12.2026 Сокращено время сбора и передачи сведений для Минобороны России о ЧС и НС на транспорте с 120 до 10 минут 2 Обеспечена автоматизация формирования отчетов о нештатных ситуациях на транспорте, в том числе по данным внешних систем 25.12.2026 Сокращено время на подготовку отчетов о нештатных ситуациях на транспорте с 20 до 5 минут Реализация остальных ОКР не является предметом данного ТЗ и проводится в рамках отдельного технического задания. 4.5.11.2. Требования к показателям назначения мероприятий по эксплуатации Модуля СЦ. Работы по эксплуатации Модуля СЦ не должны обеспечивать режимы функционирования Модуля СЦ, приведенные в разделе 4.5.2 данного ТЗ 5. СОСТАВ И СОДЕРЖАНИЕ РАБОТ ПО РАЗВИТИЮ И ТЕХНИЧЕСКОЙ ПОДДЕРЖКЕ МОДУЛЯ СЦ (КАЛЕНДАРНЫЙ ПЛАН) 1 Техническое проектирование Сопроводительным письмом предоставляются Заказчику: · Технический проект, включая следующие документы: – Ведомость технического проекта; – Ведомость машинных носителей информации – Пояснительная записка; – Описание информационного обеспечения системы; – Описание автоматизируемых функций; – Схема функциональной структуры; – Описание организации информационной базы; – Описание программного обеспечения; · Макеты экранных форм компонента «Интерактивная карта»; · Руководство по безопасной разработке программного обеспечения; · Документ о приемке Начало: с даты заключения контракта Окончание: не позднее 31.07.2026 Значение характеристики не может изменяться участником закупки 2 Услуги по технической поддержке Модуля СЦ (с даты заключения контракта по 10.09.2026) По окончании оказания Услуг сопроводительным письмом предоставляются Заказчику: – Отчет об оказанных Услугах по технической поддержке; – Актуальные на дату окончания оказания Услуг по данному этапу исходные коды прикладного ПО на электронном носителе (в случае внесения изменений); – Инструкция по сборке и развертыванию (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство пользователя (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство администратора (в случае внесения изменений); – Документ о приемке Начало: с даты заключения контракта Окончание: не позднее 10.09.2026 3 Разработка программного обеспечения (1 очередь, пп. 4.2.1, 4.2.6 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ; – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 1 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 1 очереди; – Руководство по резервному копированию; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 16.09.2026 4 Разработка программного обеспечения (2 очередь, пп. 4.2.3, 4.2.4 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ. – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 2 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 2 очереди; – Руководство по резервному копированию; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 25.09.2026 Работы по развитию Системы (за исключением этапов проведения опытной эксплуатации и услуг по технической поддержке) могут быть выполнены досрочно. При досрочном выполнении работ (этапов работ) Подрядчик в письменной форме уведомляет Заказчика о готовности представить для приемки результаты проведения работ в соответствии с требованиями Контракта. Подрядчик также вправе досрочно приступать к работам в рамках очередного этапа при наличии технической, организационной готовности - при условии получения соответствующего согласования Заказчиком. Сдача-приемка результатов выполненных работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная, техническая документация, а также результаты Работ по каждому этапу предоставляется Заказчику в порядке, предусмотренном Контрактом и настоящим Техническим заданием, до размещения Подрядчиком в Единой информационной системе в сфере закупок документа о приемке. Документ о приемке размещается в ЕИС по каждому этапу в соответствии с условиями Контракта. Согласование документов осуществляется в электронном виде посредством переписки с адресов электронной почты Заказчика и Подрядчика, указанных в контракте. Сдача-приемка результатов выполненных работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная техническая документация, а также результаты работ предоставляются Заказчику в порядке, предусмотренном Контрактом и ТЗ, до размещения Подрядчиком в ЕИС документа о приемке. Документ о приемке размещается в ЕИС по каждому этапу в соответствии с условиями Контракта. Этапы выполнения работ по развитию Модуля СЦ приведены в Таблице 11. Таблица 11. Этапы выполнения работ по развитию Модуля СЦ. № этапа Наименование этапа Результат (отчетная документация) Срок исполнения этапа 5 Разработка программного обеспечения (3 очередь, пп. 4.2.2, 4.2.5 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ; – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 3 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 3 очереди; – Руководство по резервному копированию; – Описание ролевой модели; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 09.10.2026 6 Опытная эксплуатация (1 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акт о завершении опытной эксплуатации 1 очереди; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке 17.09.2026 Окончание: не позднее 26.10.2026 7 Опытная эксплуатация (2 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акт о завершении опытной эксплуатации 2 очереди; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке 26.09.2026 Окончание: не позднее 26.10.2026 8 Опытная эксплуатация (3 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Акт о завершении опытной эксплуатации 3 очереди; – Документ о приемке Начало: с 10.10.2026 Окончание: не позднее 26.10.2026 9 Приемочные испытания Сопроводительным письмом предоставляются Заказчику: – Программа и методика приёмочных испытаний; – Протокол приемочных испытаний; – Исходные коды и дистрибутивы на электронном носителе (при условии внесения изменений, с учетом доработок по результатам опытной эксплуатации и проведенных испытаний); – Комплект рабочей документации на Модуль СЦ (при условии внесения изменений, с учетом доработок по результатам опытной эксплуатации и проведенных испытаний); – Акт приемки Системы в эксплуатацию; – Акт приемки-передачи исключительных прав на объект; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке; – Документы в соответствии с разделом 4.5.9 ТЗ; – Обеспечение гарантийных обязательств Начало: с 27.10.2026 Окончание: не позднее 10.11.2026 10 Услуги по технической поддержке Модуля СЦ (с 11.09.2026 по 15.12.2026) По окончании оказания Услуг сопроводительным письмом предоставляются Заказчику: – Отчет об оказанных Услугах по технической поддержке; – Актуальные на дату окончания оказания Услуг по данному этапу исходные коды прикладного ПО на электронном носителе (в случае внесения изменений); – Инструкция по сборке и развертыванию (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство пользователя (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство администратора (в случае внесения изменений); – Документ о приемке Начало: с 11.09.2026 Окончание: не позднее 15.12.2026 6. ПОРЯДОК РАЗРАБОТКИ МОДУЛЯ СЦ Проектирование Модуля СЦ должно включать разработку следующих документов: – Ведомость технического проекта; – Ведомость машинных носителей информации – Пояснительная записка; – Описание информационного обеспечения системы; – Описание автоматизируемых функций; – Схема функциональной структуры; – Описание организации информационной базы; – Руководство по безопасной разработке программного обеспечения; – Описание программного обеспечения; – Макеты экранных форм компонента «Интерактивная карта». Структура документов должна соответствовать ГОСТ Р 59795-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов». Разработка Модуля СЦ должна включать в себя: – разработку программного обеспечения в части новых функций Модуля СЦ; – сборка исходного кода, развертывание и настройку доработанного программного обеспечения Модуля СЦ на вычислительных мощностях Заказчика (тестовый контур); – Комплект рабочей документации на Модуль СЦ; – разработку документа «Программа и методика предварительных испытаний»; – разработку документа «Программа и методика приемочных испытаний»; – разработку документа «Программа опытной эксплуатации». Структура документов должна соответствовать ГОСТ Р 59795-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов». В ходе выполнения работ формируется правоустанавливающая, отчетная, рабочая и техническая документация в соответствии с Контрактом и Календарным планом, приведенном в разделе 5. Значение характеристики не может изменяться участником закупки 6.1. Сведения о гарантийном обслуживании Модуля СЦ Под гарантией понимается устранение Подрядчиком своими силами и за свой счет допущенных по его вине недостатков, выявленных после приемки выполненных Работ, как в работе самой Модуля СЦ, так и недостатков в отчетной документации. Если в период гарантийного срока обнаружатся недостатки, то Подрядчик обязан устранить их за свой счет, в сроки, установленные Заказчиком. Гарантийный срок в этом случае продлевается на период устранения недостатков. Срок гарантии: 1 год с даты приемки Заказчиком результатов исполнения Этапа № 9 контракта. Подрядчиком должны быть внесены соответствующие исправления в техническую и рабочую документацию (указанную в пунктах 5 и 6 настоящего ТЗ), связанные с устранением замечаний к работе Модуля СЦ или в случае выявления Заказчиком недостатков в такой документации в период гарантийного срока. Внесение изменений в документацию технического и рабочего проектирования осуществляется в соответствии с ГОСТ 2.503-2023 и ГОСТ Р 2.504-2021. 7. ПОРЯДОК КОНТРОЛЯ И ПРИЕМКИ РЕЗУЛЬТАТОВ ВЫПОЛНЕНИЯ РАБОТ ПО РАЗВИТИЮ МОДУЛЯ СЦ До момента подключения внешних ИС, Подрядчиком могут быть использованы эмуляторы ИС для прохождения предварительных испытаний, опытной эксплуатации и приемочных испытаний. В рамках опытной эксплуатации должны быть проведены мероприятия по нагрузочному тестированию Модуля СЦ. Документ «Программа и методика приемочных испытаний» должен быть разработан с учетом недостатков, выявленных в ходе опытной эксплуатации, утвержден Заказчиком до начала приемочных испытаний, при этом проверки Модуля СЦ в части не устраненных недостатков, выявленных в процессе опытной эксплуатации, должны быть вынесены в отдельный раздел «Программы и методики приемочных испытаний». В процессе приемочных испытаний должно быть проверено устранение недостатков, полученных в ходе опытной эксплуатации. После завершения устранения всех замечаний, препятствующих приемке Системы в эксплуатацию, перечисленных в Протоколе приемочных испытаний, Подрядчик должен письменно уведомить Заказчика о том, что все замечания устранены, после чего приемочные испытания по решению Заказчика могут быть проведены повторно. Процедура приемочных испытаний проводится до подписания Протокола приемочных испытаний, не содержащего замечаний, препятствующих приемке Системы в эксплуатацию. Приемочные испытания Системы считаются завершенными успешно, если Протокол приемочных испытаний не содержит замечаний, препятствующих приемке Системы в эксплуатацию Значение характеристики не может изменяться участником закупки Испытания должны быть организованы и проведены в соответствии с ГОСТ Р 59792-2021 «Информационная технология. Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем». Должны быть проведены следующие виды испытаний: – предварительные испытания; – опытная эксплуатация; – приемочные испытания. Указанные виды испытаний проводятся в отношении не функциональных требований и функциональных возможностей, разрабатываемых в соответствии с настоящим ТЗ. Отдельные виды испытаний проводятся поэтапно в сроки, установленные Календарным планом. Предварительные испытания, опытная эксплуатация, приемочные испытания проводятся комиссией, создаваемой организационно-распорядительным документом Заказчика, который должен определять состав комиссии, порядок ее работы. Методы предварительных испытаний и порядок их проведения должны быть определены в документе «Программа и методика предварительных испытаний», который должен быть утвержден Заказчиком до начала предварительных испытаний. По результатам предварительных испытаний оформляется Протокол предварительных испытания и Акт о приемке в опытную эксплуатацию. Порядок проведения и методы испытаний во время опытной эксплуатации должны быть определены в документе «Программа опытной эксплуатации», который должен быть утвержден Заказчиком до начала опытной эксплуатации. Ход и результаты опытной эксплуатации отражаются в документе «Журнал опытной эксплуатации», и учитываются в ходе приемочных испытаний. По результатам опытной эксплуатации подписывается Акт о завершении опытной эксплуатации 8. ТРЕБОВАНИЯ К СОСТАВУ И СОДЕРЖАНИЮ РАБОТ ПО ПОДГОТОВКЕ МОДУЛЯ СЦ К ВВОДУ В ЭКСПЛУАТАЦИЮ По результатам проведения приемочных испытаний оформляется Протокол приемочных испытаний и Акт приемки в эксплуатацию. В случае, если взаимодействие с внешними системами не может быть проверено на средах постоянной эксплуатации взаимодействующих систем (по причине неготовности со стороны внешней системы или иным причинам), функции взаимодействия, разработанные в соответствии с требованиями ТЗ, должны быть проверены на тестовых данных с использованием программ-имитаторов взаимодействия. По результатам выполнения этапа приемочных испытаний должны быть подготовлены материалы для регистрации доработанной версии Модуля СЦ (объекта учета) в НФАП в соответствии с требованиями постановления Правительства Российской Федерации от 30 января 2013?г. №?62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин» (с изменениями и дополнениями) в части обязательности размещения результатов работ в национальном фонде алгоритмов и программ для электронных вычислительных машин. Сдача-приемка результатов выполнения Работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная, техническая документация, а также программное обеспечение предоставляется Заказчику в порядке, предусмотренном Контрактом и ТЗ до размещения Подрядчиком в Единой информационной системе в сфере закупок документа о приемке. Результаты проведения опытной эксплуатации, предварительных и приемочных испытаний должны быть зафиксированы в соответствующих протоколах и актах. Выявленные отклонения от настоящего ТЗ, оформляются как недостатки Модуля СЦ Значение характеристики не может изменяться участником закупки Протоколы предварительных и приемочных испытаний должны содержать вывод о соответствии Модуля СЦ предъявляемым требованиям, а также сроки устранения замечаний и реализации рекомендаций, сформулированных комиссией в ходе предварительных и приемочных испытаний. Условием для передачи Модуля СЦ в промышленную эксплуатацию является устранение всех замечаний. Документация на Модуль СЦ и ее части (техническая и рабочая) должна содержать исчерпывающее описание принятых проектных решений в объеме, достаточном для ее дальнейшего развития и эксплуатации. Техническая и рабочая документация должна содержать описание разработанных результатов работ, в том числе программ для ЭВМ, прикладных программных интерфейсов, алгоритмов и протоколов информационного взаимодействия, технических требований, спецификаций и форматов обмена данными для взаимодействия с другими информационными системами, в объеме, достаточном для их установки, настройки, эксплуатации и развития в дальнейшем без привлечения Подрядчика. Исходные коды передаются в виде и составе, позволяющем провести: – сборку (компиляцию) Модуля СЦ в контролируемой Заказчиком среде; – установку полученной Модуля СЦ на специально подготовленную контролируемую Заказчиком инфраструктуру; – проверку функциональных возможностей Модуля СЦ; – оформление Модуля СЦ в качестве объекта национального фонда алгоритмов и программ для электронных вычислительных машин 8.1. Требования, предъявляемые в соответствии с Приказом Минцифры России от 17.12.2020 № 715 «Об утверждении типовых условий контрактов на выполнение работ по созданию и (или) развитию (модернизации) государственных (муниципальных) и (или) иных информационных систем» Передача исходных кодов, разработанных в ходе выполнения работ, программ для электронных вычислительных машин (далее – программа для ЭВМ) должна сопровождаться передачей всех необходимых для сборки и запуска программы для ЭВМ библиотек зависимостей, программных сценариев (скриптов) для проведения установки (развертывания) программы для ЭВМ. Подрядчик в процессе сдачи-приемки работ по Контракту должен провести демонстрацию процесса и установки (развертывания) разработанных программ для ЭВМ. Документация на Модуль СЦ должна содержать описание принятых проектных решений в объеме, достаточном для ее дальнейшего развития и эксплуатации 9. ТРЕБОВАНИЯ К ДОКУМЕНТИРОВАНИЮ 9.1. Общие требования Документация на Модуль СЦ должна быть разработана в составе, указанном в разделах 5-8 данного ТЗ, и должна удовлетворять требованиям комплекса стандартов и руководящих документов на автоматизированные системы: – ГОСТ Р 2.105-2019 в части оформления текстовых документов; – ГОСТ 34.201-2020 в части наименования и обозначения документов. Документация на Модуль СЦ должны оформляться на листах формата А4. Допускается для размещения рисунков и таблиц использование листов формата А3 с подшивкой по короткой стороне листа. Документы объемом более 25 (двадцати пяти) листов должны содержать информационную часть, состоящую из аннотации и содержания. Исходные коды должны быть представлены в 1 (одном) экземпляре на электронном носителе, отчетные материалы должны быть представлены в 2 (двух) экземплярах на бумажном носителе (по одному экземпляру для Заказчика и Подрядчика) и в 1 (одном) экземпляре на электронном носителе в формате документов DOCX и PDF. При разработке документов на Модуль СЦ допускается отклонение от требований комплекса стандартов, описанных выше. Документам на Модуль СЦ должны в обязательном порядке присваиваться уникальные децимальные номера в соответствии с порядком, установленном в ГОСТ 34.201-2020. Документ «Программа и методика предварительных испытаний» должен включать приложения с формой протокола предварительных испытаний и формой акта приемки в опытную эксплуатацию. Документ «Программа опытной эксплуатации» должен включать приложение с формой журнала опытной эксплуатации. Документ «Программа и методика приемочных испытаний» должен включать приложения с формой протокола приемочных испытаний и формой акта приемки в эксплуатацию Значение характеристики не может изменяться участником закупки 10. ИСТОЧНИКИ РАЗРАБОТКИ 10.1. Список литературы Специальная литература для разработки ТЗ не использовалась. 10.2. Нормативно-методические документы Список используемых нормативно-методических документов представлен в разделе 1.6 технического задания. ? Приложение А Эскизы визуального оформления компонента «Интерактивная карта» Значение характеристики не может изменяться участником закупки Приложение Б Параметры оказания услуг Б.1. Базовые параметры оказания Услуг Базовые параметры оказания Услуг приведены ниже: – режимы оказания Услуг (таблица Б.1.1); – сроки предоставления отчетности (таблица Б.1.2). Таблица Б.1.1 - Режимы оказания Услуг № п/п Параметр Значение Значение характеристики не может изменяться участником закупки Б.2. Приоритеты и регламентные сроки решения обращений (заявок) В зависимости от уровня сбоя в работе Системы обращению (заявке) присваивается один из следующих приоритетов, а также в зависимости от приоритета обращения (заявки) устанавливаются следующие контрольные сроки решения в соответствии с таблицей ниже (Таблица Б.2.1). Таблица Б.2.1 – Приоритеты и регламентные сроки решения обращений (заявок) № п/п Приоритет Максимальное время реагирования Время решения (срок выполнения) Описание приоритета По информационно-консультационной поддержке сотрудников Заказчика и пользователей Системы 1 - не более 1 часа не более 10 часов - По решению инцидентов, связанных с работой ППО: 1 Критический не более 30 минут не более 4 часов - полная недоступность ППО; - недоступность ключевых функций - ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО; - невозможность информационного обмена с ППО для ИС более 4 часов 2 Высокий не более 1 часа не более 8 часов - ошибки/сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; - снижение быстродействия СПО (время отклика ППО на операции превышает 30 секунд); - недоступность управления правами и ролями пользователей 3 Средний не более 4 часов не более 24 часов - невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым -недоступность функции формирования отчетов 4 Низкий не более 8 часов не более 40 часов - отклонение в работе ППО, не влияющее на корректную работу функций; - другие сбои и ошибки, затрагивающие основные функции ППО По адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) 1 Критический не более 40 минут не более 8 часов - изменения, необходимые при проведении аварийно-восстановительных работ для возобновления работоспособности Системы; - изменения, связанные с критичными ошибками, блокирующими возможность оказания государственных услуг и/или чтение и внесение данных в Систему 2 Высокий не более 1 часа не более 40 часов - изменения, относящиеся к обеспечению работоспособности основной функциональности Системы, устраняют выявленные дефекты в работе Системы, оказывающие существенное влияние на работу пользователей в Системе; - изменения, затрагивающие три и более подсистемы/модуля Системы для адаптации 3 Средний не более 4 часов не более 72 часов - изменения, связанные с развитием/улучшением/оптимизацией Системы и выводом новой функциональности в штатном режиме для одного-двух модулей/подсистем; - изменения, связанные с развитием интеграционных механизмов Системы, например обновление существующих и/или реализация новых видов сведений СМЭВ, обновление существующих и/или реализация новых API, адаптация и/или изменение механизмов импорта и экспорта данных Системы и т.д. 4 Низкий не более 8 часов не более 160 часов - изменения, связанные с ошибками/корректировкой/изменением в отображении информации в пользовательском графическом интерфейсе Системы (графика, текст, органы управления, элементы интерфейса) 1 Режим работы Системы Круглосуточно (24х7) 2 Режим доступности информационно-консультационной поддержки пользователей Системы 2.1 Прием и регистрация обращений (заявок) в СРО Регистрация обращений (заявок) производится круглосуточно в режиме 24х7, без праздников и выходных дней. Обработка заявок первой линией поддержки осуществляется в рабочие дни с 9 до 18 часов 2.2 Консультирование сотрудников Заказчика и пользователей Системы в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 3 Режим доступности по решению инцидентов, связанных с работой ППО: 3.1 - приоритет «Критический» Круглосуточно (24х7) 3.2 - приоритет «Высокий» Круглосуточно (24х7) 3.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 3.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4 Режим доступности услуг по адаптации, конфигурации и коррекционному сопровождению Системы 4.1 - приоритет «Критический» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.2 - приоритет «Высокий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 5 Режим доступности по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности 5.1 - приоритет «Критический» Круглосуточно (24х7) 5.2 - приоритет «Высокий» Круглосуточно (24х7) 5.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 5.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) Таблица Б.1.2. Сроки предоставления отчетности, с момента получения запроса № п/п Параметр Значение 1 Предоставление отчета об оказанных услугах за произвольный период 10 рабочих дней 2 Предоставление подробной информации по инциденту с приоритетом «Критический» 16 рабочих часов 3 Предоставление актуализированной документации 10 рабочих дней По устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности 1 Критический не более 30 минут не более 24 часов - критические уязвимости, влияющие на возможную полную недоступность ППО, ключевых функций Системы, ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО без возможности восстановления работоспособности Системы. - Критический уровень CVSS > 8.0 2 Высокий не более 1 часа не более 84 часов - критические уязвимости, влияющие на ошибки и сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО. - Высокий уровень CVSS 5.0 - 8.0 3 Средний не более 4 часов не более 120 часов - уязвимости, влияющие на невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым - Средний уровень CVSS 2.0 - 4.9 4 Низкий не более 8 часов не более 160 часов - уязвимости, влияющие на отклонение в работе ППО, не влияющее на корректную работу функций; - другие сбои и ошибки, затрагивающие основные функции ППО - Низкий уровень CVSS < 2.0 Взаимодействие Заказчика и Подрядчика в части регистрации и контроля времени реагирования и решения обращения (заявки) осуществляется через СРО. Заказчик предоставляет Подрядчику доступ к СРО после заключения Контракта. Поступившие от разных пользователей заявки по поводу однотипных инцидентов или имеющие общую причину должны объединяться в одну заявку. Срок выполнения включает время диагностики инцидента, в ходе которого определяется причина инцидента (проблемы) и способ его устранения. Подрядчик должен обеспечить функционирование Модуля СЦ в соответствии с требованиями и параметрами, указанными в настоящем ТЗ и Регламенте оказании услуг. Основные параметры быстродействия типовых операций в Модуле СЦ указаны в таблице ниже (таблица Б.2.2). Таблица Б.2.2 - Параметры быстродействия Модуля СЦ № п/п Наименование параметра Значение (секунд) 1 Среднее время получения сообщения из очереди сообщений 10 2 Среднее время получения ответа от Системы 5 3 Среднее время открытия карточки реестра 5 Приложение В Регламент оказания услуг Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 8) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 8) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 8) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 8) Категория обращения (заявки): инцидент Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 8) Приоритет Время, очередность решения обращения (заявки), ресурсы, привлекаемые для решения обращения (заявки), порядок/процедура действий при решении обращения (заявки) – поле СРО «Приоритет» (см. рисунок 8) Тип изменения Справочник, классифицирующий типовые запросы характерные для Системы – поле СРО «Предмет обращения» (см. рисунок 8) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 8) Текст запроса на оказание услуги по обновлению или удалению уязвимых компонентов (библиотек) ППО в соответствии с требованиями к обеспечению информационной безопасности Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 8) Значение характеристики не может изменяться участником закупки На рисунке 8 приведена форма обращения (заявки) типа «Инцидент» в СРО. Рисунок 8 - Форма обращения (заявки) типа «Инцидент» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуги по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности, заполненную в свободной форме Приложение 1 к Регламенту Матрица ответственных за взаимодействия в рамках выполнения работ по техническому сопровождению Системы Таблица 1 – Ответственные за взаимодействия в рамках выполнения работ по техническому сопровождению Системы со стороны Исполнителя ФИО Должность Адрес электронной почты Телефон — — — Общий контакт Приложение 2 к Регламенту Приоритеты и регламентные сроки решения обращений (заявок) Приоритеты и регламентные сроки решения обращений (заявок) приведены в таблице 1. Таблица 1 – Приоритеты и регламентные сроки решения обращений (заявок) № п/п Приоритет Максимальное время реагирования Время решения (срок выполнения) Описание приоритета По информационно-консультационной поддержке сотрудников Заказчика и пользователей Системы 1 – не более 1 часа не более 10 часов – По решению инцидентов, связанных с работой ППО 1 Критический не более 30 минут не более 4 часов – полная недоступность ППО; – недоступность ключевых функций; – ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО; – невозможность информационного обмена с ППО для ИС более 4 часов 2 Высокий не более 1 часа не более 8 часов – ошибки/сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; – снижение быстродействия СПО (время отклика ППО на операции превышает 30 секунд); – невозможность управления правами и ролями пользователей 3 Средний не более 4 часов не более 24 часов – невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым недоступность функции формирования отчетов 4 Низкий не более 8 часов не более 40 часов – отклонение в работе ППО, не влияющее на корректную работу функций; – другие сбои и ошибки, затрагивающие основные функции ППО По адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) 1 Критический не более 40 минут не более 8 часов – изменения необходимые при проведении аварийно-восстановительных работ для возобновления работоспособности Системы; – изменения, связанные с критичными ошибками, блокирующими возможность оказания государственных услуг и/или чтение и внесение данных в Систему 2 Высокий не более 1 часа не более 40 часов – изменения относящиеся к обеспечению работоспособности основной функциональности Системы, устраняют выявленные дефекты в работе Системы, оказывающие существенное влияние на процесс оказания государственных услуг и работу пользователей в Системе; – изменения, затрагивающие три и более подсистемы/модуля Системы для адаптации 3 Средний не более 4 часов не более 72 часов – изменения, связанные с развитием/улучшением/оптимизацией Системы и выводом новой функциональности в штатном режиме для одного-двух модулей/подсистем; – изменения, связанные с развитием интеграционных механизмов Системы, например, обновление существующих и/или реализация новых видов сведений СМЭВ, обновление существующих и/или реализация новых API, адаптация и/или изменение механизмов импорта и экспорта данных Системы и т.д. 4 Низкий не более 8 часов не более 160 часов – изменения, связанные с ошибками/ корректировкой/изменение в отображении информации в пользовательском графическом интерфейсе Системы (графика, текст, органы управления, элементы интерфейса) По устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности 1 Критический не более 30 минут не более 24 часов – критические уязвимости, влияющие на возможную полную недоступность ППО, ключевых функций Системы, ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО без возможности восстановления работоспособности Системы; – Критический уровень CVSS > 8.0 2 Высокий не более 1 часа не более 84 часов – критические уязвимости, влияющие на ошибки и сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; – Высокий уровень CVSS 5.0 - 8.0 3 Средний не более 4 часов не более 120 часов – уязвимости, влияющие на невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым; – Средний уровень CVSS 2.0 - 4.9 4 Низкий не более 8 часов не более 160 часов – уязвимости, влияющие на отклонение в работе ППО, не влияющее на корректную работу функций; – другие сбои и ошибки, затрагивающие основные функции ППО; – Низкий уровень CVSS < 2.0 Приложение Г Форма Отчета об оказанных услугах Отчет об оказанных услугах за этап «наименование этапа» в период с «__» _________ по «__» _________. № п/п Наименование услуги Общее количество Номер ОРС Краткое Описание Время реагирования по ТЗ Время реагирования фактическое Время решения по ТЗ Время решения фактическое Результат соблюдения времени реагирования Результат соблюдения времени решения Примечание 1 Услуги по информационно-консультационной поддержке работников Заказчика 2 546782 Консультация по работе Модуля СЦ 1 2 10 часов 11 часов Нет Нет 567123 Консультация по схеме БД 1 1 10 часов 1 час Да Да 2 … … Заказчик Подрядчик /Должность/ /Должность/ ____________________ /Ф.И.О/ ___________________ /Ф.И.О/ М.П. М.П. «_____»_______________________202_г. «_____»_______________________202_г Приложение 1 к Отчету об оказанных услугах Журнал обращений (заявок) на оказание услуги по информационно-консультационной поддержке пользователей Системы (шаблон) Наименование Исполнителя в этапе «наименование этапа» в период с ________________ по _______________ оказал(о) Услугу по поддержке пользователей Системы в объеме, указанном в Таблице 1 Таблица 1 - Журнал обращений (заявок) пользователей Системы № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. ИТОГО зарегистрировано: Всего обращений (заявок): ________ ИТОГО решено: Всего обращений (заявок): ________ Приложение 2 к Отчету об оказанных услугах Журнал обращений (заявок) по решению инцидентов, связанных с работой ППО (шаблон) Наименование Исполнителя в этапе «наименование этапа» в период с ________________ по _______________ оказал(о) Услугу по решению инцидентов в объеме, указанном в Таблице 1. Таблица 1 - Журнал по решению инцидентов № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. ИТОГО зарегистрировано: Всего инцидентов: ________ ИТОГО решено: Всего инцидентов: ________ Приложение 3 к Отчету об оказанных услугах Журнал обращений (заявок) выполнения адаптационного, конфигурационного и коррекционного сопровождения Системы (шаблон) Журнал выполнения адаптации, конфигурации и коррекции Системы сформирован за этап «наименование этапа» в период с «__» _________ по «__» ____________ и представлен в таблице ниже (Таблица 1). Таблица 1 - Журнал выполнения адаптации, конфигурации и коррекции сопровождения Системы № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. Количество выполненных заявок за этап: ________ Приложение 4 к Отчету об оказанных услугах Журнал обращений (заявок) по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности (шаблон) Журнал обращений (заявок) по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности сформирован за этап «наименование этапа» в период с «__» _________ по «__» ____________ и представлен в таблице ниже (Таблица 1). Таблица 1 - Журнал выполнения заявок по устранению уязвимостей в ППО № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. Количество выполненных заявок за этап: ________ Приложение Д Форма Протокола проверки результатов организационно-штатных и подготовительных мероприятий (шаблон) Протокол проверки результатов организационно-штатных и подготовительных мероприятий Настоящий Протокол содержит результаты проверки организационно-штатных и подготовительных мероприятий, проведенных Исполнителем (Таблица Д.1). Таблица Д.1. Протокол проверки результатов № Мероприятия Подготовительного этапа Результат проверки 1. Определить и направить Заказчику документ «Ответственные за взаимодействия в рамках выполнения работ по техническому сопровождению Системы со стороны Исполнителя». Документ содержит контактную информацию (ФИО, должность, адрес электронной рабочей почты, номер телефона) не менее чем о 2 лицах, ответственных за оказание услуг со стороны Подрядчика Выполнено/Не выполнено 2. Обеспечить подключение специалистов Подрядчика к Системе Выполнено/Не выполнено 3. Обеспечить подключение специалистов Подрядчика к СРО Выполнено/Не выполнено Заказчик Подрядчик /Должность/ /Должность/ ____________________ /Ф.И.О/ ___________________ /Ф.И.О/ М.П. М.П. «_____»_______________________202_г. «_____»_______________________202_г Изменение приоритета уже зарегистрированного обращения (заявки) используется в случае появления новых обстоятельств, которые ведут к изменению влияния и/или срочности существующего обращения (заявки). При регистрации обращения (заявки) необходимо провести его приоритизацию. В процессе управления обращениями (заявками) каждому обращению (заявке) присваивается приоритет, принимающий одно из значений: Низкий, Средний, Высокий или Критический. В соответствии с приоритетом определяется время, очередность устранения, , ресурсы, привлекаемые для работ по обращению (заявке), а также может определяться порядок/процедура действий при работе с обращением (заявкой). Заказчиком в зависимости от уровня сбоя в работе Системы обращению (заявке) присваивается приоритет с указанием максимального времени реакции и решения в соответствии с требованиями, указанными в Приложении 2 к настоящему Регламенту 4 Формы обращений (заявок) на оказание услуг по технической поддержке Системы, заполняемые в СРО 4.1. Форма обращения (заявки) на оказание услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы При подаче обращения (заявки) типа «ЗНО» в СРО указывается (Таблица 5): Таблица 5 – Описание атрибутов формы обращения (заявки) на оказание услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 5) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 5) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 5) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 5) Категория обращения: информационно-консультационная поддержка Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 5) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 5) Текст запроса на оказание услуги по информационно-консультационной поддержке сотрудников Заказчика Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 5) На рисунке 5 приведена форма обращения (заявки) типа «ЗНО» в СРО. Рисунок 5 - Форма обращения (заявки) типа «ЗНО» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы, заполненную в свободной форме. 4.2. Форма обращения (заявки) на оказание услуги по решению инцидентов, связанных с работой ППО При подаче обращения (заявки) типа «Инцидент» в СРО указывается (Таблица 6): Таблица 6 – Описание атрибутов формы обращения (заявки) на оказание услуги по решению инцидентов, связанных с работой ППО Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 6) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 6) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 6,) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 6) Категория обращения (заявки): инцидент Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 6) Приоритет изменения Время - одно из значений: Низкий, Средний, Высокий или Критический. Определяет, очередность решения обращения (заявки), ресурсы, привлекаемые для решения обращения (заявки), порядок/процедура действий при решении обращения (заявки) – поле СРО «Приоритет» (см. рисунок 6,) Тип изменения Справочник, классифицирующий типовые запросы характерные для Системы – поле СРО «Предмет обращения» (см. рисунок 6) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 6) Полное описание инцидента, включая скриншоты и описание шагов, приведших к неисправности Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 6) Однократность/неоднократность Круг пользователей или компьютеров, затронутых данным инцидентом Действия, предпринятые для самостоятельного решения инцидента (при наличии) Версии используемого программного обеспечения на клиентской рабочей станции, где воспроизводится ошибка (операционная система, прикладное программное обеспечение) Дополнительная информация На рисунке 6 приведена форма обращения (заявки) типа «Инцидент» в СРО. Рисунок 6 - Форма обращения (заявки) типа «Инцидент» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуги по решению инцидентов, связанных с работой ППО, заполненную в свободной форме 4.3. Форма обращения (заявки) на оказание услуг по адаптационному конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) При подаче обращения (заявки) типа «ЗНИ» в СРО указывается (Таблица 7): Таблица 7 – Описание атрибутов формы обращения (заявки) на оказание услуг по адаптационному, конфигурационному и коррекционному сопровождению Системы Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 10) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 9) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 10) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 10) Категория обращения (заявки): запрос на изменение Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 7) Приоритет изменения Время, очередность решения обращения (заявки), ресурсы, привлекаемые для решения обращения (заявки), порядок/процедура действий при решении обращения (заявки) – поле СРО «Приоритет» (см. рисунок 7) Тип изменения Справочник, классифицирующий типовые запросы характерные для Системы – поле СРО «Предмет обращения» (см. рисунок 7) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 7) Текст запроса на оказание услуги по адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 7) На рисунке 7 приведена форма обращения (заявки) типа «ЗНИ» в СРО. Рисунок 7 - Форма обращения (заявки) типа «ЗНИ» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуг по адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей), заполненную в свободной форме 4.4. Форма обращения (заявки) на оказание услуги по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности При подаче обращения (заявки) типа «Инцидент» в СРО указывается (Таблица 8): Таблица 8 – Описание атрибутов формы обращения (заявки) на оказание услуг по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности Третий уровень технической поддержки (далее – 3-й уровень) Группа ответственных сотрудников Исполнителя, отвечающая за устранение сбоев и аварий, проведение информационно-консультационной поддержки пользователей Системы, проведение адаптации и конфигурирования Системы в объемах действующих контрактов на оказание технической поддержки 3.3 Перечень и описание статусов обращений (заявок) В Таблице 3 приведен перечень статусов обращений (заявок), действующий в СРО, и их описание. Таблица 3 - Перечень статусов обращений (заявок) и их описание Статус Описание Зарегистрирован Обращение (заявка) принято и зарегистрировано Направлен в группу Присваивается при назначении ответственными сотрудниками 1-го уровня группе ответственных сотрудников 2-го уровня по тематике обращения (заявки) после заполнения всей необходимой информации и полей обращения (заявки), а также при его передаче между группами 2-го уровня Передан в группу Присваивается при передаче обращения (заявки) ответственными сотрудниками 2-го уровня на группу ответственных сотрудников 3-го уровня Назначен Присваивается при назначении обращения (заявки) на ответственного сотрудника для его решения в рамках компетенции В работе Присваивается при приеме обращения (заявки) в работу ответственным сотрудником для его решения Решен Присваивается ответственным сотрудником, выполнившим работы по обращению (заявке) Закрыт Присваивается автоматически при решении запроса по обращению (заявке), а также отсутствии дополнительных запросов пользователя в соответствии с действующим SLA, или при подтверждении решения обращения (заявки) со стороны пользователя Запрос доп. информации Присваивается при необходимости запроса дополнительной информации и/или уточнения предмета обращения по обращению (заявке) у пользователя Ответ предоставлен Присваивается после ответа пользователем на запрос дополнительной информации Отклонен Присваивается, если обращение (заявка) не актуальна (по информации от пользователя), отсутствует техническая возможность решения обращения (заявки), предмет обращения не входит в компетенции технической поддержки, или существует влияние доработки на другие компоненты, что нарушает общий порядок работы Системы Согласование Присваивается при необходимости согласования направления обращения (заявки) ответственным сотрудником Заказчика на 3-й уровень Анализ Присваивается при проведении анализа на предмет возможности внесения изменений, связанных с развитием/улучшением/оптимизацией Системы и выводом новой функциональности и оценке ресурсоемкости Тестирование Присваивается Исполнителем при завершении разработки и проведенном предварительном тестировании для последующего осуществления приемочного тестирования Специалистом 2-го уровня Релиз Присваивается ответственным сотрудником Заказчика при принятии решения о возможности вывода доработки в продуктивную среду Утверждение заказчиком Присваивается при согласовании группой профильных специалистов на 2-м уровне поддержки с пользователем технического задания для внесения изменений, связанных с развитием/улучшением/оптимизацией Системы и выводом новой функциональности Доработка Присваивается в случае несогласования Заказчиком работ, проведенных Исполнителем в рамках контрактных обязательств, по внесению изменений, связанных с развитием/улучшением/оптимизацией Системы и выводом новой функциональности в штатном режиме, и необходимости последующего направления Исполнителю для ее доработки Отложен Присваивается в случае невозможности выполнения запроса, изложенного в обращении (заявке), в связи с необходимостью запроса дополнительной информации у третьих сторон 3.4 Порядок регистрации и сопровождения Заявок Порядок регистрации и сопровождения обращений (заявок) в рамках оказываемых услуг по технической поддержке Системы зависит от типа обращения (заявки): 1. Услуга по решению инцидентов, связанных с работой ППО – тип обращения (заявки) «Инцидент». 2. Услуга по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности – тип обращения (заявки) «Инцидент». 3. Услуга информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы – тип обращения (заявки) «Запрос на обслуживание» (в том числе, консультационный запрос). 4. Услуга адаптационного, конфигурационного и коррекционного сопровождения Системы (в рамках действующих программных модулей и функциональностей) – тип обращения (заявки) «Запрос на изменение». В случае недоступности СРО взаимодействие и информирование Исполнителем о ходе оказания услуги по обращению (заявке), изменению статусов обращений (заявок) осуществляется по согласованию с Заказчиком в соответствии с матрицей взаимодействия, представленной в Приложении 1 к настоящему Регламенту. 3.4.1 Инцидент На рисунке 2 представлена функциональная схема регистрации и сопровождения обращений (заявок) типа «Инцидент». Рисунок 2 - Функциональная схема регистрации и сопровождения обращений (заявок) типа «Инцидент» 3.4.2 Запрос на обслуживание На рисунке 3 представлена функциональная схема регистрации и сопровождения обращения (заявки) типа «ЗНО». Рисунок 3 - Функциональная схема регистрации и сопровождения обращения (заявки) типа «ЗНО» 3.4.3 Запрос на изменение На рисунке 4 представлена функциональная схема регистрации и сопровождения обращений (заявок) типа «ЗНИ». Рисунок 4 - Функциональная схема регистрации и сопровождения обращений (заявок) типа «ЗНИ» 3.5 Порядок классификации и приоритизации обращений (заявок) Классификация является начальной стадией процесса оказания технической поддержки, необходимой для идентификации обращения (заявки) и определения соответствующих действий для его обработки. Для проведения первичной классификации необходимо получить от пользователя и зафиксировать в описании обращения (заявки) подробные сведения о сути запроса, в том числе, для Инцидентов зафиксировать сценарий воспроизведения обнаруженной ошибки. Для проведения вторичной классификации необходимо провести анализ и диагностику для определения корневой причины и затронутой Инцидентом функциональной области (инфраструктура, сеть, ППО). В процессе классификации осуществляется первичная диагностика и оценка проблемы, описанной пользователем Системы в обращении (заявке), в части функционирования и/или удобства использования Системы. Корректная классификация позволяет увеличить скорость обработки обращения (заявки) и решения описанной в обращении (заявке) проблемы при минимальном привлечении ресурсов, в частности, за счет использования известных решений для типовых обращений (заявок), которые должны описываться в БЗ СРО. Классификация позволяет произвести первоначальное назначение обращения (заявки) на ответственного сотрудника и выставить приоритет с учетом приоритизации. Приоритизация применяется для определения критичности описанной в обращении (заявке) проблемы для функционирования ППО Системы. Приоритет рассмотрения обращения (заявки) определяется в процессе ее классификации на основании ряда параметров, вводимых при заполнении обращения (заявки). Приоритизация используется для того, чтобы при одновременном наличии нескольких обращений (заявок) в первую очередь рассматривалась обращения (заявки) с наивысшим приоритетом и не позднее установленных для данного приоритета сроков Термины и сокращения В настоящем регламенте используются следующие термины и сокращения на русском и английском языках: Термины/сокращения Полное наименование/описание БЗ (База знаний) База данных Системы регистрации обращений (заявок), созданная для сбора, хранения и поиска способов решения известных проблем в рамках Системы Жизненный цикл обращения (заявки) Совокупность статусов, по которым проходит обращение (заявка), и правила перехода обращения (заявки) из одного статуса в другой Заказчик ФГБУ «СИЦ Минтранса России» – Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» ЗНИ Запрос на изменение – тип заявки, предполагающий внесение изменений в прикладное программное обеспечение Системы ЗНО Запрос на обслуживание – тип заявки, предполагающий работы по предоставлению консультации, предоставление доступа к Системе или стандартизированные типовые изменения конфигураций Системы Инцидент Тип заявки, классифицируемый как нештатное событие в работе компонентов функциональных задач Системы, которое привело или может привести к нарушению или снижению качества функционирования Системы ИС Информационная система Исполнитель Организация, которая определяется по результатам конкурсных процедур Классификация Анализ и заполнение классификационных полей справочными значениями, определяющими последовательность действий и этапов жизненного цикла заявки, а также порядок рассмотрения заявок Консультация Разъяснения по алгоритму работы, требуемых настроек прикладного программного обеспечения и технологии обработки данных при работе с Системой, предоставление информации Маршрутизация Определение процесса движения обращения (заявки) в Системе управления заявками между уровнями технической поддержки и организационными структурами на уровнях поддержки путем назначения обращения (заявки) в соответствии с его классификацией и выставленным приоритетом Обращение (заявка) Устное или письменное обращение пользователя АСУ ТК с вопросом, касающимся работоспособности АСУ ТК, по одному из определённых каналов связи: электронная почта, Система регистрации обращений (заявок) Пользователь Инициатор обращения (заявки) или пользователь Системы ППО Прикладное программное обеспечение Предмет обращения Справочник, классифицирующий типовые запросы в Системе регистрации обращений (заявок), характерные для Системы, выбранное значение определяет маршрутизацию обращения (заявки) (группу ответственных сотрудников) Приоритизация Значение, определяющее время, очередность решения обращений (заявок), ресурсы, привлекаемые для решения обращений (заявок), . Приоритет устанавливается в соответствии с масштабом выявленной проблемы, которая привела или может привести к нарушению или снижению качества функционирования Системы Релиз Выпуск версии прикладного программного обеспечения Системы, от разработки до тестирования и планового обновления Системы на продуктивной среде для установки изменений, связанных с развитием/улучшением/оптимизацией Системы Система, АСУ ТК, Информационно-аналитическая система регулирования на транспорте Информационно-аналитическая система, предназначенная для автоматизации и информационно-аналитического обеспечения процессов управления развитием транспортного комплекса Российской Федерации, обеспечения публичности деятельности органов государственного управления транспортным комплексом, а также обеспечения процессов оказания государственных услуг в электронном виде в сфере транспорта СМЭВ Система межведомственного электронного взаимодействия СПО Системное программное обеспечение СРО Система регистрации обращений (заявок) Статус обращения (заявки) Текущее состояние обращения (заявки) в жизненном цикле процесса оказания технической поддержки Системы СУБД Система управления базами данных Уровень технической поддержки Организационно-структурная часть технической поддержки, имеющая определённые организационно-нормативными документами зоны ответственности, обязанности, а также временные нормативы, в течение которых эти обязательства должны выполняться либо эскалироваться на следующий уровень технической поддержки Услуги Услуги по технической поддержке Информационно-аналитической системы регулирования на транспорте АСУ ТК ФИО Фамилия, имя, отчество Эскалация Процедура повышения внимания к обращению (заявке) путем повышения его приоритета и/или передачи на следующий уровень технической поддержки, а также привлечение ролей, которые могут принимать решения без передачи на следующий уровень технической поддержки API Англ. Application Programming Interface — программный интерфейс приложения, интерфейс прикладного программирования — описание способов (набор классов, процедур, функций, структур или констант), которыми одна компьютерная программа может взаимодействовать с другой программой CVSS Англ. Common Vulnerability Scoring System - открытый стандарт, используемый для расчета количественных оценок уязвимости в безопасности компьютерной системы, обычно с целью понять приоритет ее исправления. В современном инструментарии информационной безопасности используется версия 3.0 и выше с дополнительными метриками к базовым оценкам ID Англ. Identifier – идентификатор, уникальный признак объекта, позволяющий отличать его от других объектов, то есть, идентифицировать SLA Англ. Service Level Agreement - утвержденные условия по обработке обращения (заявки) с установленными метриками времени, которые определяют пороговые значения для эскалации в зависимости от статуса обращения (заявки) (например, время реакции – время от регистрации до осуществления первичной обработки, время решения – время от регистрации обращения (заявки) до его решения и т.д.) SQL Англ. Structured Query Language — «язык структурированных запросов», — декларативный язык программирования, применяемый для создания, модификации и управления данными в реляционной базе данных, управляемой соответствующей СУБД 1 Общие сведения 1.1 Полное наименование Услуг Оказание услуг по технической поддержке Модуля СЦ АСУ ТК в 2026 году. 1.2 Предмет Регламента оказания услуг Требования Технического задания 2 Общие положения 2.1 Цель и задачи оказания услуг Целью технической поддержки Системы является обеспечение ее стабильного и безопасного функционирования и эксплуатации, предупреждение, выявление и устранение сбоев в работе Системы и минимизация их неблагоприятного влияния. Для достижения поставленной цели требуется решение следующих задач: 1. Обеспечение информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы. 2. Поддержание параметров функционирования ППО Системы, удовлетворяющих требованиям производственных процессов, включая их непрерывность. 3. Обеспечение бесперебойного функционирования ППО и своевременное устранение сбоев и аварийных ситуаций в Системе. 4. Своевременное устранение уязвимостей при выявлении таковых, в соответствии с требованиями к обеспечению информационной безопасности. 5. Адаптация, конфигурирование, коррекция программного обеспечения в соответствии с изменениями нормативно-правовой базы и запросами уполномоченных сотрудников органов государственной власти, включая выполнение процедур тестирования и участие в обновлениях ППО на стендах Заказчика. 6. Обеспечение сохранения работоспособности ППО в изменяемой среде эксплуатации. 7. Ведение документации по настоящему контракту и инициирование актуализации документации на Систему по результатам обработки запросов Заказчика и внесения соответствующих изменений в ППО 2.2 Общее описание процесса оказания сопровождения (технической поддержки) Системы Процесс оказания технической поддержки Системы включает: 1. Поступление обращений (заявок) от пользователей и их регистрацию. 2. Сопровождение обращений (заявок) в соответствии с их классификацией и приоритизацией, в том числе, с их последующей эскалацией. 3. Определение ролей и регламент их взаимодействия при осуществлении деятельности по процессу. 4. Решение обращений (заявок) в установленные настоящим Регламентом сроки. 5. Взаимодействие между 1-м, 2-м и 3-м уровнями технической поддержки, в том числе, с формированием заданий для сопровождения Системы. 6. Контроль качества выполняемых Исполнителем работ, состоящий из проверки сценария, приводящего к ошибке, зафиксированной в Инциденте, и/или к ошибке воспроизведения, а также тестирование внесенных изменений в рамках ЗНИ. 7. Обеспечение мониторинга и проведение анализа процесса обработки поступающих в техническую поддержку обращений (заявок). Техническая поддержка реализуется путем проведения ответственными сотрудниками соответствующей информационно-консультационной деятельности в соответствии с определенными ролями, а также выполнения Исполнителем конкретных действий по своевременному выявлению причин сбоев и аварийных ситуаций и их устранению, а также по адаптации, конфигурированию, корректировке Системы, включая выполнение процедур тестирования и участия в обновлениях Системы. Все роли подразделяются на уровни поддержки, взаимодействующие между собой в соответствии с блок-схемой процесса технической поддержки. Общая схема процесса рассмотрения обращений (заявок) в соответствии с видами технической поддержки представлена на рисунке 1. . Рисунок 1 - Общая схема процесса рассмотрения обращений (заявок) в соответствии с видами технической поддержки 2.3 Каналы связи Должна быть предусмотрена омниканальность в части приема обращений (заявок). Получение обращений (заявок) технической поддержкой происходит по следующим каналам связи: – СРО; – электронная почта; – телефонная линия. Исполнитель обеспечивает прием обращений (заявок) от Заказчика и предоставляет информацию в рамках оказания услуг по техническому сопровождению Системы, руководствуясь матрицей взаимодействия, приведенной в Приложении 1 к настоящему Регламенту 3 Порядок оказания Услуг 3.1 Типы обращений (заявок) Обращения и заявки Заказчика классифицируются в соответствии с приоритетами и регламентными сроками, указанными в Приложении 2 к настоящему Регламенту. Регистрация обращений и заявок предусматривает создание новой записи в СРО с присвоением поступившему обращению или заявке (новой записи) уникального идентификатора. Запись в СРО должна содержать вопрос или проблему, которую требуется решить или оказать консультацию. Если обращение или заявка автоматически зарегистрированы в СРО при отправке представителем Заказчика, Исполнитель проверяет корректность указанного типа обращения (заявки) и может обратиться к Заказчику с просьбой корректировки, предоставив обоснования в соответствии с настоящей классификацией (Таблица 1) Таблица 1 - Типы обращений (заявок) Тип обращения (заявки) Описание Запрос на обслуживание Подготовка SQL запроса к СУБД для решения прикладной задачи и д р. – запрос на любое действие, не являющееся запросом информации и несовершенный на основе происшествия, прямо или косвенно влияющего на работу Системы Консультация (входит в тип обращения (заявки) «Запрос на обслуживание») «Где взять / куда обратиться...?», «Как сделать / выполнить…», «Как это работает…?» - запрос, имеющий своей целью получение информационной поддержки Инцидент Разбор ошибок/сбоев и подготовка материалов (корректировочных релизов, инструкций) для Заказчика для устранения ошибок/сбоев, которые приводят к частичному и полному нарушению работоспособности всех или отдельных функций ППО. Подготовка изменения и материалов, необходимых для проведения аварийно-восстановительных работ для возобновления работоспособности Системы. ЗНИ Подготовка изменений, связанных с изменением, улучшением/оптимизацией Системы и выводом новой модифицированной функциональности в штатном режиме. Подготовка изменений, связанных с модификацией существующих и/или реализация новых интеграционных механизмов для получения/обработки данных внешних систем. Подготовка изменений графического интерфейса по требованиям Заказчика 3.2 Участники технической поддержки, осуществляющие сопровождение обращений (заявок) Техническая поддержка Системы должна быть организована на трех уровнях: 1. Первый и второй уровни технической поддержки организуется Заказчиком. 2. Третий уровень технической поддержки организуется Исполнителем. Зона ответственности каждого уровня технической поддержки указана в Таблице 2. Таблица 2 - Зона ответственности каждого уровня технической поддержки Участники технической поддержки Описание Первый уровень технической поддержки (далее – 1-й уровень) Группа ответственных сотрудников 1-го уровня Заказчика, осуществляющая прием и первичную обработку обращений (заявок) (описание предмета обращения, первичная классификация и приоритизация, определение назначения, маршрутизация обращений (заявок) по назначению), руководствуется в своей работе настоящим Регламентом и БЗ, наполняемой 2-м уровнем поддержки, самостоятельно решает часть обращений (заявок), связанных с недостаточной квалификацией пользователей или настройками в рамках своей компетенции. В случае невозможности решения обращений (заявок) на 1-ом уровне ответственный сотрудник передает ее на 2-й уровень Второй уровень технической поддержки (далее – 2-й уровень) Группа ответственных сотрудников 2-го уровня Заказчика по установленным компетенциям (информационная безопасность, сопровождение и эксплуатация информационно-аналитических систем, развитие информационно-аналитических систем, техническая поддержка информационно-аналитических систем) отвечает за поддержание работоспособности Системы, обработку обращений (заявок) и их решение в регламентные сроки в соответствии с установленными приоритетами. Осуществляет информационно-консультационную поддержку пользователей Системы в рамках своей компетенции. Оказывает экспертную помощь ответственным сотрудникам 1-го уровня в части формирования БЗ, содержащей ответы на часто задаваемые вопросы пользователей, с целью передачи знаний, навыков и инструментария на 1-й уровень для ускорения решения обращений (заявок). В случае невозможности решения обращения (заявки) на 2-ом уровне ответственный сотрудник передает его на 3-й уровень. При выявлении необходимости изменений в ППО Системы инициирует формирование обращения (заявки) и направляет его на группу ответственных сотрудников 3-го уровня по соответствующему классификатору (ЗНО, ЗНИ, и т.д.) - Наименование характеристики - Значение характеристики - Единица измерения характеристики - Инструкция по заполнению характеристик в заявке - ОПРЕДЕЛЕНИЯ, ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ - Автоматизированная система (АС) Система, состоящая из комплекса средств автоматизации, реализующего информационную технологию выполнения установленных функций, и персонала, обеспечивающего его функционирование (ГОСТ Р 59853-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения») АРМ Автоматизированное рабочее место АСУ ТК, Система Информационно-аналитическая система регулирования на транспорте АТС Автоматическая телефонная станция БД База данных ГИС Государственная информационная система ГОСТ Государственный стандарт ГЦОД СИЦ Минтранса России, ГЦОД Головной центр обработки данных ФГБУ «СИЦ Минтранса России» Дашборд Интерактивная аналитическая панель, графический интерфейс. ЕИС Единая информационная система в сфере закупок ЕСИА Единая система идентификации и аутентификации Заказчик Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» КИИ Критическая информационная инфраструктура Кластер Кла?стер (англ. cluster) – объединение нескольких однородных элементов, которое может рассматриваться как самостоятельная единица, обладающая определёнными свойствами Компонент Часть АС, выделенная по определенному признаку или совокупности признаков и рассматриваемая как единое целое (ГОСТ Р 59853-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения») Контракт Контракт на выполнение работ по развитию и оказанию услуг по технической поддержке Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК в 2026 году, заключаемый по результатам проведения конкурентной процедуры закупки в соответствии с требованиями Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» - - Значение характеристики не может изменяться участником закупки - Модуль iМинтранс Модуль сбора данных и представления показателей деятельности Министерства транспорта Российской Федерации iМинтранс АСУ ТК Модуль СЦ Модуль сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК НС Нештатная ситуация НСИ Нормативно-справочная информация ОТИ Объект транспортной инфраструктуры П-ГИС Геоинформационная подсистема П-ИВ Подсистема информационного взаимодействия П-НСИ Подсистема ведения нормативно-справочной информации и метаданных ПО Программное обеспечение Подрядчик, Исполнитель Организация, с которой будет заключен контракт на выполнение работ по развитию Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК П-СД Подсистема сбора данных Работы Работы по развитию Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК СЗИ Средство защиты информации СМЭВ Система межведомственного электронного взаимодействия СУБД Система управления базами данных ТЗ Техническое задание (настоящий документ) ТС Транспортное средство ТК Транспортный комплекс Учреждение Учреждения в области информационной безопасности - ФГБУ «СИЦ Минтранса России» Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации», Заказчик Федеральный закон № 44-ФЗ Федеральный закон от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» ФЗ Функциональная задача ФЗ «Реестр объектов» Функциональная задача «Формирование и ведение единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации» ФСБ России Федеральная служба безопасности Российской Федерации ФСТЭК России Федеральная служба по техническому и экспортному контролю ЧС Чрезвычайная ситуация ЭВМ Электронно-вычислительная машина API От англ. Application Programming Interface – интерфейс прикладного программирования – совокупность инструментов и функций в виде интерфейса для взаимодействия с программой CSS От англ. Cascading Style Sheets — каскадные таблицы стилей FPS От англ. frame per second - количество кадров в секунду HTML От англ. HyperText Markup Language - стандартный язык разметки документов, создающий основу и структуру всех веб-страниц JSON От англ. JavaScript Object Notation – текстовый формат обмена данными, основанный на JavaScript WebAssembly (Wasm) Открытый стандарт, представляющий собой низкоуровневый бинарный формат инструкций, который позволяет выполнять код, написанный на языках C++, Rust или Go, в браузерах с производительностью, близкой к нативной - 1. ОБЩИЕ СВЕДЕНИЯ - – Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 19.02.2026 №ЕФ-1; – План мероприятий по профилактике случаев непроизводственного травматизма граждан на железнодорожном транспорте, являющийся приложением к постановлению коллегии Министерства транспорта Российской Федерации от 11.03.2026 № 2 - - Значение характеристики не может изменяться участником закупки - 1.6. Перечень документов, требования которых должны быть учтены при выполнении работ – Федеральный закон Российской Федерации от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации»; – Федеральный закон Российской Федерации от 27.07.2006 № 152-ФЗ «О персональных данных»; – Федеральный закон Российской Федерации от 06.04.2011 № 63-ФЗ «Об электронной подписи»; – Федеральный закон Российской Федерации от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации»; – Указ Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации»; – Указ Президента Российской Федерации от 01.05.2022 № 250 «О дополнительных мерах по обеспечению информационной безопасности Российской Федерации»; – Указ Президента Российской Федерации от 31.03.2010 № 403 «О создании комплексной системы обеспечения безопасности населения на транспорте»; – постановление Правительства Российской Федерации от 30.07.2004 № 395 «Об утверждении Положения о Министерстве транспорта Российской Федерации»; – постановление Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации»; – постановление Правительства Российской Федерации от 16.11.2015 № 1236 «Об установлении запрета на допуск программного обеспечения, происходящего из иностранных государств, для целей осуществления закупок для обеспечения государственных и муниципальных нужд»; – постановление Правительства Российской Федерации от 23.12.2024 № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц»; - 1.8. Общие сведения об источниках и порядке финансирования работ Источником финансирования являются средства субсидии федерального бюджета Российской Федерации, предоставленной в соответствии с абзацем вторым пункта 1 статьи 78.1 Бюджетного кодекса Российской Федерации (код цели 08-01) - 1.9. Порядок оформления и предъявления результатов работ Подрядчик должен передать Заказчику результаты работ в порядке, определенном Контрактом в сроки, установленные п. 5 настоящего ТЗ, в соответствии с Календарным планом - 1.10. Место выполнения Работ Работы выполняются удаленно на комплексе технических средств Заказчика. Адрес размещения комплекса технических средств Заказчика: Московская обл., Богородский район, пос. Горбуша, Радиоцентр. Техническая возможность удаленного подключения обеспечивается Заказчиком (в части предоставления параметров доступа). Оплата телематических и иных услуг, технических и программных средств, необходимых Подрядчику для удаленного подключения и для выполнения требований по информационной безопасности, осуществляется Подрядчиком самостоятельно за свой счет - 1.1. Наименование Системы Полное наименование системы: Информационно-аналитическая система регулирования на транспорте. Условное обозначение системы: АСУ ТК. Полное наименование модуля: Модуль сбора, ведения и анализа информации о нештатных ситуациях на транспорте. Условное обозначение модуля: Модуль СЦ. Модуль СЦ создан в рамках контракта от 05.08.2024 № ОК/24_04 на выполнение работ по развитию АСУ ТК в части создания модуля «Сбора, ведения и анализа информации о нештатных ситуациях на транспорте». Развитие Модуля СЦ осуществлено в рамках контракта от 19.05.2025 № ОК/25_09 на выполнение работ по развитию Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК - – постановление Правительства Российской Федерации от 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 Федерального закона «Об электронной подписи»; - – постановление Правительства Российской Федерации от 08.06.2011 № 451 «Об инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг и исполнения государственных и муниципальных функций в электронной форме»; – постановление Правительства Российской Федерации от 30.01.2013 № 62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин»; – приказ ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации»; – приказ ФСТЭК России от 11.04.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений»; – приказ ФСБ России от 18.03.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений, с использованием шифровальных (криптографических) средств»; – приказ ФСБ России от 10.07.2014 № 378 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных с использованием средств криптографической защиты информации, необходимых для выполнения установленных Правительством Российской Федерации требований к защите персональных данных»; - 1.2. Шифр темы или номер контракта Присваивается Заказчиком по результатам организации закупочных процедур. 1.2.1. Предмет контракта Выполнение работ по развитию Модуля СЦ. Код по ОКПД2: 62.01.11.000 – услуги по проектированию и разработке информационных технологий для прикладных задач и тестированию программного обеспечения. Оказание услуг по технической поддержке Модуля СЦ. Код по ОКПД2: 62.02.30.000 – услуги по технической поддержке информационных технологий. Выполнение работ по развитию Модуля СЦ предусмотрено с учетом ключевых результатов (ОКР) Ведомственной программы цифровой трансформации Минтранса России на 2026-2028 (далее - ВПЦТ Минтранса России) в составе мероприятия № 103.002 «АСУ ТК» ИТ расхода 103.26.000005 «Развитие Информационно-аналитической системы регулирования на транспорте (АСУ ТК)»: · «Обеспечено информационное взаимодействие с Минобороны о происшествиях на транспортных объектах»; · «Обеспечена автоматизация формирования отчетов о нештатных ситуациях на транспорте, в том числе по данным внешних систем». Выполнение работ по технической поддержке АСУ ТК предусмотрено ВПЦТ Минтранса России в составе мероприятия № 103.002 «АСУ ТК» ИТ расхода 103.26.000021 «Эксплуатация Информационно-аналитической системы регулирования на транспорте (АСУ ТК)» - 1.3. Заказчик Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» (ФГБУ «СИЦ Минтранса России»). Адрес: 107078, Москва, Садовая-Спасская ул., д.18, стр. 1. Оператором Системы является Заказчик - Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» (ФГБУ «СИЦ Минтранса России) - 1.4. Подрядчик Определяется по результатам проведения конкурентной процедуры закупки в соответствии с требованиями Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (далее – Федеральный закон № 44-ФЗ) - 1.5. Основания для выполнения работ Работы осуществляются на основании следующих документов: – постановление Правительства Российской Федерации от 30.12.2003 № 794 «О единой государственной системе предупреждения и ликвидации чрезвычайных ситуаций»; – постановление Правительства Российской Федерации от 08.11.2013 № 1007 «О силах и средствах единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций»; – распоряжение Правительства Российской Федерации от 27.11.2021 № 3363-р «О Транспортной стратегии Российской Федерации до 2030 года с прогнозом на период до 2035 года»; – Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 26.08.2025 №ЕФ-3; – Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 27.11.2025 №ЕФ-23; - – приказ Минкомсвязи России от 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.7. Сроки начала и окончания работ Начало работ: с даты заключения Контракта. Окончание работ: не позднее 15.12.2026. Работы выполняются в соответствии с этапами. Сроки выполнения этапов работ по развитию и технической поддержке Модуля СЦ определяются Календарным планом. Календарный план, приведен в разделе 5 настоящего ТЗ - 2. ЦЕЛИ И НАЗНАЧЕНИЕ ВЫПОЛНЕНИЯ РАБОТ - 2.2. Назначение и цели развития и технической поддержки Модуля СЦ Назначение Модуля СЦ: – оперативный мониторинг нештатных и чрезвычайных ситуаций на транспорте ; – оповещение заинтересованных лиц и структур о нештатных и чрезвычайных ситуациях; – сбор, обработка и хранение данных о нештатных и чрезвычайных ситуациях. Целями развития Модуля СЦ являются: – расширение состава данных об оперативной обстановке на транспорте; – оптимизация процесса сбора данных об оперативной обстановке на транспорте; – повышение информированности пользователей за счет визуализация данных Модуля СЦ; – автоматизация процесса формирования отчетов о ЧС и нештатной ситуации на транспорте; – обеспечение информационного взаимодействия с заинтересованными организациями по вопросам ведения. - - Значение характеристики не может изменяться участником закупки - Целями оказания услуг по технической поддержке являются: – обеспечение информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы; – поддержание параметров функционирования ППО Системы, удовлетворяющих требованиям производственных процессов, включая их непрерывность; – обеспечение бесперебойного функционирования ППО и своевременное устранение сбоев и аварийных ситуаций в Системе; – своевременное устранение уязвимостей при выявлении таковых, в соответствии с требованиями к обеспечению информационной безопасности; – адаптация, конфигурирование, коррекция программного обеспечения в соответствии с изменениями нормативно-правовой базы и запросами уполномоченных сотрудников органов государственной власти, включая выполнение процедур тестирования и участие в обновлениях ППО на стендах Заказчика; – обеспечение сохранения работоспособности ППО в изменяемой среде эксплуатации; – ведение документации по настоящему ТЗ, инициирование и актуализация документации на Систему по результатам обработки запросов Заказчика и внесении соответствующих изменений в ППО. Модуль СЦ применяется в деятельности Министерства транспорта Российской Федерации, подведомственных агентств и службы и другими организациями в соответствии с соглашениями об информационном обмене - 2.1. Назначение АСУ ТК АСУ ТК предназначена для автоматизации и информационно-аналитического обеспечения процессов управления развитием транспортного комплекса Российской Федерации, обеспечения публичности деятельности органов государственного управления транспортным комплексом. Основными целями АСУ ТК являются: – повышение эффективности процессов управления функционированием и развитием транспортного комплекса на основе создания единой информационной среды и комплекса информационно-аналитических услуг на уровне органов государственного управления ТК; – повышение уровня безопасности ТК на базе получения полной, достоверной и оперативной информации о происходящих изменениях, своевременного выявления негативных тенденций и для принятия соответствующих мер по их устранению и ликвидации последствий - Основными задачами АСУ ТК являются: – автоматизация процессов прогнозирования развития транспортного комплекса и поддержки принятия управленческих решений; – автоматизация процессов мониторинга безопасности и устойчивости транспортного комплекса, управления в чрезвычайных и нештатных ситуациях; – автоматизация процессов управления программами и проектами развития и модернизации транспортного комплекса; – автоматизация процессов мониторинга состояния транспортного комплекса, в том числе с использованием набора ключевых показателей эффективности деятельности транспортного комплекса; – информационно-технологическая поддержка взаимодействия субъектов транспортного комплекса Российской Федерации, органов государственного управления и контроля, международных организаций на основе создания единой технологической среды взаимодействия и управления движением данных (и связанных с ними документов) в транспортном комплексе; – использование в процессах управления транспортным комплексом РФ современных технологий электронного документооборота и электронного обмена данными; – организация межведомственного электронного взаимодействия подразделений Министерства транспорта Российской Федерации, подведомственных агентств и службы с другими организациями - 3. ХАРАКТЕРИСТИКА ОБЪЕКТА АВТОМАТИЗАЦИИ - АСУ ТК осуществляет идентификацию и авторизацию посредством Единой системы идентификации и аутентификации (ЕСИА). Информационный обмен с внешними информационными системами осуществляется посредством СМЭВ 3 и СМЭВ 4. АСУ ТК развернута на вычислительных мощностях ГЦОД СИЦ Минтранса России - - Значение характеристики не может изменяться участником закупки - 3.2. Описание и текущее состояние объекта автоматизации Модуля СЦ Объектом автоматизации является процесс организации мониторинга информации о НС и ЧС на транспорте. Предметом деятельности Учреждения являются следующие функции: – информационное обеспечение в области транспортной безопасности, защиты населения и территорий от чрезвычайных ситуаций природного и техногенного характера в транспортном комплексе; – подготовка справочных материалов при угрозе возникновения и возникновении чрезвычайных ситуаций и иных происшествий в транспортном комплексе; – взаимодействие и обмен оперативной информацией с органами управления Единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций; – организация оперативного мониторинга обстановки на объектах транспорта при угрозе и возникновении чрезвычайных ситуаций и иных происшествий. Перечень компонентов Модуля СЦ и выполняемые ими функции представлены в Таблице 2 - Таблица 2. Перечень компонентов Модуля СЦ и их функции № п/п Компонент Выполняемые функции 1 Регистрация событий – ведение карточки события; – удаление комментария; – динамическое отображение существующих событий в заданном радиусе и за заданный период; – возможность автоматической проверки вводимых данных в части количества пострадавших; – отображение карточки ОТИ, ТС в соответствии с ФЗ Реестр объектов; – сохранение и отображение версии карточки события; – привязка события к координатам по картографической основе; – указание признака выполнения действия по отработке события; – перевод статуса события; – закрытие карточки события; – публикация информации о событии в канале мессенджера; – возможность перехода из карточки события на картографическую основу для просмотра местоположения события 2 Визуализация – отображение событий на картографической основе в виде пиктограмм; – масштабирование карты; – отображение краткой карточки события при выборе события на картографической основе; – отображение списка событий; – отображение карточки события; – отображение журнала действий пользователя; – отображение дополнительной информации (текстовая информация и приложенные файлы); – отображение справки о событиях и отчета о событиях; – отображение фильтров и количества отфильтрованных объектов; – отображение результатов поиска; – отображение статистики по событиям на экране; – возможность создания события с картографической основы; – отображения картографических слоев в зависимости от примененных фильтров; – возможность настройки шага картографической сети; – возможность настройки географической точки центра карты; – отображение количества непрочитанных сообщений; – возможность перехода к детальной карточке события из краткой карточки события при выборе события на картографической основе - 3.1. Описание объекта автоматизации АСУ ТК Объектом автоматизации являются процессы основной и обеспечивающей деятельности, направленные на управление транспортным комплексом, в том числе, процессы информационного взаимодействия с другими организациями и субъектами транспортного комплекса. АСУ ТК относится к государственным информационным системам, а также к информационным системам персональных данных и значимым объектам критической информационной инфраструктуры Российской Федерации. АСУ ТК соответствует требованиям, предъявляемым к: – ГИС второго класса защищенности в соответствии с приказом ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах»; – ИС персональных данных при обеспечении третьего уровня защищенности персональных данных в соответствии с требованиями постановления Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»; – значимым объектам КИИ Российской Федерации второй категории значимости с постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении Правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений». Модуль СЦ является подсистемой АСУ ТК. Перечень платформенных решений и функциональных задач АСУ ТК представлен в Таблице 1 - Таблица 1 – Перечень платформенных решений и функциональных задач АСУ ТК № Наименование подсистемы/ функциональной задачи/ модуля Назначение 1 Подсистема сбора данных и централизованного хранилища данных Подсистема обеспечивает выполнение сбора данных в АСУ ТК, и в т. ч., в рамках функциональных задач «Формирование и ведение межрегионального транспортного баланса пассажирских перевозок в дальнем (межрегиональном) сообщении» и «Формирование и ведение транспортного паспорта региона» 2 Подсистема информационного взаимодействия Подсистема информационного предназначена для обеспечения информационного взаимодействия подсистем АСУ ТК, а также, взаимодействия АСУ ТК с АС федеральных органов исполнительной власти 3 Подсистема ведения нормативно-справочной информации и метаданных Подсистема предназначена для автоматизации функций формирования и актуализации справочников, классификаторов, реестров и регистров, необходимых для обеспечения информационной поддержки пользователей НСИ и интеграции подсистем АСУ ТК в части применения НСИ 4 Модуль СМЭВ Модуль взаимодействия со СМЭВ представляет собой набор сервисов взаимодействия: сервис синхронного взаимодействия и сервис отправки, осуществляющих дополнительную обработку сообщений, отправляемых в СМЭВ и принимаемых из СМЭВ 5 Геоинформационная подсистема Программное обеспечение геоинформационной подсистемы предназначено для обеспечения смежных подсистем АСУ ТК возможностью работы с картографической информацией, в том числе, отображения на электронных картах объектов транспортной инфраструктуры и получения информации о местоположении, характеристиках контролируемых транспортных объектов 6 Подсистема информационного портала АСУ ТК Подсистема информационного портала предназначена для отображения и входа в функциональные задачи АСУ ТК 7 Подсистема технического портала АСУ ТК Подсистема технического портала АСУ ТК предназначена для управления заявками пользователей и технологического документооборота заявок - 3 Информирование – ведение справочника способов оповещения (веб-интерфейс, мессенджер); – формирование сценария выполнения оповещения (настройка условий, способа, параметров оповещения); – выполнение оповещений пользователей 4 Отчетность – формирование отчета и справки о событиях; – фильтрация событий для выгрузки в справку о событиях или в отчет о событиях 5 Администрирование – ведение ролей пользователей; – ведение учетных данных пользователей; – ведение справочника организаций; – ведение справочника групп системы мгновенного обмена сообщениями; – выполнение исходящего звонка на контактный телефонный номер организации; – формирование матрицы эскалации событий Архитектура Модуля СЦ представлена на рисунке 1. Рисунок 1. Архитектура Модуля СЦ - 3.3. Состав используемого ПО Модуля СЦ Программная архитектура Модуля СЦ разработана как трехуровневая клиент-серверная архитектура. Архитектура включает в себя следующие уровни: • уровень представления – презентационный уровень, обеспечивающий взаимодействие с пользователя с клиентскими приложениями с использованием веб-браузера («тонкий» клиент); • уровень приложений – реализован в виде сервисов, обеспечивает обработку запросов, поступающих от клиентских приложений, формирование ответов на запрос в доступном пользователю виде (формирование пользовательских интерфейсов); • уровень хранения данных – реализуется как сервер БД и обеспечивает хранение и целостность хранимых данных, создание резервных копий, ведение журнала транзакций, восстановление данных после сбоев. Программная архитектура Модуля СЦ включает в себя сервисы и интерфейсы, указанные в Таблице 3. Таблица 3. Программная архитектура Модуля СЦ Программный сервис/интерфейс Технологии реализации Уровень представления Интерфейс пользователя и администратора (front-end) Javascript Уровень приложений Сервис (GateWay) Kotlin Сервис геокодирования (geocoding-service) Kotlin Сервис уведомлений (notifiсation-service) Kotlin Сервис работы с файлами (file-service) Kotlin Сервис отчетности (report-service) Kotlin Сервис управления событиями (event-service) Kotlin Сервис информирования через мессенджер (messenger-notifier) Python Сервис внешних интеграций (integration-service) Сбор информации из внешних систем и сервисов Брокер сообщений Kafka Уровень хранения данных Файловое хранилище MinIO S3 СУБД Postgres Pro Enterprise - 3.4. Информационное взаимодействие программных сервисов и интерфейсов Модуля СЦ Объект автоматизации функционирует в распределенной информационной среде. Обмен данными осуществляется по защищенным каналам связи (в том числе ведомственным сетям передачи данных). Источники информации включают: · внешние автоматизированные системы (органов государственной власти); · внутренние базы данных (реестры объектов транспортной инфраструктуры, паспорта регионов и пр.); · оперативная информация от персонала, поступающая через автоматизированные рабочие места (АРМ) и мобильные устройства. 3.4.1. Взаимодействие Модуля СЦ со смежными подсистемами АСУ ТК Модуль СЦ входит в состав АСУ ТК и взаимодействует со следующими ее функциональными задачами и подсистемами: · Функциональной задачей «Формирование и ведение единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации» (ФЗ «Реестр объектов»); · Геоинформационной подсистемой АСУ ТК (П-ГИС); · Подсистемой ведения нормативно-справочной информации и метаданных (П-НСИ); · Подсистемой сбора данных и централизованное хранилище данных (П-СД); · Подсистемой информационного взаимодействия (П-ИВ). 3.4.2. Взаимодействие с внешними информационными системами Список внешних информационных систем, с которыми осуществляется взаимодействие Модуля СЦ: · ЕСИА; · мессенджер; · Яндекс Геокодер; · Информационная система «Централизованная система сбора информации систем-112»; · ПВК «Поиск-Море», АИС РПТ; · облачная АТС - 8 Подсистема проектного архива АСУ ТК Подсистема проектного архива АСУ ТК предназначена для автоматизации деловых процессов должностных лиц Министерства транспорта Российской Федерации, подведомственных агентств и службы, в том числе, и процессов информационного взаимодействия внутреннего и внешнего характера 9 ФЗ «Реестр объектов» Функциональная задача предназначена для формирования и ведения единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации 10 ФЗ «СТП» Функциональная задача предназначена для организации информационно-аналитической поддержки процессов территориального планирования Российской Федерации в области федерального транспорта 11 ФЗ «МРТБ ПП» Функциональная задача предназначена для формирования и ведения межрегионального транспортного баланса пассажирских перевозок в дальнем (межрегиональном) сообщении 12 ФЗ «МДД» Функциональная задача предназначена для осуществления мониторинга дорожного движения 13 ФЗ «ТПР» Функциональная задача предназначена для формирования и ведения транспортного паспорта региона 14 ФЗ «Данные по грузообороту» Функциональная задача предназначена для обеспечения подсистем и пользователей АСУ ТК данными по грузообороту между Российской Федерацией и зарубежными странами 15 ФЗ «МЖТ» Функциональная задача предназначена для осуществления мониторинга железнодорожного транспорта 16 ФЗ «МГМП» Функциональная задача предназначена для осуществления мониторинга грузопотоков в морских портах с целью формирования единой цифровой среды мониторинга и планирования перевозок в/из портов Дальнего Востока - 17 Модуль ГЭТ Модуль предназначен для получения, хранения данных инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по отдельно взятому предприятию-перевозчику. Формирования отчетов об инвентаризации с детальными данными по каждому разделу инвентаризации с маршрутизацией в муниципалитет / регион / Минтранс. Содержит агрегированные данные инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по всем перевозчикам, относящихся к данному муниципалитету. Формирует сводный отчет по муниципалитету по каждому разделу инвентаризации с маршрутизацией в регион / Минтранс. Формирует агрегированные данные инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по всем перевозчикам, относящиеся к данному региону и по всем муниципалитетам, относящимся к данному региону. Аналитические и статистические данные о состоянии ГЭТ региона. Содержит данные о видах транспорта, цифровых транспортных сервисах и платежных инструментах Региона. Формирует сводный отчет по каждому разделу инвентаризации с маршрутизацией в Минтранс. Формирует агрегированную статистику и аналитику по всем регионам страны в разрезе транспортных средств, маршрутов, пассажиропотоков, инфраструктуры ГЭТ. Данные о рейтинге регионов и перевозчиков на основании выбранных параметров, документооборот с участниками Системы: получение подписанных печатных форм, их утверждение, возврат на доработку. 18 Модуль iМинтранс Модуль создан для отчета по ключевым показателям транспортного комплекса России (Отраслевые и статистические показатели, исполнение бюджета, исполнение поручений, аналитика СМИ, происшествия по видам транспорта). 19 Модуль СЦ Модуль СЦ предназначен для оперативного мониторинга нештатных ситуаций транспортной отрасли, оповещения заинтересованных лиц и структур и предоставления данных о нештатных ситуациях - 3.5. Требования к эксплуатации Применяемое в Системе программное обеспечение, программно-аппаратные и аппаратные комплексы должны соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации» - 4. ТРЕБОВАНИЯ К МОДУЛЮ СЦ - 4.5.9.4. Подрядчик подтверждает, что обладает всеми правами на передачу Заказчику исключительных прав в соответствии с требованиями настоящего раздела Технического задания. В случае, если к Заказчику по вине Подрядчика будут предъявлены претензии в этой части, иски третьих лиц, связанные с нарушением их прав, Подрядчик принимает на себя такие претензии и иски и возмещает Заказчику все расходы и весь ущерб, понесенный в связи с ними. 4.5.9.5. Подрядчик обязан согласовать с Заказчиком необходимость использования при выполнении работ охраняемых результатов интеллектуальной деятельности, права на которые принадлежат Подрядчику или третьим лицам. 4.5.9.6. В случае, если при выполнении Работ используется готовое программное обеспечение (платформа, подсистема, СУБД и т.д.), которое становится частью (компонентом) Системы, Заказчику передаются полные исключительные права, или неисключительные права (путем заключения лицензионного/сублицензионного договора/соглашения) на такое программное обеспечение со следующими возможностями: – права передаются бессрочно (на весь срок действия исключительных прав); – территория действия Российская Федерация; – должно быть обеспечено право Российской Федерации (в лице Заказчика) передавать, дорабатывать, распространять, развивать результаты работ, созданные в процессе исполнения Контракта, а также перерабатывать такое программное обеспечение. Лицензионное (сублицензионное) соглашение (договор), Акт передачи прав, подписанные Подрядчиком, согласие правообладателя, оформленное в соответствии с положениями Гражданского кодекса Российской Федерации (в случае, если Подрядчик не является правообладателем такого программного обеспечения), инструкция по инсталляции, руководство администратора, руководство пользователя передаются Заказчику в сроки, установленные Техническим заданием для соответствующего функционала Системы - - Значение характеристики не может изменяться участником закупки - Лицензионное (сублицензионное) соглашение (договор) не может возлагать на Заказчика какие-либо обязанности (в т.ч. в части конфиденциальности, предоставления отчетности), не предусмотренные Контрактом. 4.5.9.7. Передача Заказчику исключительных прав, или простых (неисключительных) прав не может повлечь увеличение стоимости Контракта и/или изменение иных существенных условий Контракта. 4.5.9.8. Функциональность Модуля СЦ передается в объеме и в сроки, установленные Техническим заданием. 4.5.9.9. Нарушение условий настоящего раздела Технического задания, в т.ч. отсутствие соответствующего лицензионного (сублицензионного) соглашения (или договора), либо предоставление лицензионного (сублицензионного) соглашения (или договора), не соответствующего требованиям действующего законодательства Российской Федерации или требованиям Контракта, является нарушением существенных условий Контракта. 4.5.9.10. В случае, если в соответствии с пунктом 4.5.9.6 Заказчику передается исключительное право, такая передача осуществляется в порядке, установленном Гражданским кодексом Российской Федерации. 4.5.9.11. В случае, если при выполнении Работ положения пунктов 4.5.9.5-4.5.9.6 не применялись, Подрядчик в составе отчетной документации предоставляет об этом декларацию в свободной форме. Декларация должна содержать сведения о полном соответствии результата Работ требованиям Контракта, а также о неприменении при выполнении работ готового программного обеспечения (платформ, подсистем, СУБД и т.д.), которое стало частью (компонентом) Системы - 4.2.4.1. Требования к технической реализации компонента «Интерактивная карта» При реализации компонента «Интерактивная карта» должны учитываться требования, указанные ниже. 4.2.4.1.1. Требования к отображению элементов Повторяющихся элементы карты (ТС, ОТИ, события и пр.) должны отрисовываться с использованием аппаратного создания экземпляров объектов на пользовательском устройстве (WebGL/WebGPU)). Отрисовка каждого объекта отдельным запросом не допускается, должна обеспечиваться возможность одновременного отображения не менее 5 000 объектов без снижения производительности (30 кадров в секунду на тестовой конфигурации). 4.2.4.1.2. Уровни детализации объектов Для управления отображением сложных объектов должно быть создано не менее 3-х уровней детализации, отображаемых при изменении масштаба с возможностью автоматического переключения между уровнями. Все отображаемые объекты должны масштабироваться с учетом разрешения экрана пользователя с сохранением качества детализации. 4.2.4.1.3. Полигональная оптимизация и текстурирование При реализации компонента «Интерактивная карта» должна обеспечиваться технология рельефного тестурирования объектов. Не должны использоваться высокополигональные трехмерные модели. Все повторяющиеся элементы должны генерироваться единоразово и повторно использоваться при последующих отображениях. 4.2.4.1.4. Управление памятью Требуется реализовать потоковую загрузку на устройство пользователя элементов карты и текстур. Загрузка данных целиком при старте приложения не допускается. Необходимо реализовать механизм очистки памяти от элементов, которые находятся вне области видимости камеры в течение заданного времени. 4.2.4.1.5. Требования к взаимодействию пользователя с интерфейсом компонента «Интерактивная карта» Программная реализация механизмов управление камерой (масштабирование и навигация) должна быть выполнена с поддержкой технологии WebAssembly (WASM). Элементы управления должны являться неотъемлемой частью интерактивной карты. - 4.2.5. Развитие компонента администрирования (3 очередь) Должна быть выполнена доработка ролевой модели. Ролевая модель должна обеспечивать управление доступом к отдельным объектам Модуля СЦ и их элементам (атрибутам) с разграничением по видам транспорта, регионам и пр., в частности: – определение набора конкретных действий, доступных пользователям (выполняемых над объектом доступа, например, удаление записи, редактирование записи, формирование отчета и др.); – реализация возможности объединения пользователей в группы; – определение прав доступа для групп пользователей; – реализация интерфейса визуальной настройки прав доступа пользователей к объектам Модуля СЦ - 4.3.1.1. Требования к составу и содержанию услуг третьего уровня технической поддержки Оказание услуг по технической поддержке Системы осуществляется в рамках этапов в соответствии с календарным планом. Подрядчик в течение 5 рабочих дней с даты заключения Контракта должен предоставить со своей стороны, а Заказчик со своей стороны Матрицу ответственных за взаимодействия в соответствии с Приложением 1 к Регламенту оказания услуг по третьему уровню технической поддержки Модуля СЦ (далее – Регламент, Приложение В). Подрядчик в течение 10 рабочих дней с даты заключения Контракта должен провести мероприятия по организации третьего уровня технической поддержки в соответствии с Регламентом. Услуги по третьему уровню технической поддержки Модуля СЦ должны включать: – организацию Подрядчиком третьего уровня технической поддержки; – информационно-консультационную поддержку работников Заказчика; – решение инцидентов, связанных с работой ППО; – адаптационное, конфигурационное и коррекционное сопровождение Модуля СЦ (в рамках действующих программных модулей и функциональности); – устранение уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности - 4.3.1.2. Требования к общему порядку оказания услуг Техническая поддержка Модуля СЦ должна быть организована на трех уровнях: – первый и второй уровни технической поддержки организуется Заказчиком; – третий уровень технической поддержки организуется Подрядчиком. Перечень действий на каждом уровне технической поддержки указан в Таблице 5: Таблица 5 – Перечень действий на каждом уровне технической поддержки Уровень технической поддержки Доступные действия Условия передачи задачи на следующий уровень Первый уровень технической поддержки (далее – 1-й уровень) – принимает обращения (заявки) пользователей Модуля СЦ и работников Заказчика; – регистрирует обращения в Модуле СЦ регистрации обращений; – присваивает уникальный идентификационный номер, классифицирует обращения; – самостоятельно решает обращения, которые связаны с недостаточной квалификацией пользователей или настройками в рамках своей компетенции; – взаимодействует с пользователями Модуля СЦ при решении проблемы Передает обращение на второй уровень поддержки в случае невозможности решения на своем уровне Второй уровень технической поддержки (далее – 2-й уровень) – принимает обращения от 1-го уровня; – уточняет классификацию обращения в результате дополнительного анализа; – самостоятельно решает обращения в рамках своей компетенции; – осуществляет техническую и консультационную поддержку Модуля СЦ; – взаимодействует с сотрудниками 1-го и 3-го уровня и пользователями Модуля СЦ; – формирует заявки для 3-го уровня и контролирует исполнение Передает обращение на третий уровень поддержки в случае невозможности решения на своем уровне Третий уровень технической поддержки (далее – 3-й уровень) – принимает обращения от 2-го уровня; – обеспечивает выполнение требований, предъявляемых Контрактом и настоящим Техническим заданием к Услугам, оказываемым Подрядчиком Все поступающие обращения должны быть исполнены Подрядчиком - Работы по устранению неисправности приостанавливаются (по согласованию с Заказчиком) в следующих случаях: – если Подрядчиком в результате диагностики выявлено, что неисправность находится в зоне ответственности Заказчика. Подрядчик информирует Заказчика о выявленной неисправности в зоне его ответственности по согласованным каналам связи; – требуется действие со стороны Заказчика – до момента выполнения данного действия Заказчика. Заказчик информируется о необходимых действиях по согласованным каналам связи; – отсутствие возможности связаться со специалистами Заказчика, участие которых необходимо для устранения неисправности; – требуется доставить оборудование на объект – до момента доставки и установки оборудования. В случаях, представленных выше, время приостановки работ не входит в учет продолжительности устранения неисправности. Учет времени устранения неисправности Подрядчиком считается с момента назначения Инцидента специалисту Подрядчика, ответственному за оказание услуг технической поддержки 3 уровня. Подтверждение необходимости приостановления работ находится в зоне ответственности Подрядчика. Приостановление сроков выполнения задач в соответствии с настоящим пунктом подтверждается Заказчиком по мотивированному обращению Подрядчика в СРО, основанному на данных диагностики или на иных фактических обстоятельствах - В случае непринятия Подрядчиком необходимых мер по информированию Заказчика (отсутствие надлежащего обращения от Подрядчика или отсутствие уведомления о необходимости осуществления каких-либо действий Заказчиком) не может являться основанием для приостановления работ по устранению неисправности. В отдельных случаях Подрядчику может потребоваться выполнение технологических работ для устранения причин неисправности или недопущения повторения их в будущем. Для обеспечения устранения неисправности Модуля СЦ Заказчиком проводится классификация в соответствии с приоритетами по степени срочности их устранения. Продолжительность устранения неисправности, а также периодичность информирования Подрядчиком Заказчика о ходе устранения неисправности, определены в Регламенте оказания услуг. При подаче обращения (заявки) наивысшего приоритета через СРО Заказчик должен дополнительно проинформировать службу поддержки Подрядчика о созданном обращении (заявки) по телефону уполномоченного сотрудника Подрядчика. При этом временем подачи обращения (заявки) считается время подачи обращения (заявки) через СРО - 4.3.6.4.1. Требования к проведению изменений Основанием для внесения изменений является запрос от Заказчика. Все активности по внесению изменений должны быть согласованы с Заказчиком, а действия Подрядчика при оказании данной услуги должны быть зафиксированы. В рамках данного Технического задания изменениями считаются локальные доработки функционала Модуля СЦ, которые не должны приводить к необходимости выполнения дополнительных аттестационных испытаний или переаттестации АСУ ТК в соответствии с п. 33 приказа от 29.04.2021 № 77 «Об утверждении Порядка организации и проведения работ по аттестации объектов информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну». При необходимости внесения изменений в Модуль СЦ, не связанных с критичным инцидентом, существенно нарушающим работоспособность Модуля СЦ, Заказчик направляет Подрядчику обращение (заявку), в котором излагает суть изменения, которое требуется внести в Модуль СЦ. Исполнитель, в течение 3 (трех) рабочих дней с момента поступления соответствующего обращения (заявки), оценивает техническую возможность реализации запрашиваемого изменения и варианты реализации. По итогу проведения оценки Подрядчик направляет Заказчику заключение о возможности реализации данного изменения с описанием возможных вариантов реализации и согласует с Заказчиком проведение данного изменения - При проведении работ по изменению и адаптации Подрядчик должен: – обеспечить выполнение требований безопасной разработки программного обеспечения; – обеспечить предварительное проектирование технических решений и согласование с Заказчиком проекта реализации изменения; – использовать семантическое версионирование (SemVer) в работе, передать Заказчику все артефакты разработки (исходный код и сторонние библиотеки, конфигурации, сборочные и собранные образы и др.); – подготовить полноценное описание функционала, включенного в релиз, с необходимыми схемами и пояснениями к обновлению на стендах Заказчика; – обеспечить тестирование разработанного функционала на стендах Заказчика силами Подрядчика; – решение о переносе измененного ППО на продуктивный стенд принимается Заказчиком по итогу результатов проведенного тестирования; – обеспечить техническое сопровождение процедуры тестирования ППО и переноса измененного ППО на продуктивный стенд Заказчика; – обеспечить экстренное внесение соответствующих изменений в случае выявления некорректной работы продуктивного стенда Заказчика после проведения обновления по итогам разработанного изменения в кратчайшие сроки; – актуализировать при необходимости комплект эксплуатационной документации: o руководство пользователя; o руководство администратора; o иные документы (при необходимости). Результат выполнения изменений должен быть отражен в Отчете по оказанию услуг. Типы и приоритеты изменений могут быть скорректированы в процессе оказания услуг исключительно по согласованию с Заказчиком - 4.1. Требования к структуре Модуля СЦ В процессе работ по развитию Системы должны сохраниться основные требования к построению архитектуры Системы в соответствии с принципами трехуровневой архитектуры: 1. уровень хранения данных или уровень базы данных (сервер СУБД); 2. уровень сервера приложений (сервер аналитической обработки); 3. презентационный уровень, обеспечивающий взаимодействие с клиентскими приложениями. В состав Системы должны входить следующие основные компоненты: 4. сервер баз данных; 5. сервер приложений; 6. веб-сервер. Сервер баз данных должен обеспечивать хранение и целостность хранимых данных, создание резервных копий, ведение журнала транзакций, восстановление данных после сбоев. Сервер приложений должен обеспечивать обработку запросов, поступающих от клиентских приложений (через веб-сервер), формирование ответов на запрос в доступном пользователю виде (формирование пользовательских интерфейсов). Веб-сервер должен обеспечивать взаимодействие с оператором и внешними системами по HTTP / HTTPS протоколу в режиме «запрос-ответ» (получения запросов от пользователя и передачи ответа в виде соответствующей информации, обработанной серверами приложений). Взаимодействие Системы с пользователем должно отвечать требованиям модели «тонкого клиента» (т.е. представлять на стороне клиента (пользователя) лишь графический пользовательский интерфейс). Все составляющие Системы должны использовать единую методологию и отвечать единым принципам взаимодействия, надежности и управления. Перечень компонентов Модуля СЦ представлен в Таблице 4. Таблица 4. Перечень компонентов Модуля СЦ, в отношении которых выполняются работы по развитию № п.п. Наименование компонента Модуля СЦ Раздел ТЗ 1 Компонент регистрации событий 4.2.1. 2 Компонент отчетности 4.2.2 3 Компонент визуализации 4.2.3 4 «Интерактивная карта» (компонент создается) 4.2.4 5 Компонент администрирования 4.2.5 - 4.2. Требования к дорабатываемым функциям модуля СЦ 4.2.1. Развитие компонента регистрации событий (1 очередь) Должны быть выполнены следующие доработки: – обеспечение логирования действий пользователя, связанных с карточкой события; – доработка объектной модели в части создания новых типов сущностей (карточек) с учетом реализуемых интеграций с информационными ресурсами (силы и средства предупреждения и ликвидации ЧС и нештатных ситуаций на транспорте, ТС, ограничения воздушного пространства, неблагоприятные и опасные природные явления); – реализация механизма установления связи между сущностями в Модуле СЦ автоматизированным и ручным способами (события, природные явления, силы и средства предупреждения и ликвидации ЧС и нештатных ситуаций на транспорте, ограничения воздушного пространства, ОТИ, ТС и др.); – отображение в карточке установленных связей между сущностями. - 4.2.2. Развитие компонента отчетности (3 очередь) Должна быть обеспечена автоматизация процессов формирования отчетов о ЧС и нештатных ситуациях на транспорте, в т.ч. на основе данных из внешних систем. Включает следующие доработки: – разработка шаблонов отчетов в различных форматах (табличный, текстовый); – реализация выбора фотоматериалов для включения в справку; – форматирование содержимого справок с учетом правил русского языка в отношении окончаний слов (в зависимости от падежа, склонения, числа и рода); – автоматизированное формирование выводов к содержимому справки на основе настраиваемых критериев; – создание интерфейса выбора параметров (фильтрации) для формирования отчетов: o состав полей для включения в отчёт; o настройка диапазонов значений характеристик и дат; o порядок отображения полей; o настройка заголовка. – реализация способа подготовки отчётов в асинхронном режиме (очереди); – реализация интерфейса компонента формирования отчетности для отображения очереди формирования отчетов и статусов их подготовки; – экспорт отчётов в форматы xlsx, csv и справок в форматы pdf, docx. Необходимо разработать не менее 10 шаблонов отчетов и/или справок. Перечень, структура и содержание шаблонов должны быть согласованы с Заказчиком на этапе технического проектирования. - 4.2.3. Развитие компонента визуализации (2 очередь) В рамках развития компонента визуализации должны быть выполнены следующие доработки, обеспечивающие: – вывод перечней (списков) сил и средств предупреждения и ликвидации ЧС и нештатных ситуаций на транспорте с отображением мест их постоянного размещения (дислокации) на карте, включая: o отображение зон ответственности на карте; o возможность их фильтрации (по видам транспорта, регионам и пр.); o реализацию инструмента расчета расстояния (с использованием сети автомобильных и железных дорог) между местом события и местами дислокации сил и средств, а также вывода маршрутов на карте; – отображение зон (полигонов) с установленными ограничениями движения в воздушном пространстве на карте; – отображение термических точек; – реализация возможности отображения данных из паспорта региона, отображаемого в модуле iМинтранс (модуль АСУ ТК); – отображение краткой карточки сущностей и ОТИ (краткой информации и/или динамических характеристик объекта) при выборе объекта на карте с возможностью перехода в полную карточку сущности и ОТИ; – отображение данных от Росгидромета, предусматривающих: o отображение неблагоприятных и опасных природных явлений на карте (с заданным периодом обновления данных); o управление отображением явлений на карте, включая настройку состава отображаемых объектов, поиск, фильтрацию, с использованием соответствующей панели управления; o выведение краткой карточки явления при выборе объекта, с возможностью перехода в полную карточку объекта - – отображение на карте связанных сущностей и ОТИ; – реализация функции выбора темного и светлого стилей отображения элементов интерфейса, карточек сущностей, картографической основы и объектов, отображаемых на карте; – реализация механизма для выбора картографической основы в одном из распространенных форматов WMTS, TMS, MVT и др. Должна быть предусмотрена возможность настройки перечня картографических основ и параметров доступа к ним; – настройка базового набора дашбордов, содержащих преднастроенные виджеты о количестве событий в разрезе видов транспорта с возможностью перехода к исходным данным (карточкам событий, ОТИ и т.д.), с фильтрацией по параметрам. Параметры фильтрации должны быть определены на этапе технического проектирования. Должно быть обеспечено автоматическое и принудительное обновление данных, отображаемых на дашбордах - 4.2.4. Создание компонента «Интерактивная карта» (2 очередь) В составе создаваемого компонента должны отображаться данные, доступные в компоненте визуализации. Требования к интерфейсу интерактивной карты: – интерактивная карта должна быть представлена в виде объемной карты с учетом макетов, представленных в Приложении А к ТЗ; – интерфейс должен корректно отображаться на экранах мониторов (разрешение Full HD 1920?1080), телевизоров (разрешение 4К 3840?2160), жидкокристаллических панелей для видеостены, используемой Заказчиком, с параметрами каждой панели: диагональ 55 дюймов, разрешение 1920x1080; – интерфейс должен корректно отображаться на планшетных устройствах с диагональю экрана 10-12 дюймов, конкретные требования должны быть уточнены на этапе технического проектирования; – должна быть обеспечена кластеризация и генерализация отображения объектов на карте при изменении масштаба; – должно быть обеспечено отображение основных характеристик объектов при выборе их на карте; – должно быть обеспечено управление отображением слоев на карте; – должна быть обеспечена настройка цветовой индикации отображаемых объектов транспортной инфраструктуры; – должно быть обеспечено отображение легенды карты, содержащей отображаемые объекты на карте; – должна быть обеспечена возможность одновременного отображения не менее 5 000 ОТИ и ТС на карте. - На интерактивной карте должны быть отображены подвижные объекты совместно с объектами транспортной инфраструктуры (ОТИ), включая следующие возможности: § отображение местоположения транспортных средств (воздушный, водный и автомобильный транспорт) на карте в режиме реального времени (с заданным периодом обновления данных); § отображение маршрутов движения всех ТС за выбранный период времени, в том числе с использованием эффектов анимации; § отображение маршрутов движения ТС, связанных с карточкой события: ТС, являющихся участниками события, и ТС, находящиеся в заданном радиусе от события; § управление отображением сущностей и ОТИ на карте, включая настройку состава отображаемых объектов, поиск, фильтрацию, с использованием соответствующей панели управления и наглядным представлением результатов; § автоматическое изменение вида отображения объектов (цветовая индикация) по заданным условиям (например, при достижении критических значений параметров, характеризующих функционирование объекта); Должна обеспечиваться производительность обновления изображения на экране в 30 кадров в секунду на тестовой конфигурации пользовательского устройства (модель Бештау AIO2402/B560, входящая в Реестр российской промышленной продукции под номером 10394100 или аналог) при одновременном отображении не менее 5 000 объектов и 200 уникальных моделей объектов. Макеты интерфейсов Модуля СЦ должны быть предварительно согласованы с Заказчиком и разработаны с учетом требований ГОСТ Р ИСО 9241-161-2016 «Элементы графического пользовательского интерфейса» - Технические меры по обеспечению надежности должны предусматривать: – резервирование критически важных компонентов и данных Системы и отсутствие единой точки отказа; – использование программного резервирования (программной избыточности); – изменение конфигурации используемых средств и применение специализированного ПО, обеспечивающего высокую надёжность. Организационные меры по обеспечению надежности должны быть направлены на минимизацию ошибок пользователей (а также обслуживающего персонала при эксплуатации и проведении работ по обслуживанию), минимизацию времени ремонта или замены вышедших из строя компонентов за счёт: – обеспечения для обслуживающего персонала требуемого уровня квалификации; – регламентации и нормативного обеспечения выполнения работ обслуживающим персоналом; – своевременной диагностики неисправностей. Расчетное значение коэффициента доступности Модуля СЦ должно составлять не менее 0,95. - 4.5.3. Требования по диагностированию Модуля СЦ Диагностирование Модуля СЦ должно осуществляться путем анализа записей в системных журналах СУБД, операционных систем серверов, а также с помощью встроенных средств диагностирования общего программного обеспечения Модуля СЦ. Диагностированию подлежат: – сбои и нарушения функционирования технического обеспечения (серверов) Модуля СЦ; – сбои и нарушения функционирования системного программного обеспечения серверов, используемых для работы Модуля СЦ; – сбои и нарушения функционирования прикладного программного обеспечения серверов, используемых для работы Модуля СЦ; – случаи недоступности (отсутствия ответа) или некорректные ответы внешних систем; – сбои и нарушения функционирования СУБД; – сбои при выполнении регламентных операций резервного копирования. При возникновении аварийных ситуаций либо ошибок в программном обеспечении диагностические инструменты должны позволять сохранять набор информации, необходимой для идентификации и устранения проблемы. Модуль СЦ и ее компоненты должны обеспечивать возможность диагностики своей работоспособности с возможностью интеграции с модулем мониторинга АСУ ТК. Набор передаваемых журналов и метрик должен быть определен на этапе технического проектирования - 4.5.4. Требования к надежности Должно быть предусмотрено сохранение работоспособности Модуля СЦ при некорректных действиях пользователя и сохранение целостности данных при нештатном завершении работы Модуля СЦ (отказ рабочей станции, потеря сетевого доступа и т.п.). Модуль СЦ должен предоставлять механизмы обеспечения сохранности данных через применение процедур резервного копирования и восстановления, описанных в документации на Систему. Ключевые показатели надежности информационной системы — допустимое время на восстановление работоспособности Модуля СЦ (RTO - recovery time objective) и/или допустимый интервал времени потери изменений в данных при сбоях/отказах (RPO – recovery point objective) должны быть определены Подрядчиком и согласованы с Заказчиком на этапе технического проектирования - 4.2.6. Взаимосвязи с внешними автоматизированными системами (1 очередь) Способы взаимодействия с внешними информационными системами должны быть определены на этапе технического проектирования. Должны быть выполнены следующие доработки: – интеграции с информационными ресурсами в целях получения данных о движении подвижных ТС (воздушные суда, суда водного транспорта); – интеграция с информационным ресурсом в целях получения данных о событиях на железнодорожном транспорте. Реализация интеграций должна включать проектирование и реализацию интеграционных механизмов обмена данными с учетом доступных вариантов реализации, обеспечение защищенных способов взаимодействия, настройку отображения отдельных данных на карте (настройка слоев). Взаимодействия, имеющие каналы связи, выходящие за пределы контролируемой зоны взаимодействующих систем, считаются защищенными, если для их защиты используются программные и/или программно-аппаратные шифровальные (криптографические) средства, сертифицированные ФСБ России (далее – СКЗИ). Выбор СКЗИ, схемы подключения и требуемого класса криптостойкости должен производиться в соответствии с Техническими условиями на подключение к информационным ресурсам ФГБУ «СИЦ Минтранса России» и инструкциями по подключению пользователей к ресурсам инфраструктуры Головного центра обработки данных, утвержденных приказом директора ФБГУ «СИЦ Минтранса России» от 24.05.2024 № 21-ОД - 4.3. Требования к оказанию услуг по технической поддержке Модуля СЦ 4.3.1. Общие требования к оказанию Услуг Техническая поддержка Модуля СЦ должна осуществляться с учетом требований постановления Правительства Российской Федерации от 06.07.2015 N 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации». Подрядчик обязан выполнять требования законодательства в сфере защиты информации, требования по защите информации, информационной безопасности, указанные в локальных нормативных актах ФГБУ «СИЦ Минтранса России», регламентирующих условия информационного взаимодействия, защиты информации и подключения к информационным ресурсам ФГБУ «СИЦ Минтранса России», участвующих в информационном взаимодействии в рамках оказания услуг по технической поддержке АСУ ТК в 2026 году - Для обеспечения взаимодействия с Заказчиком Подрядчик со своей стороны определяет ответственных лиц, уполномоченных в структуре Подрядчика за своевременное и качественное оказание Услуг в рамках настоящего ТЗ, а также контактную информацию ответственных лиц (телефон, электронную почту). Подрядчик должен предоставить Заказчику единый адрес электронной почты для приема обращений (заявок) в течение 3 (трех) рабочих дней после заключения Контракта. Указанный в настоящем пункте адрес электронной почты (способ направления обращений (заявок) применяется в случае сбоя в работе СРО Заказчика. Со своей стороны, Заказчик предоставляет Подрядчику перечень и контактную информацию (телефон, электронную почту) уполномоченных лиц для осуществления взаимодействия с указанием зон ответственности. О любых изменениях в контактной информации ответственных лиц Стороны должны уведомить друг друга в течение 1 (одного) рабочего дня с момента возникновения таких изменений посредством уведомления на электронную почту ответственных лиц и/или в письменной форме. В результате оказания услуг по настоящему ТЗ не должны быть изменены исходные коды, дистрибутивы и иные компоненты Модуля СЦ вне согласованных с Заказчиком изменений. Любые изменения исходных кодов, дистрибутивов и иных компонентов Модуля СЦ должны производиться только после согласования с Заказчиком уполномоченными лицами по электронной почте или иным заранее согласованным способом. Не должна быть ухудшена надежность и производительность Модуля СЦ. Оказание услуг по Контракту не должно нарушать требования к информационной безопасности, описанной в документации на Модуль СЦ - Оказание услуг в рамках данного технического задания осуществляется Подрядчиком по обращению (заявке) Заказчика, направляемой посредством СРО Заказчика. Регистрация обращений, поступивших непосредственно в Модуль СЦ регистрации обращений Заказчика, производится сотрудниками Заказчика, которые обеспечивают первый уровень технической поддержки Модуля СЦ. В случае назначения приоритета «Критический» или «Высокий», информация о назначении также дублируется оповещением ответственных представителей Подрядчика посредством звонка на предоставленные номера телефонов. Обращение (заявка) должна содержать следующую информацию: – контакты пользователя/организации; – приоритет обращения, соответствующий Приложению 2 к Регламенту; – время обнаружения; – наименование компонента АСУ ТК - Модуль СЦ; Информация может быть расширена по согласованию с Заказчиком. Обращения (заявки) сотрудников Заказчика должны приниматься Подрядчиком через веб-интерфейс СРО. В процессе обработки обращений (заявок) Подрядчик должен обеспечить выполнение следующих процедур: – прием обращений(заявок) от сотрудников Заказчика; – оказание информационно-консультационной поддержки в соответствии с требованиями настоящего Технического задания; – информирование сотрудников Заказчика о статусе обработки и результатах обработки обращений(заявок). Подрядчик осуществляет обязательную регистрацию и учет всех обращений и заявок, поступивших к Подрядчику от представителей Заказчика в рамках оказания настоящих услуг - Примечание: в случае приостановки работы по обращению или заявке (обращение или заявка находится в статусе «Приостановлено»), указываются причины, по которым работы по обращению или заявке приостановлены с указанием перечня действий/информации, запрошенных у инициатора обращения, а также даты, формы и адресата такого запроса. В случае отклонения обращения или заявки (заполняется в случае, если обращению или заявке присваивается статус «Отклонено»), указываются подробно причины такого отклонения, а также фиксируется дата и время перехода в статус «Отклонено». В случае, если обращение или заявка отклонены (отменены) самим Инициатором, то указывается дата и способ, которым от инициатора получено соответствующее уведомление. В случае невыполнения Подрядчиком регламентного времени реагирования или решения обращения (заявки) Заказчик вправе отозвать обращение и направить его Подрядчику повторно. При этом каждое отозванное обращение учитывается в Отчёте об оказанных услугах, как обращение с превышением времени реагирования или решения, но оплате не подлежит. В случае, если обращение (заявка) связано с некачественным выполнением Подрядчиком другой задачи, такое обращение решается в регламентное время, установленное Техническим заданием, при этом оплате такие обращения не подлежат, о чем указывается в Отчете об оказанных услугах в графе «Примечание» - 4.3.1.3. Требования к регламенту оказания услуг Подрядчик должен руководствоваться Регламентом оказания услуг по технической поддержке Модуля СЦ. Регламент оказания услуг содержит следующую информацию: – порядок оказания услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Модуля СЦ; – порядок оказания услуги по решению инцидентов, связанных с работой ППО; – порядок оказания услуги адаптационного, конфигурационного и коррекционного сопровождения Модуля СЦ (в рамках действующих программных модулей и функциональностей); – порядок оказания услуги по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности. – Регламент содержит следующие формы заявок на оказание услуг: – форма заявки на оказание услуги по информационно-консультационной поддержке сотрудников Заказчика; – форма заявки на оказание услуги по решению инцидентов, связанных с работой ППО; – форма заявки на оказание услуг адаптационного, конфигурационного и коррекционного сопровождения Модуля СЦ (в рамках действующих программных модулей и функциональностей) (приоритет заявки определяется Заказчиком); – форма заявки на оказание услуги по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности - 4.3.2. Требования к режиму обеспечения функционирования Модуля СЦ Режим оказания услуг определен в Приложении Б к настоящему ТЗ. По согласованию с Заказчиком, в целях недопущения остановки функционирования Модуля СЦ в период интенсивной работы пользователей в Модуле СЦ, отдельные услуги могут оказываться по специальному графику (в нерабочее время Подрядчика) в соответствии с заявками Заказчика - 4.3.3. Требования к качеству оказываемых услуг Качество оказываемых услуг поддерживается Подрядчиком в соответствии с определяемыми данным ТЗ условиями и правилами и контролируется Заказчиком на постоянной основе, в том числе по соблюдению сроков исполнения и подтверждениям исполнения от инициаторов обращений и другим параметрам. По результатам выполнения работ по устранению инцидента должна быть устранена корневая причина инцидента с окончательным решением, устраняющим причину возникновения проблемы и исключающим вероятность повторного возникновения проблемы (инцидента). Время устранения корневых причин проблемы (инцидента) не должно составлять более 40 рабочих часов - 4.3.4. Требования к документированию результатов оказываемых услуг Для обеспечения контроля оказываемых услуг по поддержке Модуля СЦ со стороны Заказчика, по окончании каждого отчетного периода по контракту в соответствии с календарным планом, Подрядчик обязан предоставить Заказчику Отчет об оказанных услугах. Отчет должен содержать детальную информацию об оказанных услугах с указанием даты выполненных мероприятий и приложением обосновывающих документов (заявок, запросов, требований) или ссылкой на такие документы, если они содержатся в Модуле СЦ. Информация о выполненных мероприятиях по заявкам должна быть сформирована на основании соответствующих записей СРО по каждому этапу исполнения Контракта. В случае оказания услуги адаптационного, конфигурационного и коррекционного сопровождения Модуля СЦ, должны быть предоставлены документы, подтверждающие выполнение требований п. 29.3 приказа ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации». Фактическое время реагирования и время решения по всем обращениям, поступившим в СРО, формируется в СРО по итогам отчетного периода в разделе «Отчеты». Фактическое время реагирования и время решения по обращениям учитывает суммарное время, затраченное на реагирование и, соответственно, на работу по обращению с момента назначения обращения специалисту Подрядчика или группе исполнителей, ответственным за оказание услуг технической поддержки 3 уровня от начала до завершения работ Подрядчиком. При этом принимается суммарное время нахождения заявки в соответствующих статусах заявки СРО на стороне Подрядчика - 4.3.5. Требования к классификации обращений и заявок Обращения и заявки Заказчика классифицируются в соответствии с приоритетами и регламентными сроками, указанными в Приложении 2 к Регламенту. Регистрация обращений и заявок предусматривает создание новой записи в СРО с присвоением поступившему обращению или заявке (новой записи) уникального идентификатора. Запись в СРО должна содержать вопрос или проблему, которую требуется решить или оказать консультацию. Состав обязательной информации, которую должно содержать обращение или заявка, зафиксирован в Регламенте оказания Услуг. Если обращение или заявка автоматически зарегистрированы в СРО при отправке представителем Заказчика, Подрядчик проверяет корректность классификации обращения или заявки и может обратиться к Заказчику с просьбой корректировки, предоставив обоснования в соответствии с настоящей классификацией (Таблица 6) - Таблица 6. Категории обращений и заявок Категория Примеры Запрос на обслуживание Подготовка SQL запроса к СУБД для решения прикладной задачи и д.р. – запрос на любое действие, не являющееся запросом информации и несовершенный на основе происшествия, прямо или косвенно влияющего на работу Модуля СЦ Консультация «Где взять / куда обратиться...?», «Как сделать / выполнить…», «Как это работает…?» - запрос, имеющий своей целью получение информационной поддержки Инцидент Разбор ошибок/сбоев и подготовка материалов (корректировочных релизов, инструкций) для Заказчика для устранения ошибок/сбоев, которые приводят к частичному и полному нарушению работоспособности всех или отдельных функций ППО. Подготовка изменения и материалов, необходимых для проведения аварийно-восстановительных работ для возобновления работоспособности Модуля СЦ ЗНИ Подготовка изменений, связанных с изменением, улучшением/оптимизацией Модуля СЦ и выводом новой модифицированной функциональности в штатном режиме. Подготовка изменений, связанных с модификацией существующих и/или реализация новых интеграционных механизмов для получения/обработки данных внешних систем. Подготовка изменений графического интерфейса по требованиям Заказчика. Перечень статусов обращений (заявок) приведен в пункте 3.3. Регламента оказания Услуг. Назначение обращению (заявке) статуса «Закрыто» осуществляется Заказчиком только после получения от инициатора обращения (заявки) подтверждения о его исполнении или нахождения обращения (заявки) в статусе «Выполнено» и отсутствия повторных вопросов/запросов по данному обращению (заявки) в течение 5 рабочих дней. Категории и статусы обращений (заявок) могут быть скорректированы в процессе оказания услуг исключительно по согласованию с Заказчиком - 4.3.6. Требования к услугам технической поддержки 4.3.6.1. Требования к организации третьего уровня технической поддержки Основными задачами организации третьего уровня технической поддержки в рамках оказания услуг по технической поддержке Модуля СЦ являются организация эксплуатационной службы Подрядчика, проверка готовности технических и программных средств для обеспечения непрерывного функционирования ППО Модуля СЦ. Подрядчиком должны быть проведены организационно-штатные и подготовительные мероприятия (в т. ч. технические) в рамках организации технической поддержки Модуля СЦ. Подрядчик в течение 5 (пяти) рабочих дней с даты заключения Контракта должен: – определить и направить Заказчику документ «Перечень уполномоченных специалистов», содержащий контактную информацию (ФИО, должность, адрес рабочей электронной почты) лиц, ответственных за оказание услуг со стороны Подрядчика; – обеспечить подключение специалистов Подрядчика к Системе регистрации обращений (заявок) (СРО предоставляется Заказчиком) для оказания услуг; – согласовать с Заказчиком способ доступа Подрядчика к Модулю СЦ. Результат выполнения мероприятий фиксируется в Протоколе проверки результатов организационно-штатных и подготовительных мероприятий (см. Приложение Д к настоящему ТЗ) - 4.3.6.2. Требования к услугам информационно-консультационной поддержки работников Заказчика и пользователей Модуля СЦ Услуги информационно-консультационной поддержки сотрудников Заказчика включают: – обработку обращений и заявок, поступивших от сотрудников Заказчика; – консультирование сотрудников Заказчика и пользователей Модуля СЦ; – актуализацию документации, и других материалов по работе с Модулем СЦ при необходимости. – консультирование и разработку рекомендаций по настройке Модуля СЦ (без изменения программного кода), включая изменение настроек функционирования; – консультации по вопросам использования, настройки и возможностям Модуля СЦ; – консультации по проведению превентивных мер для недопущения аварийных ситуаций в Модуле СЦ; – консультации по предварительной диагностике и локализации возникшей неисправности Модуля СЦ; – консультации по вопросам обеспечения информационной безопасности Модуля СЦ и настройки функций, обеспечивающих корректную работу программного обеспечения для совершения юридически значимых действий в Модуле СЦ; – другие вопросы, связанные с работой Модуля СЦ. 4.3.6.2.1. Требования к порядку оказания услуг информационно-консультационной поддержки работников Заказчика и пользователей Модуля СЦ Подрядчик выполняет консультирование сотрудников Заказчика и пользователей Модуля СЦ. Консультация может быть предоставлена по согласованным с представителем Заказчика каналам коммуникации с регистрацией результата консультации в СРО Подрядчиком. Детальный порядок оказания консультационных услуг определен в Регламенте оказания Услуг - 4.3.6.3. Требования к услугам по решению инцидентов, связанных с работой ППО Подрядчик устраняет неисправности Модуля СЦ, связанные с работой ППО, выявленные в рамках оказания услуг согласно настоящему Техническому заданию, при этом в зону ответственности Подрядчика не входит устранение неисправностей, выявленных на стороне Заказчика и на стороне третьих лиц (провайдера связи, поставщика электропитания и т.д.). Первичная диагностика выявленной неисправности проводится на 1 и 2 уровнях технической поддержки и не входит в зону ответственности Подрядчика. Если при проведении первичной диагностики и попытке устранить неисправности на 1 и 2 уровнях технической поддержки, данную неисправность устранить не удалось и в процессе диагностики было выявлено, что проблема связана с работоспособностью ППО, обращение (заявка) назначается сотруднику Подрядчика, ответственному за оказание услуг технической поддержки 3 уровня. Инцидентами вне зоны ответственности Подрядчика являются: – работоспособность функциональности, выходящая за рамки текущей реализации функций в Модуле СЦ и/или являющаяся расширением требований Заказчика к функциям Модуля СЦ; – проведение профилактических и плановых работ, согласованных с Заказчиком; – нарушение работоспособности функций Модуля СЦ, вызванное проведением работ на стороне Заказчика - 4.3.6.3.1. Требования к порядку оказания услуги по решению инцидентов, связанных с работой ППО При поступлении от Заказчика обращения (заявки), являющегося неисправностью в работе Модуля СЦ (инцидентом), Исполнитель реагирует на инцидент в СРО в срок не более 30 минут с момента поступления. В случае необходимости, для решения инцидента ответственный специалист должен связаться с инициатором обращения (заявки) для уточнения условий воспроизведения проблемы или для получения дополнительных сведений. После получения необходимых сведений от инициатора обращения (заявки) ответственный специалист производит диагностику с целью выявления причины инцидента и возможных путей устранения. В случае, если инцидент невозможно решить без получения дополнительных сведений от инициатора, и не удается связаться с инициатором в течение пяти рабочих дней, обращение (заявка) отклоняется в связи с недостатком данных для его решения, Заказчику направляется уведомление об отклонении обращения (заявки). Время, в течение которого невозможно связаться с инициатором, вычитается из общего времени обработки обращения (заявки). Все попытки связаться с инициатором должны фиксироваться с указанием даты и времени попытки, используемого способа связи (номер телефона, адрес электронной почты) и результата попытки (не удалось дозвониться, абонент недоступен, и т.д.) - Факт и время решения инцидента должны быть зафиксированы и отражены в СРО. В случае, если причиной сбоя в работе Модуля СЦ является выход из строя аппаратного обеспечения или неработоспособность смежной информационной системы, время работы над инцидентом приостанавливается до момента устранения неисправности. В ходе решения инцидентов могут быть выявлены дефекты ППО Модуля СЦ. В случае обнаружения дефектов ППО, Подрядчик информирует об этом Заказчика. Исполнитель может быть привлечен к проверке результата устранения дефекта по инициативе Заказчика. Приоритеты инцидентов приведены в Приложении Б к ТЗ. Детальный порядок оказания услуги по решению инцидентов, связанных с работой ППО Модуля СЦ определен в Регламенте оказания Услуг - 4.3.6.4. Требования к услугам адаптационного, конфигурационного и коррекционного сопровождения и доработки Модуля СЦ (в рамках действующих программных модулей и функциональностей) Услуги адаптационного, конфигурационного и коррекционного сопровождения и доработки Модуля СЦ включают: – управление изменениями и адаптация функций Модуля СЦ; – изменение настроек функционирования Модуля СЦ; – внесение изменений и/или модификаций Модуля СЦ (в рамках действующих программных модулей и функциональностей), направленных на улучшение их работоспособности и функциональных возможностей; – подготовка и передача Заказчику SQL запросов в СУБД для получения агрегированной информации из Модуля СЦ, которую невозможно получить с использованием графического пользовательского интерфейса; – адаптация модулей интеграций со смежными информационными системами - 4.3.6.4.2. Требования к изменению настроек функционирования Изменение настроек функционирования может проводиться в рамках допустимых пределов изменения функционирования, заложенных в архитектуру Модуля СЦ. Изменение настроек функционирования включает в себя изменение данных и справочников, изменение форм документов, формируемых Модулем СЦ, изменение и настройку форматов и версий передачи данных в смежные системы. Доработка программного кода Модуля СЦ может допускаться (в случае необходимости) при выполнении работ по адаптации функций Модуля СЦ в части изменения формата передачи данных в смежные информационные системы при условии соблюдения требований пункта 29.3 приказа ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации» - 4.3.6.5. Требования к услугам по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности По запросу Заказчика Подрядчик должен провести работу по приведению ППО в соответствие с требованиями по обеспечению информационной безопасности. Критичность уязвимости оценивается в соответствии в соответствии с Методическим документом ФСТЭК России «Методика оценки уровня критичности уязвимостей программных, программно-аппаратных средств» (утвержден ФСТЭК России 30.06.2025), а также с учетом ГОСТ 56545-2015 и международными стандартами (CVSS 3.0 и выше), и задает необходимый срок устранения. В процессе проведения Заказчиком обследования Модуля СЦ и выявления уязвимостей в ППО, связанных с исходным кодом Модуля СЦ и/или используемыми компонентами (библиотеками), Заказчик направляет Подрядчику обращение (заявку) на устранение, с указанием критичности и срочности принятия мер по устранению в СРО. - Подрядчик при оказании услуг по обновлению или устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности должен: – провести анализ уязвимостей и связанных с ними исходным кодом и/или используемыми компонентами (библиотеками); – выработать варианты устранения указанных уязвимостей и согласовать с Заказчиком их реализацию; – своевременно внести изменения в исходный код Модуля СЦ и/или используемые компоненты (библиотеки) и подготовить соответствующее обновление; – провести обновление Модуля СЦ в тестовом контуре Заказчика и проинформировать Заказчика о готовности проведения тестирования; – протестировать успешность обновления или устранения уязвимостей в ППО и корректность функционирования Модуля СЦ на тестовом контуре, совместно с Заказчиком; – при невозможности незамедлительного устранения уязвимости приоритетов «Критический» и «Высокий» Подрядчик обязан предоставить исчерпывающий список причин и согласовать план достаточных компенсирующих мер с ответственными сотрудниками Заказчика. Результат внесения изменений отображается в соответствующей записи в СРО и в составе Отчета об оказанных услугах - 4.3.6.5.1. Требования к порядку оказания услуг по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности Подрядчик в соответствии с приоритетами обращений и контрольными сроками исполнения (см. Приложение Б к ТЗ) оценивает техническую возможность и сроки устранения уязвимостей, и реализацию обновления Модуля СЦ. По итогу проведения оценки Подрядчик направляет в заявке СРО Заказчику заключение о возможности устранения уязвимостей и/или обновления в ППО и согласует с Заказчиком проведение данных работ - При проведении работ по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности необходимо выполнить следующее: – Заказчику сформировать заявку на устранение (обновление) в СРО с полным списком обнаруженных уязвимостей и планируемыми работами; – согласовать в рабочем порядке время начала и завершения работ, перечень работ, выполняемых в рамках обновления или устранения уязвимостей в ППО с Заказчиком; – оповестить Заказчика о начале проведения работ на тестовом контуре; – провести работы по обновлению или устранению уязвимостей в ППО на тестовом контуре Модуля СЦ в установленные сроки; – протестировать выполнение работ в тестовом контуре и проинформировать Заказчика о готовности переноса ППО на продуктивный контур; – силами Заказчика обновить продуктивный контур Модуля СЦ, в соответствии с планом устранения и выполненными работами; – совместно с Заказчиком проверить корректность функционирования Модуля СЦ и устранения уязвимостей в продуктивном контуре Модуля СЦ по результатам обновления; – при необходимости актуализировать документацию (описание архитектуры, анкеты постановки на мониторинг и иные документы). Любые изменения в части обновления или устранения уязвимостей в ППО на промышленном контуре Модуля СЦ должны применяться только в случае успешного проведения аналогичных работ на тестовом контуре. Детальный порядок оказания услуги по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности определен в Регламенте оказания Услуг - 4.4. Требования к видам обеспечения 4.4.1. Требования к лингвистическому обеспечению Документация на Модуль СЦ должна разрабатываться на русском языке. Взаимодействие пользователей с Модулем СЦ посредством графического интерфейса должно происходить на русском языке за исключением сообщений, зависящих от настроек системного программного обеспечения, установленного на рабочих местах пользователей. При разработке программных решений Модуля СЦ должно быть предусмотрено использование языков программирования высокого уровня, приведенных в Таблице 7. Таблица 7. Языки и средства разработки, специального программного обеспечения Модуля СЦ Категория Наименование Назначение Языки программирования Kotlin Разработка серверной логики и сервисов (backend) JavaScript / TypeScript Разработка клиентской части (frontend) Python Разработка скриптов интеграции, обработки данных и автоматизации Фреймворки и библиотеки Vue.JS Разработка пользовательских интерфейсов (веб-интерфейсы компонентов визуализации и отчетности) React Разработка пользовательских интерфейсов (при необходимости создания сложных интерактивных компонентов) Решения по лингвистическому обеспечению, включая перечень используемых языков программирования, должны быть согласованы с Заказчиком на этапе технического проектирования - 4.4.2. Требования к математическому обеспечению Требования к математическому обеспечению не предъявляются. 4.4.3. Требования к метрологическому обеспечению Требования к метрологическому обеспечению не предъявляются. 4.4.4. Требования к организационному обеспечению Требования к организационному обеспечению не предъявляются. 4.4.5. Требования к методическому обеспечению Задачи методического обеспечения Модуля СЦ должны быть обеспечены за счет использования технологических и методических документов касающихся вопросов функционирования транспортного комплекса и разработки и эксплуатации ПО. 4.4.6. Требования к информационному обеспечению Состав, структура и способы организации информационного обеспечения в Модуле СЦ должны быть определены на этапе технического проектирования. Факты информационного обмена с внешними системами должны фиксироваться в соответствующем журнале - 4.4.7. Требования к программному обеспечению Общесистемное ПО, используемое в составе Модуля СЦ, должно быть зарегистрировано в Едином реестре российских программ для электронных вычислительных машин и баз данных и соответствовать рекомендованным показателям эффективности и соответствующим им значениям индикаторов эффективности перехода подведомственных организаций на использование российского ПО, заданных Приказом Минцифры России от 18.01.2023 № 21 «Об утверждении методических рекомендаций по переходу на использование российского программного обеспечения, в том числе на значимых объектах критической информационной инфраструктуры Российской Федерации, и о реализации мер, направленных на ускоренный переход органов государственной власти и организаций на использование российского программного обеспечения в Российской Федерации». Применяемое в системе программное обеспечение должно соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации, постановления Правительства Российской Федерации от 23 декабря 2024 г. № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц» - Прикладное программное обеспечение должно отвечать следующим требованиям: – совместимость программных продуктов в части используемых технических средств, системного программного обеспечения и общесистемной инфраструктуры в пределах требований к техническому обеспечению, а также их информационная совместимость в пределах требований к информационному обмену; – обеспечение трехуровневой архитектуры с разделением на уровень хранения данных (сервер БД), уровень бизнес-логики (сервер приложений) и уровень представления ( - 4.4.7.1. Требования к инструментам разработки и процессу контроля версий программного обеспечения 4.4.7.1.1. Система контроля версий Для управления исходным кодом должна использоваться система контроля версий кода, развернутая в инфраструктуре Заказчика. 4.4.7.1.2. Правила именования веток Имя ветки должно соответствовать следующему формату: / / Категории веток: ? feature/ — разработка новой функциональности, а также рефакторинг или удаление существующей; ? fix/ — исправление ошибок; ? hotfix/ — срочные исправления, применяемые в обход стандартного процесса разработки; ? test/ — для проведения экспериментов, не влияющих на основную разработку. Идентификатор задачи: после категории указывается ссылка на задачу (issue) в системе контроля версий кода. Описание: добавляется краткое описание решаемой задачи в формате kebab-case (слова разделяются дефисами, например, add-user-auth). Примеры именования веток: ? feature/#123/add-payment-integration; ? fix/#45/correct-calculation-logic; ? hotfix/#67/urgent-database-connection-patch. 4.4.7.1.3. Правила именования коммитов Сообщение коммита должно соответствовать соглашению Conventional Commits и состоять из категории и описания: : ? fix — исправление ошибки. Примеры сообщений коммитов: ? feat: добавление формы регистрации пользователя; ? fix: исправление ошибки валидации email-адреса; ? refactor: оптимизация алгоритма сортировки данных; ? chore: обновление версий в файле dependencies. 4.4.7.1.4. Модель ветвления В процессе разработки используются следующие основные ветви: ? main / master — стабильная ветка, содержит только код, прошедший полное тестирование и развернутый в продуктивных контурах; ? dev — ветка для интеграции завершенных задач, предназначенная для сборки и тестирования в тестовых средах. Попадание кода в main осуществляется только через Merge Request (MR) из dev - 4.4.7.1.5. Требования к используемым зависимостям (библиотекам) Все внешние зависимости проекта должны быть зафиксированы с указанием точных версий. Для контроля версий зависимостей в репозиторий обязательно должны быть включены следующие файлы: · Для JavaScript: package-lock.json или yarn.lock; · Для Python: requirements.txt (с зафиксированными версиями) или Pipfile.lock; · Для Go: go.mod и go.sum; Загрузка всех зависимостей должна производиться исключительно через внутренний прокси-репозиторий Заказчика, настроенный в соответствующем системе менеджере пакетов. Запрещается: · Использование плавающих версий (например, ^1.2.3, ~4.5.0, latest); · Использование библиотек, содержащих критические уязвимости, в том числе зарегистрированные в реестре CVE (Common Vulnerabilities and Exposures). 4.4.7.1.6. Требования к процессу непрерывной интеграции (CI) Сборка программного обеспечения, включая этапы компиляции, тестирования и анализа кода, должна выполняться исключительно в инфраструктуре непрерывной интеграции Заказчика. 4.4.7.1.7. Требования к хранению артефактов сборки Все артефакты сборки (результирующие пакеты, Docker-образы и т.д.) подлежат обязательному хранению в предназначенной для этого инфраструктуре Заказчика (артефакторий). Запрещается размещение финальных артефактов сборки на сторонних ресурсах - 4.4.8. Требования к техническому обеспечению Количество серверов, подключаемых и настраиваемых сервисов, их параметров, схемы соединений и настройки межсетевого взаимодействия должны быть согласованы с Заказчиком на этапе № 1 Техническое проектирование. Доступ к комплексу технических средств предоставляется Заказчиком по письменному запросу Подрядчика. Применяемые в Системе программно-аппаратные и аппаратные комплексы должны соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации», требованиям Постановления Правительства Российской Федерации от 23 декабря 2024 г. № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц». Модуль СЦ, работающий в составе АСУ ТК, развернут на вычислительных мощностях ГЦОД СИЦ Минтранса России - 4.5. Общие технические требования 4.5.1. Требования к численности и квалификации персонала и пользователей Модуля СЦ Программное обеспечение Модуля СЦ не должно требовать изменения штатной численности персонала Заказчика. Программное обеспечение Модуля СЦ не должно требовать наличия у пользователей дополнительной квалификации в сфере информационных технологий, кроме базовых знаний в обращении с персональным компьютером, базовых навыков работы в интернет-обозревателях и знаний о Модуле СЦ в объеме документов Руководство пользователя, Руководство администратора - 4.5.2. Требования к режимам функционирования Модуля СЦ Модуль СЦ должен предусматривать наличие следующих режимов работы: – штатный; – регламентный (профилактический); – аварийный. Основным режимом функционирования является штатный. В штатном режиме все компоненты корректно и полностью выполняют свои функции. Перерывов в работе как Модуля СЦ в целом, так и одного, либо нескольких компонентов не предусмотрено. Режим регламентного (профилактического) обслуживания предназначен для проведения работ по обновлению и техническому обслуживанию компонентов Модуля СЦ, а также резервному копированию данных. При работе в данном режиме допускаются перерывы в работе Модуля СЦ с предварительным информированием пользователей. Состав процедур по регламентному обслуживанию Модуля СЦ и их периодичность определяются Подрядчиком в процессе выполнения работ по созданию Модуля СЦ. В режиме регламентного (профилактического) обслуживания Модуль СЦ может функционировать с частичным ограничением своих функциональных возможностей, либо без ограничения, но со снижением показателей надежности и производительности. Перевод в данный режим работы должен осуществляться сразу после начала выполнения любой операции, отнесенной к этому режиму, с последующим возвратом в штатный режим функционирования сразу после ее завершения. Перевод в указанный режим должен осуществляться при возникновении необходимости проведения работ по обновлению и техническому обслуживанию компонентов Модуля СЦ, а также резервному копированию данных с условием предварительного оповещения пользователей. Аварийный режим функционирования характеризуется отказом одной или нескольких подсистем, вызванных выходом из строя аппаратного и/или программного обеспечения, а также в случае временной неработоспособности каналов связи между серверами. - В аварийном режиме осуществляется поиск неисправностей и проведение работ по их устранению. Перевод в аварийный режим должен осуществляться при возникновении сбоев, аварий и прочих незапланированных воздействий, сразу после наступления одной или нескольких аварийных ситуаций, с последующим возвратом в штатный режим функционирования сразу после окончания восстановительных работ. ПО Модуля СЦ должно обладать надежностью, обеспечивающей работу пользователей в произвольном режиме и оперативное восстановление работоспособности при сбоях. В целях обеспечения надежного функционирования ПО должно предусматривать: – сохранение целостности данных при нештатном завершении работы компонентов Модуля СЦ; – сохранение работоспособности программного обеспечения при некорректных действиях пользователя; – резервное копирование базы данных Модуля СЦ. – время восстановления работоспособности Модуля СЦ после отказа не более 4 часов. – отказоустойчивость на уровне 99% при единовременной количестве не менее 200 пользовательских сессий в Модуле СЦ. Указанные характеристики приведены без учета характеристик надежности инфраструктуры и времени передачи информации по каналам связи. При возникновении сбоев в аппаратном обеспечении, включая аварийное отключение электропитания, Модуль СЦ должен автоматически восстанавливать свою работоспособность (не требовать перенастройки) после устранения сбоев и корректного перезапуска аппаратного обеспечения - 4.5.5. Требования к информационной безопасности Работы по защите информации/информационной безопасности, не включенные в состав настоящего раздела, требуемые в соответствии с требованиями постановления Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации», а также нормативно правовых актов в области защиты персональных данных и обеспечения безопасности объектов критической информационной инфраструктуры, будут проведены в рамках исполнения отдельного контракта, заключенного по результатам отдельной закупочной процедуры (не является частью данного ТЗ), включающего: – определение актуальных угроз безопасности информации и актуализация модели угроз безопасности информации (при необходимости); – выполнение требований о согласовании технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России в установленном порядке; – выполнение требований по устранению Подрядчиком замечаний и недостатков, в случае их выявления при согласовании Заказчиком технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России; – выполнение требований к классу защищенности ГИС, уровню защищенности персональных данных и категории значимости объекта КИИ РФ, установленных для Головного центра обработки данных ФГБУ «СИЦ Минтранса России» (далее – ГЦОД); - – определение перечня объектов защиты информационной системы; – описание (актуализированных) требований к системе защиты информации, а также к мерам защиты информации информационной системы в зависимости от установленных классов защищенности, уровня защищенности персональных данных и категории значимости объектов КИИ РФ (приказы ФСТЭК России № 21, 117, 239); – выполнение требований к мерам по защите ГИС от атак, направленных на отказ в обслуживании, в соответствии с пунктами 30, 34, 59, 63 Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений, утвержденных приказом ФСТЭК России от 11.04.2025 № 117; – описание (актуализированных) требований по защите информации, подлежащих реализации в информационно телекоммуникационной инфраструктуре ГЦОД; – выполнение требований о применении сертифицированных средств защиты информации, включая их классы защиты и уровни доверия; – выполнение требований о запрете использования с 01.01.2025 органами (организациями) средств защиты информации странами происхождения, которых являются иностранные государства в соответствии с пунктом 6 Указа Президента Российской Федерации от 01.05.2022 № 250; – выполнение требований по обеспечению непрерывного взаимодействия с ГосСОПКА в установленном порядке; - – выполнение требований по обеспечению в автоматизированном режиме с Национальной системой противодействия DDoS-атакам (НСПА) Центра мониторинга и управления сетью связи общего пользования ФГУП «ГРЧЦ» в рамках реализации мер по защите ГИС от атак, направленных на отказ в обслуживании; – детализированные требования к составу и содержанию работ по аттестации, а также к их результатам в соответствии с пунктами 13, 15 и 16 требований приказа ФСТЭК России от 29.04.2021 № 77 «Об утверждении Порядка организации и проведения работ по аттестации объектов информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну» - 4.5.5.1. Требования к безопасности исходного кода Процесс разработки исходного кода должен соответствовать требованиям законодательства, нормативным правовым актам Российской Федерации, приказу ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по безопасности значимых объектов критической информационной инфраструктуры Российской Федерации», а также учитывать отраслевые практики безопасной разработки. Подрядчик должен предоставить Заказчику Руководство по безопасной разработке программного обеспечения (далее – Руководство), применяемое при разработке исходного кода Модуля СЦ. Руководство должно содержать: · описание процесса безопасной разработки и ролевой модели, отражающей зоны ответственности сотрудников Подрядчика; · описание процессов моделирования, оценки и формирования мер предотвращения угроз, применяемых Подрядчиком; · описание методик, применяемых Подрядчиком при разработке исходного кода (правила написания кода); · описание методик, периодичности проведения и инструментария статического, динамического, композитного и фаззинг тестирования исходного кода, включающего критерии отбора релизных версий ПО, применяемые Подрядчиком в процессе разработки; · описание механизмов безопасности в процессе сборки и доставки (безопасность образов, безопасность секретов, безопасность окружения и сборочной среды), применяемые Подрядчиком; · утвержденные шаблоны отчетной документации (в том числе акты), в соответствии с которыми Заказчик принимает результаты проверок (артефакты сборочного процесса), проведенных Подрядчиком; · описание процедур отслеживания и исправления обнаруженных ошибок и уязвимостей программного обеспечения; · описание способов и сроков доведения Подрядчиком до Заказчика информации об уязвимостях программного обеспечения, о компенсирующих мерах по защите информации или ограничениях по применению программного обеспечения, способов получения пользователями программного обеспечения его обновлений, проверки их целостности и подлинности - Подрядчик должен обеспечить реализацию и проведение внутренних проверок мер по разработке безопасного ПО, приведенных в Руководстве. Подрядчик должен провести анализ угроз безопасности информации программного обеспечения в соответствии с ГОСТ 58412-2019 «Защита информации. Разработка безопасного программного обеспечения. Угрозы безопасности информации при разработке программного обеспечения». Подрядчик должен провести испытания по выявлению уязвимостей в программном обеспечении Системы: · проведение статического анализа исходного кода программы; · проведение динамического анализа исходного кода программы; · проведение композитного анализа исходного кода и образов программы; · проведение фаззинг-тестирования программы, направленного на выявление в ней уязвимостей. Испытания по выявлению уязвимостей в программном обеспечении Системы должны быть проведены в рамках: · предварительных испытаний; · опытной эксплуатации; · приемочных испытаний - По результатам анализа угроз безопасности информации программного обеспечения и испытаний по выявлению уязвимостей в программном обеспечении Системы должна быть предоставлена отчетная документация по формам, утвержденным в Руководстве, и артефакты сборочной среды, подтверждающие проведение испытаний по выявлению уязвимостей в программном обеспечении Систем. Уязвимости подлежат устранению в сроки, обозначенные Заказчиком. В случае обнаружения уязвимого компонента Подрядчик должен заменить/обновить библиотеки. В случае, если уязвимость не подлежит исправлению на программном уровне, Подрядчик должен разработать меры предотвращения угроз безопасности, в том числе правила безопасности для наложенных средств защиты, рекомендации по безопасной настройке конфигурации для устранения потенциальных уязвимостей и снижения рисков информационной безопасности. Уязвимости, найденные ФСБ России, ФСТЭК России, Минцифры России, Роскомнадзором в ходе исполнения Контракта, а также в течение гарантийного периода, должны быть устранены Подрядчиком за свой счет в сроки, согласованные с Заказчиком - 4.5.6. Требования к эргономике и технической эстетике Взаимодействие пользователей с Модулем СЦ должно осуществляться посредством визуального графического интерфейса. Ввод-вывод данных, прием управляющих команд и отображение результатов их исполнения должны выполняться в интерактивном режиме. Интерфейс должен быть рассчитан на преимущественное использование манипулятора типа «мышь», то есть управление Модулем СЦ должно осуществляться с помощью набора экранных меню, кнопок, значков и т. п. элементов. Клавиатурный режим ввода должен использоваться главным образом при заполнении и/или редактировании текстовых и числовых полей экранных форм. Все надписи экранных форм, а также сообщения, выдаваемые пользователю (кроме системных сообщений), должны быть на русском языке. Модуль СЦ должен обеспечивать проверку вводимых пользователем данных и предупреждать о некорректно введённых значениях - Экранные формы должны проектироваться с учетом требований унификации: – все экранные формы пользовательского интерфейса должны быть выполнены в едином графическом дизайне, с одинаковым расположением основных элементов управления и навигации; – для обозначения сходных операций должны использоваться сходные графические элементы, кнопки и другие управляющие (навигационные) элементы. Термины, используемые для обозначения типовых операций, а также последовательности действий пользователя при их выполнении должны быть унифицированы; – внешнее поведение сходных элементов интерфейса (реакция на наведение указателя «мыши», переключение фокуса, нажатие кнопки) должно реализовываться одинаково. Структура размещения информации и представление этой структуры в Модуле СЦ должны соответствовать следующим требованиям: – пункты меню в пользовательском веб-интерфейсе должны быть сгруппированы в соответствии с тематикой информации, функциональными задачами и технологией работы; – каждому пункту меню должна соответствовать только одна выполняемая функция; – при совершении пользователями ошибочных действий должны выдаваться сообщения об ошибках. Эскизы визуального оформления компонента «Интерактивная карта» представлены в Приложении А. - 4.5.7. Требования по сохранности информации при авариях В случае возникновения аварии или сбоя в процессе выполнения пользовательских задач должно быть обеспечено восстановление баз данных до состояния на момент последней завершенной Модулем СЦ транзакции, и структуры файлового хранилища. Все аварийные ситуации должны обрабатываться программно с выдачей соответствующих сообщений, с корректной обработкой ситуации (завершение транзакций, закрытие файлов и т.п.), без потери обрабатываемой информации. В Модуле СЦ должны быть предусмотрены меры, обеспечивающие целостность данных в случае отказа программного обеспечения или аппаратных средств, исключая случаи физического уничтожения носителя или нарушения функциональности носителя, операционной системы или СУБД по вине их производителя либо обслуживающего персонала. Используемые аппаратные и системные платформы должны обеспечивать сохранность и целостность информации в Модуле СЦ при полном или частичном отключении электропитания, аварии сетей телекоммуникации, полном или частичном отказе технических средств Модуля СЦ. Технические решения должны обеспечивать сохранность информации в случае возникновения следующих событий (аварий, отказов и т.п.): – отказ аппаратного обеспечения на сервере; – отключение питания на сервере; – отказ аппаратного обеспечения на рабочей станции; – отключение питания на рабочей станции администратора; – отказ линий связи, в том числе при осуществлении обмена данными - 4.5.8. Требования к защите от влияния внешних воздействий Требования к защите от влияния внешних воздействий не предъявляются - 4.5.9. Требования к патентной чистоте и патентоспособности 4.5.9.1. Исключительные права на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, базы данных, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, принадлежат Российской Федерации в лице Заказчика. Право собственности на результаты работ, отчетные документы и материалы, полученные в ходе выполнения работ по Контракту, принадлежат Российской Федерации в лице Заказчика и считаются переданными с момента подписания Сторонами Акта сдачи-приемки выполненных работ. Разработанное программное обеспечение поставляется вместе с исходными кодами. 4.5.9.2. Все проектные и технические решения должны отвечать требованиям четвертой части Гражданского кодекса Российской Федерации. Результаты Работ должны быть свободными от возможности предъявления любых прав и притязаний третьих лиц, основанных на промышленной, интеллектуальной или другой собственности. 4.5.9.3 Результаты выполненных Работ не должны повлечь необходимость осуществления Заказчиком закупок программного обеспечения (как исключительных, так и неисключительных прав) для обеспечения функциональности Системы в соответствии с Техническим заданием. При выполнении работ Подрядчик должен использовать только объекты интеллектуальной собственности, права на которые приобретены (получены) и используются без нарушений прав на интеллектуальную собственность третьих лиц или предоставлены Заказчиком - 4.5.9.12. Передача Заказчику комплекта документов, материалов и сведений, предусмотренных нормативными правовыми актами Российской Федерации в сфере информационных технологий, защиты информации, правовой защиты интересов государства в области интеллектуальной собственности, включая документы, подтверждающие отказ авторов (разработчиков) от исключительных прав на передаваемые объекты интеллектуальной собственности в пользу Подрядчика, с проектами заявок на государственную регистрацию в установленном порядке прав Заказчика на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, базы данных, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, осуществляется Подрядчиком в составе отчетной документации, предусмотренной условиями Контракта. 4.5.9.13. По результатам выполнения работ по развитию системы должны быть подготовлены материалы для регистрации доработанной версии Системы (объекта учета) в НФАП в соответствии с требованиями постановления Правительства Российской Федерации от 30 января 2013?г. №?62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин» (с изменениями и дополнениями) в части обязательности размещения результатов работ в национальном фонде алгоритмов и программ для электронных вычислительных машин - 4.5.10. Требования по стандартизации и унификации К Модулю СЦ предъявляются следующие требования в части стандартизации и унификации: – работы по развитию Модуля СЦ должны производиться в соответствии с действующими стандартами и нормами Российской Федерации; – при создании и модернизации элементов Модуля СЦ следует руководствоваться действующими в Российской Федерации национальными стандартами и другими нормативно-техническими документами; – используемые оборудование и материалы, подлежащие обязательной сертификации, должны иметь соответствующие сертификаты; – ПО Модуля СЦ должно проектироваться и разрабатываться с учётом обеспечения требований унификации; – применяемые при создании Модуля СЦ технические (форматы данных, протоколы передачи и прочие) и организационные (регламенты, требования, инструкции) решения должны быть доступны и документированы в виде, достаточном для независимой (без обращения к Подрядчику) реализации третьими сторонами; – термины, обозначения и наименования, используемые в ПО, должны быть стандартизованы и унифицированы, выполнены на русском языке; – взаимодействие элементов и их внешнее поведение должно быть реализовано одинаково и производиться по единым правилам - 4.5.11. Требования к показателям назначения 4.5.11.1. Требования к показателям назначения мероприятий по развитию Модуля СЦ В рамках выполнения работ по развитию Модуля СЦ, предусмотренных ТЗ, показатель назначения «Количество пользователей» должен соответствовать значениям, приведенным в данном разделе. Пояснения по показателям, связанным с количеством пользователей, приведены в Таблице 8. Таблица 8. Определения показателей, связанных с количеством пользователей в Модуле СЦ № Показатель Определение Расчетное количество пользователей Количество пользователей, работу которых должен обеспечить Модуль СЦ к моменту сдачи работ по Контракту с учетом достижения всех показателей назначения Расчетное количество одновременно работающих пользователей Количество одновременно работающих пользователей, работу которых должен обеспечивать Модуль СЦ к моменту сдачи работ по Контракту с учетом достижения всех показателей назначения Значения показателей количества пользователей, достижение которых необходимо обеспечить, представлено в Таблице 9 - Таблица 9. Значения показателей количества пользователей № Показатель Значение 1. Расчетное количество пользователей 1 000 2. Расчетное среднее количество одновременно работающих пользователей 200 Развитие Модуля СЦ должно быть направлено на достижение следующего эффекта (показателя), подставленного в мероприятии 103.002 «Информационно-аналитическая система регулирования на транспорте (АСУ ТК)» ВПЦТ Минтранса России: Выполнение работ по развитию Модуля СЦ предусмотрено мероприятием по развитию АСУ ТК, приведенном в ВПЦТ Минтранса России на 2026-2028 гг: № 103.002 «АСУ ТК» в составе ИТ расхода 103.26.000005 «Развитие предусматривает реализацию ОКР и эффектов, приведенных в Таблице 10. Таблица 10. ОКР и эффекты, приведенные в ВПЦТ Минтранса России на 2026 г. № ОКР Дата ОКР Эффекты 1 Обеспечено информационное взаимодействие с Минобороны России о происшествиях на транспортных объектах 25.12.2026 Сокращено время сбора и передачи сведений для Минобороны России о ЧС и НС на транспорте с 120 до 10 минут 2 Обеспечена автоматизация формирования отчетов о нештатных ситуациях на транспорте, в том числе по данным внешних систем 25.12.2026 Сокращено время на подготовку отчетов о нештатных ситуациях на транспорте с 20 до 5 минут Реализация остальных ОКР не является предметом данного ТЗ и проводится в рамках отдельного технического задания. - 4.5.11.2. Требования к показателям назначения мероприятий по эксплуатации Модуля СЦ. Работы по эксплуатации Модуля СЦ не должны обеспечивать режимы функционирования Модуля СЦ, приведенные в разделе 4.5.2 данного ТЗ - 5. СОСТАВ И СОДЕРЖАНИЕ РАБОТ ПО РАЗВИТИЮ И ТЕХНИЧЕСКОЙ ПОДДЕРЖКЕ МОДУЛЯ СЦ (КАЛЕНДАРНЫЙ ПЛАН) - 1 Техническое проектирование Сопроводительным письмом предоставляются Заказчику: · Технический проект, включая следующие документы: – Ведомость технического проекта; – Ведомость машинных носителей информации – Пояснительная записка; – Описание информационного обеспечения системы; – Описание автоматизируемых функций; – Схема функциональной структуры; – Описание организации информационной базы; – Описание программного обеспечения; · Макеты экранных форм компонента «Интерактивная карта»; · Руководство по безопасной разработке программного обеспечения; · Документ о приемке Начало: с даты заключения контракта Окончание: не позднее 31.07.2026 - - Значение характеристики не может изменяться участником закупки - 2 Услуги по технической поддержке Модуля СЦ (с даты заключения контракта по 10.09.2026) По окончании оказания Услуг сопроводительным письмом предоставляются Заказчику: – Отчет об оказанных Услугах по технической поддержке; – Актуальные на дату окончания оказания Услуг по данному этапу исходные коды прикладного ПО на электронном носителе (в случае внесения изменений); – Инструкция по сборке и развертыванию (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство пользователя (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство администратора (в случае внесения изменений); – Документ о приемке Начало: с даты заключения контракта Окончание: не позднее 10.09.2026 - 3 Разработка программного обеспечения (1 очередь, пп. 4.2.1, 4.2.6 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ; – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 1 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 1 очереди; – Руководство по резервному копированию; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 16.09.2026 - 4 Разработка программного обеспечения (2 очередь, пп. 4.2.3, 4.2.4 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ. – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 2 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 2 очереди; – Руководство по резервному копированию; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 25.09.2026 - Работы по развитию Системы (за исключением этапов проведения опытной эксплуатации и услуг по технической поддержке) могут быть выполнены досрочно. При досрочном выполнении работ (этапов работ) Подрядчик в письменной форме уведомляет Заказчика о готовности представить для приемки результаты проведения работ в соответствии с требованиями Контракта. Подрядчик также вправе досрочно приступать к работам в рамках очередного этапа при наличии технической, организационной готовности - при условии получения соответствующего согласования Заказчиком. Сдача-приемка результатов выполненных работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная, техническая документация, а также результаты Работ по каждому этапу предоставляется Заказчику в порядке, предусмотренном Контрактом и настоящим Техническим заданием, до размещения Подрядчиком в Единой информационной системе в сфере закупок документа о приемке. Документ о приемке размещается в ЕИС по каждому этапу в соответствии с условиями Контракта. Согласование документов осуществляется в электронном виде посредством переписки с адресов электронной почты Заказчика и Подрядчика, указанных в контракте. - Сдача-приемка результатов выполненных работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная техническая документация, а также результаты работ предоставляются Заказчику в порядке, предусмотренном Контрактом и ТЗ, до размещения Подрядчиком в ЕИС документа о приемке. Документ о приемке размещается в ЕИС по каждому этапу в соответствии с условиями Контракта. Этапы выполнения работ по развитию Модуля СЦ приведены в Таблице 11. Таблица 11. Этапы выполнения работ по развитию Модуля СЦ. № этапа Наименование этапа Результат (отчетная документация) Срок исполнения этапа - 5 Разработка программного обеспечения (3 очередь, пп. 4.2.2, 4.2.5 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ; – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 3 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 3 очереди; – Руководство по резервному копированию; – Описание ролевой модели; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 09.10.2026 - 6 Опытная эксплуатация (1 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акт о завершении опытной эксплуатации 1 очереди; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке 17.09.2026 Окончание: не позднее 26.10.2026 - 7 Опытная эксплуатация (2 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акт о завершении опытной эксплуатации 2 очереди; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке 26.09.2026 Окончание: не позднее 26.10.2026 - 8 Опытная эксплуатация (3 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Акт о завершении опытной эксплуатации 3 очереди; – Документ о приемке Начало: с 10.10.2026 Окончание: не позднее 26.10.2026 - 9 Приемочные испытания Сопроводительным письмом предоставляются Заказчику: – Программа и методика приёмочных испытаний; – Протокол приемочных испытаний; – Исходные коды и дистрибутивы на электронном носителе (при условии внесения изменений, с учетом доработок по результатам опытной эксплуатации и проведенных испытаний); – Комплект рабочей документации на Модуль СЦ (при условии внесения изменений, с учетом доработок по результатам опытной эксплуатации и проведенных испытаний); – Акт приемки Системы в эксплуатацию; – Акт приемки-передачи исключительных прав на объект; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке; – Документы в соответствии с разделом 4.5.9 ТЗ; – Обеспечение гарантийных обязательств Начало: с 27.10.2026 Окончание: не позднее 10.11.2026 - 10 Услуги по технической поддержке Модуля СЦ (с 11.09.2026 по 15.12.2026) По окончании оказания Услуг сопроводительным письмом предоставляются Заказчику: – Отчет об оказанных Услугах по технической поддержке; – Актуальные на дату окончания оказания Услуг по данному этапу исходные коды прикладного ПО на электронном носителе (в случае внесения изменений); – Инструкция по сборке и развертыванию (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство пользователя (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство администратора (в случае внесения изменений); – Документ о приемке Начало: с 11.09.2026 Окончание: не позднее 15.12.2026 - 6. ПОРЯДОК РАЗРАБОТКИ МОДУЛЯ СЦ - Проектирование Модуля СЦ должно включать разработку следующих документов: – Ведомость технического проекта; – Ведомость машинных носителей информации – Пояснительная записка; – Описание информационного обеспечения системы; – Описание автоматизируемых функций; – Схема функциональной структуры; – Описание организации информационной базы; – Руководство по безопасной разработке программного обеспечения; – Описание программного обеспечения; – Макеты экранных форм компонента «Интерактивная карта». Структура документов должна соответствовать ГОСТ Р 59795-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов». Разработка Модуля СЦ должна включать в себя: – разработку программного обеспечения в части новых функций Модуля СЦ; – сборка исходного кода, развертывание и настройку доработанного программного обеспечения Модуля СЦ на вычислительных мощностях Заказчика (тестовый контур); – Комплект рабочей документации на Модуль СЦ; – разработку документа «Программа и методика предварительных испытаний»; – разработку документа «Программа и методика приемочных испытаний»; – разработку документа «Программа опытной эксплуатации». Структура документов должна соответствовать ГОСТ Р 59795-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов». В ходе выполнения работ формируется правоустанавливающая, отчетная, рабочая и техническая документация в соответствии с Контрактом и Календарным планом, приведенном в разделе 5. - - Значение характеристики не может изменяться участником закупки - 6.1. Сведения о гарантийном обслуживании Модуля СЦ Под гарантией понимается устранение Подрядчиком своими силами и за свой счет допущенных по его вине недостатков, выявленных после приемки выполненных Работ, как в работе самой Модуля СЦ, так и недостатков в отчетной документации. Если в период гарантийного срока обнаружатся недостатки, то Подрядчик обязан устранить их за свой счет, в сроки, установленные Заказчиком. Гарантийный срок в этом случае продлевается на период устранения недостатков. Срок гарантии: 1 год с даты приемки Заказчиком результатов исполнения Этапа № 9 контракта. Подрядчиком должны быть внесены соответствующие исправления в техническую и рабочую документацию (указанную в пунктах 5 и 6 настоящего ТЗ), связанные с устранением замечаний к работе Модуля СЦ или в случае выявления Заказчиком недостатков в такой документации в период гарантийного срока. Внесение изменений в документацию технического и рабочего проектирования осуществляется в соответствии с ГОСТ 2.503-2023 и ГОСТ Р 2.504-2021. - 7. ПОРЯДОК КОНТРОЛЯ И ПРИЕМКИ РЕЗУЛЬТАТОВ ВЫПОЛНЕНИЯ РАБОТ ПО РАЗВИТИЮ МОДУЛЯ СЦ - До момента подключения внешних ИС, Подрядчиком могут быть использованы эмуляторы ИС для прохождения предварительных испытаний, опытной эксплуатации и приемочных испытаний. В рамках опытной эксплуатации должны быть проведены мероприятия по нагрузочному тестированию Модуля СЦ. Документ «Программа и методика приемочных испытаний» должен быть разработан с учетом недостатков, выявленных в ходе опытной эксплуатации, утвержден Заказчиком до начала приемочных испытаний, при этом проверки Модуля СЦ в части не устраненных недостатков, выявленных в процессе опытной эксплуатации, должны быть вынесены в отдельный раздел «Программы и методики приемочных испытаний». В процессе приемочных испытаний должно быть проверено устранение недостатков, полученных в ходе опытной эксплуатации. После завершения устранения всех замечаний, препятствующих приемке Системы в эксплуатацию, перечисленных в Протоколе приемочных испытаний, Подрядчик должен письменно уведомить Заказчика о том, что все замечания устранены, после чего приемочные испытания по решению Заказчика могут быть проведены повторно. Процедура приемочных испытаний проводится до подписания Протокола приемочных испытаний, не содержащего замечаний, препятствующих приемке Системы в эксплуатацию. Приемочные испытания Системы считаются завершенными успешно, если Протокол приемочных испытаний не содержит замечаний, препятствующих приемке Системы в эксплуатацию - - Значение характеристики не может изменяться участником закупки - Испытания должны быть организованы и проведены в соответствии с ГОСТ Р 59792-2021 «Информационная технология. Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем». Должны быть проведены следующие виды испытаний: – предварительные испытания; – опытная эксплуатация; – приемочные испытания. Указанные виды испытаний проводятся в отношении не функциональных требований и функциональных возможностей, разрабатываемых в соответствии с настоящим ТЗ. Отдельные виды испытаний проводятся поэтапно в сроки, установленные Календарным планом. Предварительные испытания, опытная эксплуатация, приемочные испытания проводятся комиссией, создаваемой организационно-распорядительным документом Заказчика, который должен определять состав комиссии, порядок ее работы. Методы предварительных испытаний и порядок их проведения должны быть определены в документе «Программа и методика предварительных испытаний», который должен быть утвержден Заказчиком до начала предварительных испытаний. По результатам предварительных испытаний оформляется Протокол предварительных испытания и Акт о приемке в опытную эксплуатацию. Порядок проведения и методы испытаний во время опытной эксплуатации должны быть определены в документе «Программа опытной эксплуатации», который должен быть утвержден Заказчиком до начала опытной эксплуатации. Ход и результаты опытной эксплуатации отражаются в документе «Журнал опытной эксплуатации», и учитываются в ходе приемочных испытаний. По результатам опытной эксплуатации подписывается Акт о завершении опытной эксплуатации - 8. ТРЕБОВАНИЯ К СОСТАВУ И СОДЕРЖАНИЮ РАБОТ ПО ПОДГОТОВКЕ МОДУЛЯ СЦ К ВВОДУ В ЭКСПЛУАТАЦИЮ - По результатам проведения приемочных испытаний оформляется Протокол приемочных испытаний и Акт приемки в эксплуатацию. В случае, если взаимодействие с внешними системами не может быть проверено на средах постоянной эксплуатации взаимодействующих систем (по причине неготовности со стороны внешней системы или иным причинам), функции взаимодействия, разработанные в соответствии с требованиями ТЗ, должны быть проверены на тестовых данных с использованием программ-имитаторов взаимодействия. По результатам выполнения этапа приемочных испытаний должны быть подготовлены материалы для регистрации доработанной версии Модуля СЦ (объекта учета) в НФАП в соответствии с требованиями постановления Правительства Российской Федерации от 30 января 2013?г. №?62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин» (с изменениями и дополнениями) в части обязательности размещения результатов работ в национальном фонде алгоритмов и программ для электронных вычислительных машин. Сдача-приемка результатов выполнения Работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная, техническая документация, а также программное обеспечение предоставляется Заказчику в порядке, предусмотренном Контрактом и ТЗ до размещения Подрядчиком в Единой информационной системе в сфере закупок документа о приемке. Результаты проведения опытной эксплуатации, предварительных и приемочных испытаний должны быть зафиксированы в соответствующих протоколах и актах. Выявленные отклонения от настоящего ТЗ, оформляются как недостатки Модуля СЦ - - Значение характеристики не может изменяться участником закупки - Протоколы предварительных и приемочных испытаний должны содержать вывод о соответствии Модуля СЦ предъявляемым требованиям, а также сроки устранения замечаний и реализации рекомендаций, сформулированных комиссией в ходе предварительных и приемочных испытаний. Условием для передачи Модуля СЦ в промышленную эксплуатацию является устранение всех замечаний. Документация на Модуль СЦ и ее части (техническая и рабочая) должна содержать исчерпывающее описание принятых проектных решений в объеме, достаточном для ее дальнейшего развития и эксплуатации. Техническая и рабочая документация должна содержать описание разработанных результатов работ, в том числе программ для ЭВМ, прикладных программных интерфейсов, алгоритмов и протоколов информационного взаимодействия, технических требований, спецификаций и форматов обмена данными для взаимодействия с другими информационными системами, в объеме, достаточном для их установки, настройки, эксплуатации и развития в дальнейшем без привлечения Подрядчика. Исходные коды передаются в виде и составе, позволяющем провести: – сборку (компиляцию) Модуля СЦ в контролируемой Заказчиком среде; – установку полученной Модуля СЦ на специально подготовленную контролируемую Заказчиком инфраструктуру; – проверку функциональных возможностей Модуля СЦ; – оформление Модуля СЦ в качестве объекта национального фонда алгоритмов и программ для электронных вычислительных машин - 8.1. Требования, предъявляемые в соответствии с Приказом Минцифры России от 17.12.2020 № 715 «Об утверждении типовых условий контрактов на выполнение работ по созданию и (или) развитию (модернизации) государственных (муниципальных) и (или) иных информационных систем» Передача исходных кодов, разработанных в ходе выполнения работ, программ для электронных вычислительных машин (далее – программа для ЭВМ) должна сопровождаться передачей всех необходимых для сборки и запуска программы для ЭВМ библиотек зависимостей, программных сценариев (скриптов) для проведения установки (развертывания) программы для ЭВМ. Подрядчик в процессе сдачи-приемки работ по Контракту должен провести демонстрацию процесса и установки (развертывания) разработанных программ для ЭВМ. Документация на Модуль СЦ должна содержать описание принятых проектных решений в объеме, достаточном для ее дальнейшего развития и эксплуатации - 9. ТРЕБОВАНИЯ К ДОКУМЕНТИРОВАНИЮ - 9.1. Общие требования Документация на Модуль СЦ должна быть разработана в составе, указанном в разделах 5-8 данного ТЗ, и должна удовлетворять требованиям комплекса стандартов и руководящих документов на автоматизированные системы: – ГОСТ Р 2.105-2019 в части оформления текстовых документов; – ГОСТ 34.201-2020 в части наименования и обозначения документов. Документация на Модуль СЦ должны оформляться на листах формата А4. Допускается для размещения рисунков и таблиц использование листов формата А3 с подшивкой по короткой стороне листа. Документы объемом более 25 (двадцати пяти) листов должны содержать информационную часть, состоящую из аннотации и содержания. Исходные коды должны быть представлены в 1 (одном) экземпляре на электронном носителе, отчетные материалы должны быть представлены в 2 (двух) экземплярах на бумажном носителе (по одному экземпляру для Заказчика и Подрядчика) и в 1 (одном) экземпляре на электронном носителе в формате документов DOCX и PDF. При разработке документов на Модуль СЦ допускается отклонение от требований комплекса стандартов, описанных выше. Документам на Модуль СЦ должны в обязательном порядке присваиваться уникальные децимальные номера в соответствии с порядком, установленном в ГОСТ 34.201-2020. Документ «Программа и методика предварительных испытаний» должен включать приложения с формой протокола предварительных испытаний и формой акта приемки в опытную эксплуатацию. Документ «Программа опытной эксплуатации» должен включать приложение с формой журнала опытной эксплуатации. Документ «Программа и методика приемочных испытаний» должен включать приложения с формой протокола приемочных испытаний и формой акта приемки в эксплуатацию - - Значение характеристики не может изменяться участником закупки - 10. ИСТОЧНИКИ РАЗРАБОТКИ - 10.1. Список литературы Специальная литература для разработки ТЗ не использовалась. 10.2. Нормативно-методические документы Список используемых нормативно-методических документов представлен в разделе 1.6 технического задания. ? Приложение А Эскизы визуального оформления компонента «Интерактивная карта» - - Значение характеристики не может изменяться участником закупки - Приложение Б Параметры оказания услуг - Б.1. Базовые параметры оказания Услуг Базовые параметры оказания Услуг приведены ниже: – режимы оказания Услуг (таблица Б.1.1); – сроки предоставления отчетности (таблица Б.1.2). Таблица Б.1.1 - Режимы оказания Услуг № п/п Параметр Значение - - Значение характеристики не может изменяться участником закупки - Б.2. Приоритеты и регламентные сроки решения обращений (заявок) В зависимости от уровня сбоя в работе Системы обращению (заявке) присваивается один из следующих приоритетов, а также в зависимости от приоритета обращения (заявки) устанавливаются следующие контрольные сроки решения в соответствии с таблицей ниже (Таблица Б.2.1). Таблица Б.2.1 – Приоритеты и регламентные сроки решения обращений (заявок) № п/п Приоритет Максимальное время реагирования Время решения (срок выполнения) Описание приоритета По информационно-консультационной поддержке сотрудников Заказчика и пользователей Системы 1 - не более 1 часа не более 10 часов - По решению инцидентов, связанных с работой ППО: 1 Критический не более 30 минут не более 4 часов - полная недоступность ППО; - недоступность ключевых функций - ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО; - невозможность информационного обмена с ППО для ИС более 4 часов 2 Высокий не более 1 часа не более 8 часов - ошибки/сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; - снижение быстродействия СПО (время отклика ППО на операции превышает 30 секунд); - недоступность управления правами и ролями пользователей 3 Средний не более 4 часов не более 24 часов - невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым -недоступность функции формирования отчетов 4 Низкий не более 8 часов не более 40 часов - отклонение в работе ППО, не влияющее на корректную работу функций; - другие сбои и ошибки, затрагивающие основные функции ППО - По адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) 1 Критический не более 40 минут не более 8 часов - изменения, необходимые при проведении аварийно-восстановительных работ для возобновления работоспособности Системы; - изменения, связанные с критичными ошибками, блокирующими возможность оказания государственных услуг и/или чтение и внесение данных в Систему 2 Высокий не более 1 часа не более 40 часов - изменения, относящиеся к обеспечению работоспособности основной функциональности Системы, устраняют выявленные дефекты в работе Системы, оказывающие существенное влияние на работу пользователей в Системе; - изменения, затрагивающие три и более подсистемы/модуля Системы для адаптации 3 Средний не более 4 часов не более 72 часов - изменения, связанные с развитием/улучшением/оптимизацией Системы и выводом новой функциональности в штатном режиме для одного-двух модулей/подсистем; - изменения, связанные с развитием интеграционных механизмов Системы, например обновление существующих и/или реализация новых видов сведений СМЭВ, обновление существующих и/или реализация новых API, адаптация и/или изменение механизмов импорта и экспорта данных Системы и т.д. 4 Низкий не более 8 часов не более 160 часов - изменения, связанные с ошибками/корректировкой/изменением в отображении информации в пользовательском графическом интерфейсе Системы (графика, текст, органы управления, элементы интерфейса) - 1 Режим работы Системы Круглосуточно (24х7) 2 Режим доступности информационно-консультационной поддержки пользователей Системы 2.1 Прием и регистрация обращений (заявок) в СРО Регистрация обращений (заявок) производится круглосуточно в режиме 24х7, без праздников и выходных дней. Обработка заявок первой линией поддержки осуществляется в рабочие дни с 9 до 18 часов 2.2 Консультирование сотрудников Заказчика и пользователей Системы в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 3 Режим доступности по решению инцидентов, связанных с работой ППО: 3.1 - приоритет «Критический» Круглосуточно (24х7) 3.2 - приоритет «Высокий» Круглосуточно (24х7) 3.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 3.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4 Режим доступности услуг по адаптации, конфигурации и коррекционному сопровождению Системы 4.1 - приоритет «Критический» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.2 - приоритет «Высокий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 5 Режим доступности по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности 5.1 - приоритет «Критический» Круглосуточно (24х7) 5.2 - приоритет «Высокий» Круглосуточно (24х7) 5.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 5.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) - Таблица Б.1.2. Сроки предоставления отчетности, с момента получения запроса № п/п Параметр Значение 1 Предоставление отчета об оказанных услугах за произвольный период 10 рабочих дней 2 Предоставление подробной информации по инциденту с приоритетом «Критический» 16 рабочих часов 3 Предоставление актуализированной документации 10 рабочих дней - По устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности 1 Критический не более 30 минут не более 24 часов - критические уязвимости, влияющие на возможную полную недоступность ППО, ключевых функций Системы, ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО без возможности восстановления работоспособности Системы. - Критический уровень CVSS > 8.0 2 Высокий не более 1 часа не более 84 часов - критические уязвимости, влияющие на ошибки и сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО. - Высокий уровень CVSS 5.0 - 8.0 3 Средний не более 4 часов не более 120 часов - уязвимости, влияющие на невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым - Средний уровень CVSS 2.0 - 4.9 4 Низкий не более 8 часов не более 160 часов - уязвимости, влияющие на отклонение в работе ППО, не влияющее на корректную работу функций; - другие сбои и ошибки, затрагивающие основные функции ППО - Низкий уровень CVSS < 2.0 - Взаимодействие Заказчика и Подрядчика в части регистрации и контроля времени реагирования и решения обращения (заявки) осуществляется через СРО. Заказчик предоставляет Подрядчику доступ к СРО после заключения Контракта. Поступившие от разных пользователей заявки по поводу однотипных инцидентов или имеющие общую причину должны объединяться в одну заявку. Срок выполнения включает время диагностики инцидента, в ходе которого определяется причина инцидента (проблемы) и способ его устранения. Подрядчик должен обеспечить функционирование Модуля СЦ в соответствии с требованиями и параметрами, указанными в настоящем ТЗ и Регламенте оказании услуг. Основные параметры быстродействия типовых операций в Модуле СЦ указаны в таблице ниже (таблица Б.2.2). Таблица Б.2.2 - Параметры быстродействия Модуля СЦ № п/п Наименование параметра Значение (секунд) 1 Среднее время получения сообщения из очереди сообщений 10 2 Среднее время получения ответа от Системы 5 3 Среднее время открытия карточки реестра 5 - Приложение В Регламент оказания услуг - Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 8) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 8) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 8) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 8) Категория обращения (заявки): инцидент Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 8) Приоритет Время, очередность решения обращения (заявки), ресурсы, привлекаемые для решения обращения (заявки), порядок/процедура действий при решении обращения (заявки) – поле СРО «Приоритет» (см. рисунок 8) Тип изменения Справочник, классифицирующий типовые запросы характерные для Системы – поле СРО «Предмет обращения» (см. рисунок 8) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 8) Текст запроса на оказание услуги по обновлению или удалению уязвимых компонентов (библиотек) ППО в соответствии с требованиями к обеспечению информационной безопасности Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 8) - - Значение характеристики не может изменяться участником закупки - На рисунке 8 приведена форма обращения (заявки) типа «Инцидент» в СРО. Рисунок 8 - Форма обращения (заявки) типа «Инцидент» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуги по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности, заполненную в свободной форме - Приложение 1 к Регламенту Матрица ответственных за взаимодействия в рамках выполнения работ по техническому сопровождению Системы Таблица 1 – Ответственные за взаимодействия в рамках выполнения работ по техническому сопровождению Системы со стороны Исполнителя ФИО Должность Адрес электронной почты Телефон — — — Общий контакт - Приложение 2 к Регламенту Приоритеты и регламентные сроки решения обращений (заявок) Приоритеты и регламентные сроки решения обращений (заявок) приведены в таблице 1. Таблица 1 – Приоритеты и регламентные сроки решения обращений (заявок) № п/п Приоритет Максимальное время реагирования Время решения (срок выполнения) Описание приоритета - По информационно-консультационной поддержке сотрудников Заказчика и пользователей Системы 1 – не более 1 часа не более 10 часов – - По решению инцидентов, связанных с работой ППО 1 Критический не более 30 минут не более 4 часов – полная недоступность ППО; – недоступность ключевых функций; – ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО; – невозможность информационного обмена с ППО для ИС более 4 часов 2 Высокий не более 1 часа не более 8 часов – ошибки/сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; – снижение быстродействия СПО (время отклика ППО на операции превышает 30 секунд); – невозможность управления правами и ролями пользователей 3 Средний не более 4 часов не более 24 часов – невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым недоступность функции формирования отчетов 4 Низкий не более 8 часов не более 40 часов – отклонение в работе ППО, не влияющее на корректную работу функций; – другие сбои и ошибки, затрагивающие основные функции ППО - По адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) 1 Критический не более 40 минут не более 8 часов – изменения необходимые при проведении аварийно-восстановительных работ для возобновления работоспособности Системы; – изменения, связанные с критичными ошибками, блокирующими возможность оказания государственных услуг и/или чтение и внесение данных в Систему 2 Высокий не более 1 часа не более 40 часов – изменения относящиеся к обеспечению работоспособности основной функциональности Системы, устраняют выявленные дефекты в работе Системы, оказывающие существенное влияние на процесс оказания государственных услуг и работу пользователей в Системе; – изменения, затрагивающие три и более подсистемы/модуля Системы для адаптации 3 Средний не более 4 часов не более 72 часов – изменения, связанные с развитием/улучшением/оптимизацией Системы и выводом новой функциональности в штатном режиме для одного-двух модулей/подсистем; – изменения, связанные с развитием интеграционных механизмов Системы, например, обновление существующих и/или реализация новых видов сведений СМЭВ, обновление существующих и/или реализация новых API, адаптация и/или изменение механизмов импорта и экспорта данных Системы и т.д. 4 Низкий не более 8 часов не более 160 часов – изменения, связанные с ошибками/ корректировкой/изменение в отображении информации в пользовательском графическом интерфейсе Системы (графика, текст, органы управления, элементы интерфейса) - По устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности 1 Критический не более 30 минут не более 24 часов – критические уязвимости, влияющие на возможную полную недоступность ППО, ключевых функций Системы, ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО без возможности восстановления работоспособности Системы; – Критический уровень CVSS > 8.0 2 Высокий не более 1 часа не более 84 часов – критические уязвимости, влияющие на ошибки и сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; – Высокий уровень CVSS 5.0 - 8.0 3 Средний не более 4 часов не более 120 часов – уязвимости, влияющие на невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым; – Средний уровень CVSS 2.0 - 4.9 4 Низкий не более 8 часов не более 160 часов – уязвимости, влияющие на отклонение в работе ППО, не влияющее на корректную работу функций; – другие сбои и ошибки, затрагивающие основные функции ППО; – Низкий уровень CVSS < 2.0 - Приложение Г Форма Отчета об оказанных услугах Отчет об оказанных услугах за этап «наименование этапа» в период с «__» _________ по «__» _________. № п/п Наименование услуги Общее количество Номер ОРС Краткое Описание Время реагирования по ТЗ Время реагирования фактическое Время решения по ТЗ Время решения фактическое Результат соблюдения времени реагирования Результат соблюдения времени решения Примечание 1 Услуги по информационно-консультационной поддержке работников Заказчика 2 546782 Консультация по работе Модуля СЦ 1 2 10 часов 11 часов Нет Нет 567123 Консультация по схеме БД 1 1 10 часов 1 час Да Да 2 … … Заказчик Подрядчик /Должность/ /Должность/ ____________________ /Ф.И.О/ ___________________ /Ф.И.О/ М.П. М.П. «_____»_______________________202_г. «_____»_______________________202_г - Приложение 1 к Отчету об оказанных услугах Журнал обращений (заявок) на оказание услуги по информационно-консультационной поддержке пользователей Системы (шаблон) Наименование Исполнителя в этапе «наименование этапа» в период с ________________ по _______________ оказал(о) Услугу по поддержке пользователей Системы в объеме, указанном в Таблице 1 Таблица 1 - Журнал обращений (заявок) пользователей Системы № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. ИТОГО зарегистрировано: Всего обращений (заявок): ________ ИТОГО решено: Всего обращений (заявок): ________ - Приложение 2 к Отчету об оказанных услугах Журнал обращений (заявок) по решению инцидентов, связанных с работой ППО (шаблон) Наименование Исполнителя в этапе «наименование этапа» в период с ________________ по _______________ оказал(о) Услугу по решению инцидентов в объеме, указанном в Таблице 1. Таблица 1 - Журнал по решению инцидентов № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. ИТОГО зарегистрировано: Всего инцидентов: ________ ИТОГО решено: Всего инцидентов: ________ - Приложение 3 к Отчету об оказанных услугах Журнал обращений (заявок) выполнения адаптационного, конфигурационного и коррекционного сопровождения Системы (шаблон) Журнал выполнения адаптации, конфигурации и коррекции Системы сформирован за этап «наименование этапа» в период с «__» _________ по «__» ____________ и представлен в таблице ниже (Таблица 1). Таблица 1 - Журнал выполнения адаптации, конфигурации и коррекции сопровождения Системы № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. Количество выполненных заявок за этап: ________ - Приложение 4 к Отчету об оказанных услугах Журнал обращений (заявок) по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности (шаблон) Журнал обращений (заявок) по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности сформирован за этап «наименование этапа» в период с «__» _________ по «__» ____________ и представлен в таблице ниже (Таблица 1). Таблица 1 - Журнал выполнения заявок по устранению уязвимостей в ППО № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. Количество выполненных заявок за этап: ________ - Приложение Д Форма Протокола проверки результатов организационно-штатных и подготовительных мероприятий (шаблон) Протокол проверки результатов организационно-штатных и подготовительных мероприятий Настоящий Протокол содержит результаты проверки организационно-штатных и подготовительных мероприятий, проведенных Исполнителем (Таблица Д.1). Таблица Д.1. Протокол проверки результатов № Мероприятия Подготовительного этапа Результат проверки 1. Определить и направить Заказчику документ «Ответственные за взаимодействия в рамках выполнения работ по техническому сопровождению Системы со стороны Исполнителя». Документ содержит контактную информацию (ФИО, должность, адрес электронной рабочей почты, номер телефона) не менее чем о 2 лицах, ответственных за оказание услуг со стороны Подрядчика Выполнено/Не выполнено 2. Обеспечить подключение специалистов Подрядчика к Системе Выполнено/Не выполнено 3. Обеспечить подключение специалистов Подрядчика к СРО Выполнено/Не выполнено Заказчик Подрядчик /Должность/ /Должность/ ____________________ /Ф.И.О/ ___________________ /Ф.И.О/ М.П. М.П. «_____»_______________________202_г. «_____»_______________________202_г - Изменение приоритета уже зарегистрированного обращения (заявки) используется в случае появления новых обстоятельств, которые ведут к изменению влияния и/или срочности существующего обращения (заявки). При регистрации обращения (заявки) необходимо провести его приоритизацию. В процессе управления обращениями (заявками) каждому обращению (заявке) присваивается приоритет, принимающий одно из значений: Низкий, Средний, Высокий или Критический. В соответствии с приоритетом определяется время, очередность устранения, , ресурсы, привлекаемые для работ по обращению (заявке), а также может определяться порядок/процедура действий при работе с обращением (заявкой). Заказчиком в зависимости от уровня сбоя в работе Системы обращению (заявке) присваивается приоритет с указанием максимального времени реакции и решения в соответствии с требованиями, указанными в Приложении 2 к настоящему Регламенту - 4 Формы обращений (заявок) на оказание услуг по технической поддержке Системы, заполняемые в СРО 4.1. Форма обращения (заявки) на оказание услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы При подаче обращения (заявки) типа «ЗНО» в СРО указывается (Таблица 5): Таблица 5 – Описание атрибутов формы обращения (заявки) на оказание услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 5) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 5) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 5) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 5) Категория обращения: информационно-консультационная поддержка Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 5) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 5) Текст запроса на оказание услуги по информационно-консультационной поддержке сотрудников Заказчика Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 5) - На рисунке 5 приведена форма обращения (заявки) типа «ЗНО» в СРО. Рисунок 5 - Форма обращения (заявки) типа «ЗНО» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы, заполненную в свободной форме. - 4.2. Форма обращения (заявки) на оказание услуги по решению инцидентов, связанных с работой ППО При подаче обращения (заявки) типа «Инцидент» в СРО указывается (Таблица 6): Таблица 6 – Описание атрибутов формы обращения (заявки) на оказание услуги по решению инцидентов, связанных с работой ППО Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 6) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 6) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 6,) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 6) Категория обращения (заявки): инцидент Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 6) Приоритет изменения Время - одно из значений: Низкий, Средний, Высокий или Критический. Определяет, очередность решения обращения (заявки), ресурсы, привлекаемые для решения обращения (заявки), порядок/процедура действий при решении обращения (заявки) – поле СРО «Приоритет» (см. рисунок 6,) - Тип изменения Справочник, классифицирующий типовые запросы характерные для Системы – поле СРО «Предмет обращения» (см. рисунок 6) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 6) Полное описание инцидента, включая скриншоты и описание шагов, приведших к неисправности Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 6) Однократность/неоднократность Круг пользователей или компьютеров, затронутых данным инцидентом Действия, предпринятые для самостоятельного решения инцидента (при наличии) Версии используемого программного обеспечения на клиентской рабочей станции, где воспроизводится ошибка (операционная система, прикладное программное обеспечение) Дополнительная информация - На рисунке 6 приведена форма обращения (заявки) типа «Инцидент» в СРО. Рисунок 6 - Форма обращения (заявки) типа «Инцидент» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуги по решению инцидентов, связанных с работой ППО, заполненную в свободной форме - 4.3. Форма обращения (заявки) на оказание услуг по адаптационному конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) При подаче обращения (заявки) типа «ЗНИ» в СРО указывается (Таблица 7): Таблица 7 – Описание атрибутов формы обращения (заявки) на оказание услуг по адаптационному, конфигурационному и коррекционному сопровождению Системы Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 10) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 9) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 10) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 10) Категория обращения (заявки): запрос на изменение Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 7) Приоритет изменения Время, очередность решения обращения (заявки), ресурсы, привлекаемые для решения обращения (заявки), порядок/процедура действий при решении обращения (заявки) – поле СРО «Приоритет» (см. рисунок 7) Тип изменения Справочник, классифицирующий типовые запросы характерные для Системы – поле СРО «Предмет обращения» (см. рисунок 7) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 7) Текст запроса на оказание услуги по адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 7) - На рисунке 7 приведена форма обращения (заявки) типа «ЗНИ» в СРО. Рисунок 7 - Форма обращения (заявки) типа «ЗНИ» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуг по адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей), заполненную в свободной форме - 4.4. Форма обращения (заявки) на оказание услуги по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности При подаче обращения (заявки) типа «Инцидент» в СРО указывается (Таблица 8): Таблица 8 – Описание атрибутов формы обращения (заявки) на оказание услуг по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности - Третий уровень технической поддержки (далее – 3-й уровень) Группа ответственных сотрудников Исполнителя, отвечающая за устранение сбоев и аварий, проведение информационно-консультационной поддержки пользователей Системы, проведение адаптации и конфигурирования Системы в объемах действующих контрактов на оказание технической поддержки - 3.3 Перечень и описание статусов обращений (заявок) В Таблице 3 приведен перечень статусов обращений (заявок), действующий в СРО, и их описание. Таблица 3 - Перечень статусов обращений (заявок) и их описание Статус Описание Зарегистрирован Обращение (заявка) принято и зарегистрировано Направлен в группу Присваивается при назначении ответственными сотрудниками 1-го уровня группе ответственных сотрудников 2-го уровня по тематике обращения (заявки) после заполнения всей необходимой информации и полей обращения (заявки), а также при его передаче между группами 2-го уровня Передан в группу Присваивается при передаче обращения (заявки) ответственными сотрудниками 2-го уровня на группу ответственных сотрудников 3-го уровня Назначен Присваивается при назначении обращения (заявки) на ответственного сотрудника для его решения в рамках компетенции В работе Присваивается при приеме обращения (заявки) в работу ответственным сотрудником для его решения Решен Присваивается ответственным сотрудником, выполнившим работы по обращению (заявке) Закрыт Присваивается автоматически при решении запроса по обращению (заявке), а также отсутствии дополнительных запросов пользователя в соответствии с действующим SLA, или при подтверждении решения обращения (заявки) со стороны пользователя Запрос доп. информации Присваивается при необходимости запроса дополнительной информации и/или уточнения предмета обращения по обращению (заявке) у пользователя Ответ предоставлен Присваивается после ответа пользователем на запрос дополнительной информации Отклонен Присваивается, если обращение (заявка) не актуальна (по информации от пользователя), отсутствует техническая возможность решения обращения (заявки), предмет обращения не входит в компетенции технической поддержки, или существует влияние доработки на другие компоненты, что нарушает общий порядок работы Системы - Согласование Присваивается при необходимости согласования направления обращения (заявки) ответственным сотрудником Заказчика на 3-й уровень Анализ Присваивается при проведении анализа на предмет возможности внесения изменений, связанных с развитием/улучшением/оптимизацией Системы и выводом новой функциональности и оценке ресурсоемкости Тестирование Присваивается Исполнителем при завершении разработки и проведенном предварительном тестировании для последующего осуществления приемочного тестирования Специалистом 2-го уровня Релиз Присваивается ответственным сотрудником Заказчика при принятии решения о возможности вывода доработки в продуктивную среду Утверждение заказчиком Присваивается при согласовании группой профильных специалистов на 2-м уровне поддержки с пользователем технического задания для внесения изменений, связанных с развитием/улучшением/оптимизацией Системы и выводом новой функциональности Доработка Присваивается в случае несогласования Заказчиком работ, проведенных Исполнителем в рамках контрактных обязательств, по внесению изменений, связанных с развитием/улучшением/оптимизацией Системы и выводом новой функциональности в штатном режиме, и необходимости последующего направления Исполнителю для ее доработки Отложен Присваивается в случае невозможности выполнения запроса, изложенного в обращении (заявке), в связи с необходимостью запроса дополнительной информации у третьих сторон - 3.4 Порядок регистрации и сопровождения Заявок Порядок регистрации и сопровождения обращений (заявок) в рамках оказываемых услуг по технической поддержке Системы зависит от типа обращения (заявки): 1. Услуга по решению инцидентов, связанных с работой ППО – тип обращения (заявки) «Инцидент». 2. Услуга по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности – тип обращения (заявки) «Инцидент». 3. Услуга информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы – тип обращения (заявки) «Запрос на обслуживание» (в том числе, консультационный запрос). 4. Услуга адаптационного, конфигурационного и коррекционного сопровождения Системы (в рамках действующих программных модулей и функциональностей) – тип обращения (заявки) «Запрос на изменение». В случае недоступности СРО взаимодействие и информирование Исполнителем о ходе оказания услуги по обращению (заявке), изменению статусов обращений (заявок) осуществляется по согласованию с Заказчиком в соответствии с матрицей взаимодействия, представленной в Приложении 1 к настоящему Регламенту. - 3.4.1 Инцидент На рисунке 2 представлена функциональная схема регистрации и сопровождения обращений (заявок) типа «Инцидент». Рисунок 2 - Функциональная схема регистрации и сопровождения обращений (заявок) типа «Инцидент» 3.4.2 Запрос на обслуживание На рисунке 3 представлена функциональная схема регистрации и сопровождения обращения (заявки) типа «ЗНО». Рисунок 3 - Функциональная схема регистрации и сопровождения обращения (заявки) типа «ЗНО» 3.4.3 Запрос на изменение На рисунке 4 представлена функциональная схема регистрации и сопровождения обращений (заявок) типа «ЗНИ». Рисунок 4 - Функциональная схема регистрации и сопровождения обращений (заявок) типа «ЗНИ» - 3.5 Порядок классификации и приоритизации обращений (заявок) Классификация является начальной стадией процесса оказания технической поддержки, необходимой для идентификации обращения (заявки) и определения соответствующих действий для его обработки. Для проведения первичной классификации необходимо получить от пользователя и зафиксировать в описании обращения (заявки) подробные сведения о сути запроса, в том числе, для Инцидентов зафиксировать сценарий воспроизведения обнаруженной ошибки. Для проведения вторичной классификации необходимо провести анализ и диагностику для определения корневой причины и затронутой Инцидентом функциональной области (инфраструктура, сеть, ППО). В процессе классификации осуществляется первичная диагностика и оценка проблемы, описанной пользователем Системы в обращении (заявке), в части функционирования и/или удобства использования Системы. Корректная классификация позволяет увеличить скорость обработки обращения (заявки) и решения описанной в обращении (заявке) проблемы при минимальном привлечении ресурсов, в частности, за счет использования известных решений для типовых обращений (заявок), которые должны описываться в БЗ СРО. Классификация позволяет произвести первоначальное назначение обращения (заявки) на ответственного сотрудника и выставить приоритет с учетом приоритизации. Приоритизация применяется для определения критичности описанной в обращении (заявке) проблемы для функционирования ППО Системы. Приоритет рассмотрения обращения (заявки) определяется в процессе ее классификации на основании ряда параметров, вводимых при заполнении обращения (заявки). Приоритизация используется для того, чтобы при одновременном наличии нескольких обращений (заявок) в первую очередь рассматривалась обращения (заявки) с наивысшим приоритетом и не позднее установленных для данного приоритета сроков - Термины и сокращения В настоящем регламенте используются следующие термины и сокращения на русском и английском языках: Термины/сокращения Полное наименование/описание БЗ (База знаний) База данных Системы регистрации обращений (заявок), созданная для сбора, хранения и поиска способов решения известных проблем в рамках Системы Жизненный цикл обращения (заявки) Совокупность статусов, по которым проходит обращение (заявка), и правила перехода обращения (заявки) из одного статуса в другой Заказчик ФГБУ «СИЦ Минтранса России» – Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» ЗНИ Запрос на изменение – тип заявки, предполагающий внесение изменений в прикладное программное обеспечение Системы ЗНО Запрос на обслуживание – тип заявки, предполагающий работы по предоставлению консультации, предоставление доступа к Системе или стандартизированные типовые изменения конфигураций Системы Инцидент Тип заявки, классифицируемый как нештатное событие в работе компонентов функциональных задач Системы, которое привело или может привести к нарушению или снижению качества функционирования Системы ИС Информационная система Исполнитель Организация, которая определяется по результатам конкурсных процедур Классификация Анализ и заполнение классификационных полей справочными значениями, определяющими последовательность действий и этапов жизненного цикла заявки, а также порядок рассмотрения заявок Консультация Разъяснения по алгоритму работы, требуемых настроек прикладного программного обеспечения и технологии обработки данных при работе с Системой, предоставление информации Маршрутизация Определение процесса движения обращения (заявки) в Системе управления заявками между уровнями технической поддержки и организационными структурами на уровнях поддержки путем назначения обращения (заявки) в соответствии с его классификацией и выставленным приоритетом - Обращение (заявка) Устное или письменное обращение пользователя АСУ ТК с вопросом, касающимся работоспособности АСУ ТК, по одному из определённых каналов связи: электронная почта, Система регистрации обращений (заявок) Пользователь Инициатор обращения (заявки) или пользователь Системы ППО Прикладное программное обеспечение Предмет обращения Справочник, классифицирующий типовые запросы в Системе регистрации обращений (заявок), характерные для Системы, выбранное значение определяет маршрутизацию обращения (заявки) (группу ответственных сотрудников) Приоритизация Значение, определяющее время, очередность решения обращений (заявок), ресурсы, привлекаемые для решения обращений (заявок), . Приоритет устанавливается в соответствии с масштабом выявленной проблемы, которая привела или может привести к нарушению или снижению качества функционирования Системы Релиз Выпуск версии прикладного программного обеспечения Системы, от разработки до тестирования и планового обновления Системы на продуктивной среде для установки изменений, связанных с развитием/улучшением/оптимизацией Системы Система, АСУ ТК, Информационно-аналитическая система регулирования на транспорте Информационно-аналитическая система, предназначенная для автоматизации и информационно-аналитического обеспечения процессов управления развитием транспортного комплекса Российской Федерации, обеспечения публичности деятельности органов государственного управления транспортным комплексом, а также обеспечения процессов оказания государственных услуг в электронном виде в сфере транспорта СМЭВ Система межведомственного электронного взаимодействия СПО Системное программное обеспечение СРО Система регистрации обращений (заявок) Статус обращения (заявки) Текущее состояние обращения (заявки) в жизненном цикле процесса оказания технической поддержки Системы СУБД Система управления базами данных - Уровень технической поддержки Организационно-структурная часть технической поддержки, имеющая определённые организационно-нормативными документами зоны ответственности, обязанности, а также временные нормативы, в течение которых эти обязательства должны выполняться либо эскалироваться на следующий уровень технической поддержки Услуги Услуги по технической поддержке Информационно-аналитической системы регулирования на транспорте АСУ ТК ФИО Фамилия, имя, отчество Эскалация Процедура повышения внимания к обращению (заявке) путем повышения его приоритета и/или передачи на следующий уровень технической поддержки, а также привлечение ролей, которые могут принимать решения без передачи на следующий уровень технической поддержки API Англ. Application Programming Interface — программный интерфейс приложения, интерфейс прикладного программирования — описание способов (набор классов, процедур, функций, структур или констант), которыми одна компьютерная программа может взаимодействовать с другой программой - CVSS Англ. Common Vulnerability Scoring System - открытый стандарт, используемый для расчета количественных оценок уязвимости в безопасности компьютерной системы, обычно с целью понять приоритет ее исправления. В современном инструментарии информационной безопасности используется версия 3.0 и выше с дополнительными метриками к базовым оценкам ID Англ. Identifier – идентификатор, уникальный признак объекта, позволяющий отличать его от других объектов, то есть, идентифицировать SLA Англ. Service Level Agreement - утвержденные условия по обработке обращения (заявки) с установленными метриками времени, которые определяют пороговые значения для эскалации в зависимости от статуса обращения (заявки) (например, время реакции – время от регистрации до осуществления первичной обработки, время решения – время от регистрации обращения (заявки) до его решения и т.д.) SQL Англ. Structured Query Language — «язык структурированных запросов», — декларативный язык программирования, применяемый для создания, модификации и управления данными в реляционной базе данных, управляемой соответствующей СУБД - 1 Общие сведения 1.1 Полное наименование Услуг Оказание услуг по технической поддержке Модуля СЦ АСУ ТК в 2026 году. 1.2 Предмет Регламента оказания услуг Требования Технического задания - 2 Общие положения 2.1 Цель и задачи оказания услуг Целью технической поддержки Системы является обеспечение ее стабильного и безопасного функционирования и эксплуатации, предупреждение, выявление и устранение сбоев в работе Системы и минимизация их неблагоприятного влияния. Для достижения поставленной цели требуется решение следующих задач: 1. Обеспечение информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы. 2. Поддержание параметров функционирования ППО Системы, удовлетворяющих требованиям производственных процессов, включая их непрерывность. 3. Обеспечение бесперебойного функционирования ППО и своевременное устранение сбоев и аварийных ситуаций в Системе. 4. Своевременное устранение уязвимостей при выявлении таковых, в соответствии с требованиями к обеспечению информационной безопасности. 5. Адаптация, конфигурирование, коррекция программного обеспечения в соответствии с изменениями нормативно-правовой базы и запросами уполномоченных сотрудников органов государственной власти, включая выполнение процедур тестирования и участие в обновлениях ППО на стендах Заказчика. 6. Обеспечение сохранения работоспособности ППО в изменяемой среде эксплуатации. 7. Ведение документации по настоящему контракту и инициирование актуализации документации на Систему по результатам обработки запросов Заказчика и внесения соответствующих изменений в ППО - 2.2 Общее описание процесса оказания сопровождения (технической поддержки) Системы Процесс оказания технической поддержки Системы включает: 1. Поступление обращений (заявок) от пользователей и их регистрацию. 2. Сопровождение обращений (заявок) в соответствии с их классификацией и приоритизацией, в том числе, с их последующей эскалацией. 3. Определение ролей и регламент их взаимодействия при осуществлении деятельности по процессу. 4. Решение обращений (заявок) в установленные настоящим Регламентом сроки. 5. Взаимодействие между 1-м, 2-м и 3-м уровнями технической поддержки, в том числе, с формированием заданий для сопровождения Системы. 6. Контроль качества выполняемых Исполнителем работ, состоящий из проверки сценария, приводящего к ошибке, зафиксированной в Инциденте, и/или к ошибке воспроизведения, а также тестирование внесенных изменений в рамках ЗНИ. 7. Обеспечение мониторинга и проведение анализа процесса обработки поступающих в техническую поддержку обращений (заявок). Техническая поддержка реализуется путем проведения ответственными сотрудниками соответствующей информационно-консультационной деятельности в соответствии с определенными ролями, а также выполнения Исполнителем конкретных действий по своевременному выявлению причин сбоев и аварийных ситуаций и их устранению, а также по адаптации, конфигурированию, корректировке Системы, включая выполнение процедур тестирования и участия в обновлениях Системы. Все роли подразделяются на уровни поддержки, взаимодействующие между собой в соответствии с блок-схемой процесса технической поддержки. Общая схема процесса рассмотрения обращений (заявок) в соответствии с видами технической поддержки представлена на рисунке 1. . Рисунок 1 - Общая схема процесса рассмотрения обращений (заявок) в соответствии с видами технической поддержки - 2.3 Каналы связи Должна быть предусмотрена омниканальность в части приема обращений (заявок). Получение обращений (заявок) технической поддержкой происходит по следующим каналам связи: – СРО; – электронная почта; – телефонная линия. Исполнитель обеспечивает прием обращений (заявок) от Заказчика и предоставляет информацию в рамках оказания услуг по техническому сопровождению Системы, руководствуясь матрицей взаимодействия, приведенной в Приложении 1 к настоящему Регламенту - 3 Порядок оказания Услуг 3.1 Типы обращений (заявок) Обращения и заявки Заказчика классифицируются в соответствии с приоритетами и регламентными сроками, указанными в Приложении 2 к настоящему Регламенту. Регистрация обращений и заявок предусматривает создание новой записи в СРО с присвоением поступившему обращению или заявке (новой записи) уникального идентификатора. Запись в СРО должна содержать вопрос или проблему, которую требуется решить или оказать консультацию. Если обращение или заявка автоматически зарегистрированы в СРО при отправке представителем Заказчика, Исполнитель проверяет корректность указанного типа обращения (заявки) и может обратиться к Заказчику с просьбой корректировки, предоставив обоснования в соответствии с настоящей классификацией (Таблица 1) - Таблица 1 - Типы обращений (заявок) Тип обращения (заявки) Описание Запрос на обслуживание Подготовка SQL запроса к СУБД для решения прикладной задачи и д р. – запрос на любое действие, не являющееся запросом информации и несовершенный на основе происшествия, прямо или косвенно влияющего на работу Системы Консультация (входит в тип обращения (заявки) «Запрос на обслуживание») «Где взять / куда обратиться...?», «Как сделать / выполнить…», «Как это работает…?» - запрос, имеющий своей целью получение информационной поддержки Инцидент Разбор ошибок/сбоев и подготовка материалов (корректировочных релизов, инструкций) для Заказчика для устранения ошибок/сбоев, которые приводят к частичному и полному нарушению работоспособности всех или отдельных функций ППО. Подготовка изменения и материалов, необходимых для проведения аварийно-восстановительных работ для возобновления работоспособности Системы. ЗНИ Подготовка изменений, связанных с изменением, улучшением/оптимизацией Системы и выводом новой модифицированной функциональности в штатном режиме. Подготовка изменений, связанных с модификацией существующих и/или реализация новых интеграционных механизмов для получения/обработки данных внешних систем. Подготовка изменений графического интерфейса по требованиям Заказчика - 3.2 Участники технической поддержки, осуществляющие сопровождение обращений (заявок) Техническая поддержка Системы должна быть организована на трех уровнях: 1. Первый и второй уровни технической поддержки организуется Заказчиком. 2. Третий уровень технической поддержки организуется Исполнителем. Зона ответственности каждого уровня технической поддержки указана в Таблице 2. Таблица 2 - Зона ответственности каждого уровня технической поддержки Участники технической поддержки Описание - Первый уровень технической поддержки (далее – 1-й уровень) Группа ответственных сотрудников 1-го уровня Заказчика, осуществляющая прием и первичную обработку обращений (заявок) (описание предмета обращения, первичная классификация и приоритизация, определение назначения, маршрутизация обращений (заявок) по назначению), руководствуется в своей работе настоящим Регламентом и БЗ, наполняемой 2-м уровнем поддержки, самостоятельно решает часть обращений (заявок), связанных с недостаточной квалификацией пользователей или настройками в рамках своей компетенции. В случае невозможности решения обращений (заявок) на 1-ом уровне ответственный сотрудник передает ее на 2-й уровень - Второй уровень технической поддержки (далее – 2-й уровень) Группа ответственных сотрудников 2-го уровня Заказчика по установленным компетенциям (информационная безопасность, сопровождение и эксплуатация информационно-аналитических систем, развитие информационно-аналитических систем, техническая поддержка информационно-аналитических систем) отвечает за поддержание работоспособности Системы, обработку обращений (заявок) и их решение в регламентные сроки в соответствии с установленными приоритетами. Осуществляет информационно-консультационную поддержку пользователей Системы в рамках своей компетенции. Оказывает экспертную помощь ответственным сотрудникам 1-го уровня в части формирования БЗ, содержащей ответы на часто задаваемые вопросы пользователей, с целью передачи знаний, навыков и инструментария на 1-й уровень для ускорения решения обращений (заявок). В случае невозможности решения обращения (заявки) на 2-ом уровне ответственный сотрудник передает его на 3-й уровень. При выявлении необходимости изменений в ППО Системы инициирует формирование обращения (заявки) и направляет его на группу ответственных сотрудников 3-го уровня по соответствующему классификатору (ЗНО, ЗНИ, и т.д.)

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

ОПРЕДЕЛЕНИЯ, ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ - Автоматизированная система (АС) Система, состоящая из комплекса средств автоматизации, реализующего информационную технологию выполнения установленных функций, и персонала, обеспечивающего его функционирование (ГОСТ Р 59853-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения») АРМ Автоматизированное рабочее место АСУ ТК, Система Информационно-аналитическая система регулирования на транспорте АТС Автоматическая телефонная станция БД База данных ГИС Государственная информационная система ГОСТ Государственный стандарт ГЦОД СИЦ Минтранса России, ГЦОД Головной центр обработки данных ФГБУ «СИЦ Минтранса России» Дашборд Интерактивная аналитическая панель, графический интерфейс. ЕИС Единая информационная система в сфере закупок ЕСИА Единая система идентификации и аутентификации Заказчик Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» КИИ Критическая информационная инфраструктура Кластер Кла?стер (англ. cluster) – объединение нескольких однородных элементов, которое может рассматриваться как самостоятельная единица, обладающая определёнными свойствами Компонент Часть АС, выделенная по определенному признаку или совокупности признаков и рассматриваемая как единое целое (ГОСТ Р 59853-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения») Контракт Контракт на выполнение работ по развитию и оказанию услуг по технической поддержке Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК в 2026 году, заключаемый по результатам проведения конкурентной процедуры закупки в соответствии с требованиями Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» - - Значение характеристики не может изменяться участником закупки

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

ФГБУ «СИЦ Минтранса России» Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации», Заказчик Федеральный закон № 44-ФЗ Федеральный закон от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» ФЗ Функциональная задача ФЗ «Реестр объектов» Функциональная задача «Формирование и ведение единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации» ФСБ России Федеральная служба безопасности Российской Федерации ФСТЭК России Федеральная служба по техническому и экспортному контролю ЧС Чрезвычайная ситуация ЭВМ Электронно-вычислительная машина API От англ. Application Programming Interface – интерфейс прикладного программирования – совокупность инструментов и функций в виде интерфейса для взаимодействия с программой CSS От англ. Cascading Style Sheets — каскадные таблицы стилей FPS От англ. frame per second - количество кадров в секунду HTML От англ. HyperText Markup Language - стандартный язык разметки документов, создающий основу и структуру всех веб-страниц JSON От англ. JavaScript Object Notation – текстовый формат обмена данными, основанный на JavaScript WebAssembly (Wasm) Открытый стандарт, представляющий собой низкоуровневый бинарный формат инструкций, который позволяет выполнять код, написанный на языках C++, Rust или Go, в браузерах с производительностью, близкой к нативной

1. ОБЩИЕ СВЕДЕНИЯ - – Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 19.02.2026 №ЕФ-1; – План мероприятий по профилактике случаев непроизводственного травматизма граждан на железнодорожном транспорте, являющийся приложением к постановлению коллегии Министерства транспорта Российской Федерации от 11.03.2026 № 2 - - Значение характеристики не может изменяться участником закупки

1.6. Перечень документов, требования которых должны быть учтены при выполнении работ – Федеральный закон Российской Федерации от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации»; – Федеральный закон Российской Федерации от 27.07.2006 № 152-ФЗ «О персональных данных»; – Федеральный закон Российской Федерации от 06.04.2011 № 63-ФЗ «Об электронной подписи»; – Федеральный закон Российской Федерации от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации»; – Указ Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации»; – Указ Президента Российской Федерации от 01.05.2022 № 250 «О дополнительных мерах по обеспечению информационной безопасности Российской Федерации»; – Указ Президента Российской Федерации от 31.03.2010 № 403 «О создании комплексной системы обеспечения безопасности населения на транспорте»; – постановление Правительства Российской Федерации от 30.07.2004 № 395 «Об утверждении Положения о Министерстве транспорта Российской Федерации»; – постановление Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации»; – постановление Правительства Российской Федерации от 16.11.2015 № 1236 «Об установлении запрета на допуск программного обеспечения, происходящего из иностранных государств, для целей осуществления закупок для обеспечения государственных и муниципальных нужд»; – постановление Правительства Российской Федерации от 23.12.2024 № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц»;

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

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

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

1.1. Наименование Системы Полное наименование системы: Информационно-аналитическая система регулирования на транспорте. Условное обозначение системы: АСУ ТК. Полное наименование модуля: Модуль сбора, ведения и анализа информации о нештатных ситуациях на транспорте. Условное обозначение модуля: Модуль СЦ. Модуль СЦ создан в рамках контракта от 05.08.2024 № ОК/24_04 на выполнение работ по развитию АСУ ТК в части создания модуля «Сбора, ведения и анализа информации о нештатных ситуациях на транспорте». Развитие Модуля СЦ осуществлено в рамках контракта от 19.05.2025 № ОК/25_09 на выполнение работ по развитию Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК

– постановление Правительства Российской Федерации от 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 Федерального закона «Об электронной подписи»;

– постановление Правительства Российской Федерации от 08.06.2011 № 451 «Об инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг и исполнения государственных и муниципальных функций в электронной форме»; – постановление Правительства Российской Федерации от 30.01.2013 № 62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин»; – приказ ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации»; – приказ ФСТЭК России от 11.04.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений»; – приказ ФСБ России от 18.03.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений, с использованием шифровальных (криптографических) средств»; – приказ ФСБ России от 10.07.2014 № 378 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных с использованием средств криптографической защиты информации, необходимых для выполнения установленных Правительством Российской Федерации требований к защите персональных данных»;

1.2. Шифр темы или номер контракта Присваивается Заказчиком по результатам организации закупочных процедур. 1.2.1. Предмет контракта Выполнение работ по развитию Модуля СЦ. Код по ОКПД2: 62.01.11.000 – услуги по проектированию и разработке информационных технологий для прикладных задач и тестированию программного обеспечения. Оказание услуг по технической поддержке Модуля СЦ. Код по ОКПД2: 62.02.30.000 – услуги по технической поддержке информационных технологий. Выполнение работ по развитию Модуля СЦ предусмотрено с учетом ключевых результатов (ОКР) Ведомственной программы цифровой трансформации Минтранса России на 2026-2028 (далее - ВПЦТ Минтранса России) в составе мероприятия № 103.002 «АСУ ТК» ИТ расхода 103.26.000005 «Развитие Информационно-аналитической системы регулирования на транспорте (АСУ ТК)»: · «Обеспечено информационное взаимодействие с Минобороны о происшествиях на транспортных объектах»; · «Обеспечена автоматизация формирования отчетов о нештатных ситуациях на транспорте, в том числе по данным внешних систем». Выполнение работ по технической поддержке АСУ ТК предусмотрено ВПЦТ Минтранса России в составе мероприятия № 103.002 «АСУ ТК» ИТ расхода 103.26.000021 «Эксплуатация Информационно-аналитической системы регулирования на транспорте (АСУ ТК)»

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

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

1.5. Основания для выполнения работ Работы осуществляются на основании следующих документов: – постановление Правительства Российской Федерации от 30.12.2003 № 794 «О единой государственной системе предупреждения и ликвидации чрезвычайных ситуаций»; – постановление Правительства Российской Федерации от 08.11.2013 № 1007 «О силах и средствах единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций»; – распоряжение Правительства Российской Федерации от 27.11.2021 № 3363-р «О Транспортной стратегии Российской Федерации до 2030 года с прогнозом на период до 2035 года»; – Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 26.08.2025 №ЕФ-3; – Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 27.11.2025 №ЕФ-23;

– приказ Минкомсвязи России от 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.7. Сроки начала и окончания работ Начало работ: с даты заключения Контракта. Окончание работ: не позднее 15.12.2026. Работы выполняются в соответствии с этапами. Сроки выполнения этапов работ по развитию и технической поддержке Модуля СЦ определяются Календарным планом. Календарный план, приведен в разделе 5 настоящего ТЗ

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

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

2.1. Назначение АСУ ТК АСУ ТК предназначена для автоматизации и информационно-аналитического обеспечения процессов управления развитием транспортного комплекса Российской Федерации, обеспечения публичности деятельности органов государственного управления транспортным комплексом. Основными целями АСУ ТК являются: – повышение эффективности процессов управления функционированием и развитием транспортного комплекса на основе создания единой информационной среды и комплекса информационно-аналитических услуг на уровне органов государственного управления ТК; – повышение уровня безопасности ТК на базе получения полной, достоверной и оперативной информации о происходящих изменениях, своевременного выявления негативных тенденций и для принятия соответствующих мер по их устранению и ликвидации последствий

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

3. ХАРАКТЕРИСТИКА ОБЪЕКТА АВТОМАТИЗАЦИИ - АСУ ТК осуществляет идентификацию и авторизацию посредством Единой системы идентификации и аутентификации (ЕСИА). Информационный обмен с внешними информационными системами осуществляется посредством СМЭВ 3 и СМЭВ 4. АСУ ТК развернута на вычислительных мощностях ГЦОД СИЦ Минтранса России - - Значение характеристики не может изменяться участником закупки

3.2. Описание и текущее состояние объекта автоматизации Модуля СЦ Объектом автоматизации является процесс организации мониторинга информации о НС и ЧС на транспорте. Предметом деятельности Учреждения являются следующие функции: – информационное обеспечение в области транспортной безопасности, защиты населения и территорий от чрезвычайных ситуаций природного и техногенного характера в транспортном комплексе; – подготовка справочных материалов при угрозе возникновения и возникновении чрезвычайных ситуаций и иных происшествий в транспортном комплексе; – взаимодействие и обмен оперативной информацией с органами управления Единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций; – организация оперативного мониторинга обстановки на объектах транспорта при угрозе и возникновении чрезвычайных ситуаций и иных происшествий. Перечень компонентов Модуля СЦ и выполняемые ими функции представлены в Таблице 2

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

3.1. Описание объекта автоматизации АСУ ТК Объектом автоматизации являются процессы основной и обеспечивающей деятельности, направленные на управление транспортным комплексом, в том числе, процессы информационного взаимодействия с другими организациями и субъектами транспортного комплекса. АСУ ТК относится к государственным информационным системам, а также к информационным системам персональных данных и значимым объектам критической информационной инфраструктуры Российской Федерации. АСУ ТК соответствует требованиям, предъявляемым к: – ГИС второго класса защищенности в соответствии с приказом ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах»; – ИС персональных данных при обеспечении третьего уровня защищенности персональных данных в соответствии с требованиями постановления Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»; – значимым объектам КИИ Российской Федерации второй категории значимости с постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении Правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений». Модуль СЦ является подсистемой АСУ ТК. Перечень платформенных решений и функциональных задач АСУ ТК представлен в Таблице 1

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

3 Информирование – ведение справочника способов оповещения (веб-интерфейс, мессенджер); – формирование сценария выполнения оповещения (настройка условий, способа, параметров оповещения); – выполнение оповещений пользователей 4 Отчетность – формирование отчета и справки о событиях; – фильтрация событий для выгрузки в справку о событиях или в отчет о событиях 5 Администрирование – ведение ролей пользователей; – ведение учетных данных пользователей; – ведение справочника организаций; – ведение справочника групп системы мгновенного обмена сообщениями; – выполнение исходящего звонка на контактный телефонный номер организации; – формирование матрицы эскалации событий Архитектура Модуля СЦ представлена на рисунке 1. Рисунок 1. Архитектура Модуля СЦ

3.3. Состав используемого ПО Модуля СЦ Программная архитектура Модуля СЦ разработана как трехуровневая клиент-серверная архитектура. Архитектура включает в себя следующие уровни: • уровень представления – презентационный уровень, обеспечивающий взаимодействие с пользователя с клиентскими приложениями с использованием веб-браузера («тонкий» клиент); • уровень приложений – реализован в виде сервисов, обеспечивает обработку запросов, поступающих от клиентских приложений, формирование ответов на запрос в доступном пользователю виде (формирование пользовательских интерфейсов); • уровень хранения данных – реализуется как сервер БД и обеспечивает хранение и целостность хранимых данных, создание резервных копий, ведение журнала транзакций, восстановление данных после сбоев. Программная архитектура Модуля СЦ включает в себя сервисы и интерфейсы, указанные в Таблице 3. Таблица 3. Программная архитектура Модуля СЦ Программный сервис/интерфейс Технологии реализации Уровень представления Интерфейс пользователя и администратора (front-end) Javascript Уровень приложений Сервис (GateWay) Kotlin Сервис геокодирования (geocoding-service) Kotlin Сервис уведомлений (notifiсation-service) Kotlin Сервис работы с файлами (file-service) Kotlin Сервис отчетности (report-service) Kotlin Сервис управления событиями (event-service) Kotlin Сервис информирования через мессенджер (messenger-notifier) Python Сервис внешних интеграций (integration-service) Сбор информации из внешних систем и сервисов Брокер сообщений Kafka Уровень хранения данных Файловое хранилище MinIO S3 СУБД Postgres Pro Enterprise

3.4. Информационное взаимодействие программных сервисов и интерфейсов Модуля СЦ Объект автоматизации функционирует в распределенной информационной среде. Обмен данными осуществляется по защищенным каналам связи (в том числе ведомственным сетям передачи данных). Источники информации включают: · внешние автоматизированные системы (органов государственной власти); · внутренние базы данных (реестры объектов транспортной инфраструктуры, паспорта регионов и пр.); · оперативная информация от персонала, поступающая через автоматизированные рабочие места (АРМ) и мобильные устройства. 3.4.1. Взаимодействие Модуля СЦ со смежными подсистемами АСУ ТК Модуль СЦ входит в состав АСУ ТК и взаимодействует со следующими ее функциональными задачами и подсистемами: · Функциональной задачей «Формирование и ведение единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации» (ФЗ «Реестр объектов»); · Геоинформационной подсистемой АСУ ТК (П-ГИС); · Подсистемой ведения нормативно-справочной информации и метаданных (П-НСИ); · Подсистемой сбора данных и централизованное хранилище данных (П-СД); · Подсистемой информационного взаимодействия (П-ИВ). 3.4.2. Взаимодействие с внешними информационными системами Список внешних информационных систем, с которыми осуществляется взаимодействие Модуля СЦ: · ЕСИА; · мессенджер; · Яндекс Геокодер; · Информационная система «Централизованная система сбора информации систем-112»; · ПВК «Поиск-Море», АИС РПТ; · облачная АТС

8 Подсистема проектного архива АСУ ТК Подсистема проектного архива АСУ ТК предназначена для автоматизации деловых процессов должностных лиц Министерства транспорта Российской Федерации, подведомственных агентств и службы, в том числе, и процессов информационного взаимодействия внутреннего и внешнего характера 9 ФЗ «Реестр объектов» Функциональная задача предназначена для формирования и ведения единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации 10 ФЗ «СТП» Функциональная задача предназначена для организации информационно-аналитической поддержки процессов территориального планирования Российской Федерации в области федерального транспорта 11 ФЗ «МРТБ ПП» Функциональная задача предназначена для формирования и ведения межрегионального транспортного баланса пассажирских перевозок в дальнем (межрегиональном) сообщении 12 ФЗ «МДД» Функциональная задача предназначена для осуществления мониторинга дорожного движения 13 ФЗ «ТПР» Функциональная задача предназначена для формирования и ведения транспортного паспорта региона 14 ФЗ «Данные по грузообороту» Функциональная задача предназначена для обеспечения подсистем и пользователей АСУ ТК данными по грузообороту между Российской Федерацией и зарубежными странами 15 ФЗ «МЖТ» Функциональная задача предназначена для осуществления мониторинга железнодорожного транспорта 16 ФЗ «МГМП» Функциональная задача предназначена для осуществления мониторинга грузопотоков в морских портах с целью формирования единой цифровой среды мониторинга и планирования перевозок в/из портов Дальнего Востока

17 Модуль ГЭТ Модуль предназначен для получения, хранения данных инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по отдельно взятому предприятию-перевозчику. Формирования отчетов об инвентаризации с детальными данными по каждому разделу инвентаризации с маршрутизацией в муниципалитет / регион / Минтранс. Содержит агрегированные данные инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по всем перевозчикам, относящихся к данному муниципалитету. Формирует сводный отчет по муниципалитету по каждому разделу инвентаризации с маршрутизацией в регион / Минтранс. Формирует агрегированные данные инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по всем перевозчикам, относящиеся к данному региону и по всем муниципалитетам, относящимся к данному региону. Аналитические и статистические данные о состоянии ГЭТ региона. Содержит данные о видах транспорта, цифровых транспортных сервисах и платежных инструментах Региона. Формирует сводный отчет по каждому разделу инвентаризации с маршрутизацией в Минтранс. Формирует агрегированную статистику и аналитику по всем регионам страны в разрезе транспортных средств, маршрутов, пассажиропотоков, инфраструктуры ГЭТ. Данные о рейтинге регионов и перевозчиков на основании выбранных параметров, документооборот с участниками Системы: получение подписанных печатных форм, их утверждение, возврат на доработку. 18 Модуль iМинтранс Модуль создан для отчета по ключевым показателям транспортного комплекса России (Отраслевые и статистические показатели, исполнение бюджета, исполнение поручений, аналитика СМИ, происшествия по видам транспорта). 19 Модуль СЦ Модуль СЦ предназначен для оперативного мониторинга нештатных ситуаций транспортной отрасли, оповещения заинтересованных лиц и структур и предоставления данных о нештатных ситуациях

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

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

Лицензионное (сублицензионное) соглашение (договор) не может возлагать на Заказчика какие-либо обязанности (в т.ч. в части конфиденциальности, предоставления отчетности), не предусмотренные Контрактом. 4.5.9.7. Передача Заказчику исключительных прав, или простых (неисключительных) прав не может повлечь увеличение стоимости Контракта и/или изменение иных существенных условий Контракта. 4.5.9.8. Функциональность Модуля СЦ передается в объеме и в сроки, установленные Техническим заданием. 4.5.9.9. Нарушение условий настоящего раздела Технического задания, в т.ч. отсутствие соответствующего лицензионного (сублицензионного) соглашения (или договора), либо предоставление лицензионного (сублицензионного) соглашения (или договора), не соответствующего требованиям действующего законодательства Российской Федерации или требованиям Контракта, является нарушением существенных условий Контракта. 4.5.9.10. В случае, если в соответствии с пунктом 4.5.9.6 Заказчику передается исключительное право, такая передача осуществляется в порядке, установленном Гражданским кодексом Российской Федерации. 4.5.9.11. В случае, если при выполнении Работ положения пунктов 4.5.9.5-4.5.9.6 не применялись, Подрядчик в составе отчетной документации предоставляет об этом декларацию в свободной форме. Декларация должна содержать сведения о полном соответствии результата Работ требованиям Контракта, а также о неприменении при выполнении работ готового программного обеспечения (платформ, подсистем, СУБД и т.д.), которое стало частью (компонентом) Системы

4.2.4.1. Требования к технической реализации компонента «Интерактивная карта» При реализации компонента «Интерактивная карта» должны учитываться требования, указанные ниже. 4.2.4.1.1. Требования к отображению элементов Повторяющихся элементы карты (ТС, ОТИ, события и пр.) должны отрисовываться с использованием аппаратного создания экземпляров объектов на пользовательском устройстве (WebGL/WebGPU)). Отрисовка каждого объекта отдельным запросом не допускается, должна обеспечиваться возможность одновременного отображения не менее 5 000 объектов без снижения производительности (30 кадров в секунду на тестовой конфигурации). 4.2.4.1.2. Уровни детализации объектов Для управления отображением сложных объектов должно быть создано не менее 3-х уровней детализации, отображаемых при изменении масштаба с возможностью автоматического переключения между уровнями. Все отображаемые объекты должны масштабироваться с учетом разрешения экрана пользователя с сохранением качества детализации. 4.2.4.1.3. Полигональная оптимизация и текстурирование При реализации компонента «Интерактивная карта» должна обеспечиваться технология рельефного тестурирования объектов. Не должны использоваться высокополигональные трехмерные модели. Все повторяющиеся элементы должны генерироваться единоразово и повторно использоваться при последующих отображениях. 4.2.4.1.4. Управление памятью Требуется реализовать потоковую загрузку на устройство пользователя элементов карты и текстур. Загрузка данных целиком при старте приложения не допускается. Необходимо реализовать механизм очистки памяти от элементов, которые находятся вне области видимости камеры в течение заданного времени. 4.2.4.1.5. Требования к взаимодействию пользователя с интерфейсом компонента «Интерактивная карта» Программная реализация механизмов управление камерой (масштабирование и навигация) должна быть выполнена с поддержкой технологии WebAssembly (WASM). Элементы управления должны являться неотъемлемой частью интерактивной карты.

4.2.5. Развитие компонента администрирования (3 очередь) Должна быть выполнена доработка ролевой модели. Ролевая модель должна обеспечивать управление доступом к отдельным объектам Модуля СЦ и их элементам (атрибутам) с разграничением по видам транспорта, регионам и пр., в частности: – определение набора конкретных действий, доступных пользователям (выполняемых над объектом доступа, например, удаление записи, редактирование записи, формирование отчета и др.); – реализация возможности объединения пользователей в группы; – определение прав доступа для групп пользователей; – реализация интерфейса визуальной настройки прав доступа пользователей к объектам Модуля СЦ

4.3.1.1. Требования к составу и содержанию услуг третьего уровня технической поддержки Оказание услуг по технической поддержке Системы осуществляется в рамках этапов в соответствии с календарным планом. Подрядчик в течение 5 рабочих дней с даты заключения Контракта должен предоставить со своей стороны, а Заказчик со своей стороны Матрицу ответственных за взаимодействия в соответствии с Приложением 1 к Регламенту оказания услуг по третьему уровню технической поддержки Модуля СЦ (далее – Регламент, Приложение В). Подрядчик в течение 10 рабочих дней с даты заключения Контракта должен провести мероприятия по организации третьего уровня технической поддержки в соответствии с Регламентом. Услуги по третьему уровню технической поддержки Модуля СЦ должны включать: – организацию Подрядчиком третьего уровня технической поддержки; – информационно-консультационную поддержку работников Заказчика; – решение инцидентов, связанных с работой ППО; – адаптационное, конфигурационное и коррекционное сопровождение Модуля СЦ (в рамках действующих программных модулей и функциональности); – устранение уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности

4.3.1.2. Требования к общему порядку оказания услуг Техническая поддержка Модуля СЦ должна быть организована на трех уровнях: – первый и второй уровни технической поддержки организуется Заказчиком; – третий уровень технической поддержки организуется Подрядчиком. Перечень действий на каждом уровне технической поддержки указан в Таблице 5: Таблица 5 – Перечень действий на каждом уровне технической поддержки Уровень технической поддержки Доступные действия Условия передачи задачи на следующий уровень Первый уровень технической поддержки (далее – 1-й уровень) – принимает обращения (заявки) пользователей Модуля СЦ и работников Заказчика; – регистрирует обращения в Модуле СЦ регистрации обращений; – присваивает уникальный идентификационный номер, классифицирует обращения; – самостоятельно решает обращения, которые связаны с недостаточной квалификацией пользователей или настройками в рамках своей компетенции; – взаимодействует с пользователями Модуля СЦ при решении проблемы Передает обращение на второй уровень поддержки в случае невозможности решения на своем уровне Второй уровень технической поддержки (далее – 2-й уровень) – принимает обращения от 1-го уровня; – уточняет классификацию обращения в результате дополнительного анализа; – самостоятельно решает обращения в рамках своей компетенции; – осуществляет техническую и консультационную поддержку Модуля СЦ; – взаимодействует с сотрудниками 1-го и 3-го уровня и пользователями Модуля СЦ; – формирует заявки для 3-го уровня и контролирует исполнение Передает обращение на третий уровень поддержки в случае невозможности решения на своем уровне Третий уровень технической поддержки (далее – 3-й уровень) – принимает обращения от 2-го уровня; – обеспечивает выполнение требований, предъявляемых Контрактом и настоящим Техническим заданием к Услугам, оказываемым Подрядчиком Все поступающие обращения должны быть исполнены Подрядчиком

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

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

4.3.6.4.1. Требования к проведению изменений Основанием для внесения изменений является запрос от Заказчика. Все активности по внесению изменений должны быть согласованы с Заказчиком, а действия Подрядчика при оказании данной услуги должны быть зафиксированы. В рамках данного Технического задания изменениями считаются локальные доработки функционала Модуля СЦ, которые не должны приводить к необходимости выполнения дополнительных аттестационных испытаний или переаттестации АСУ ТК в соответствии с п. 33 приказа от 29.04.2021 № 77 «Об утверждении Порядка организации и проведения работ по аттестации объектов информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну». При необходимости внесения изменений в Модуль СЦ, не связанных с критичным инцидентом, существенно нарушающим работоспособность Модуля СЦ, Заказчик направляет Подрядчику обращение (заявку), в котором излагает суть изменения, которое требуется внести в Модуль СЦ. Исполнитель, в течение 3 (трех) рабочих дней с момента поступления соответствующего обращения (заявки), оценивает техническую возможность реализации запрашиваемого изменения и варианты реализации. По итогу проведения оценки Подрядчик направляет Заказчику заключение о возможности реализации данного изменения с описанием возможных вариантов реализации и согласует с Заказчиком проведение данного изменения

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

4.1. Требования к структуре Модуля СЦ В процессе работ по развитию Системы должны сохраниться основные требования к построению архитектуры Системы в соответствии с принципами трехуровневой архитектуры: 1. уровень хранения данных или уровень базы данных (сервер СУБД); 2. уровень сервера приложений (сервер аналитической обработки); 3. презентационный уровень, обеспечивающий взаимодействие с клиентскими приложениями. В состав Системы должны входить следующие основные компоненты: 4. сервер баз данных; 5. сервер приложений; 6. веб-сервер. Сервер баз данных должен обеспечивать хранение и целостность хранимых данных, создание резервных копий, ведение журнала транзакций, восстановление данных после сбоев. Сервер приложений должен обеспечивать обработку запросов, поступающих от клиентских приложений (через веб-сервер), формирование ответов на запрос в доступном пользователю виде (формирование пользовательских интерфейсов). Веб-сервер должен обеспечивать взаимодействие с оператором и внешними системами по HTTP / HTTPS протоколу в режиме «запрос-ответ» (получения запросов от пользователя и передачи ответа в виде соответствующей информации, обработанной серверами приложений). Взаимодействие Системы с пользователем должно отвечать требованиям модели «тонкого клиента» (т.е. представлять на стороне клиента (пользователя) лишь графический пользовательский интерфейс). Все составляющие Системы должны использовать единую методологию и отвечать единым принципам взаимодействия, надежности и управления. Перечень компонентов Модуля СЦ представлен в Таблице 4. Таблица 4. Перечень компонентов Модуля СЦ, в отношении которых выполняются работы по развитию № п.п. Наименование компонента Модуля СЦ Раздел ТЗ 1 Компонент регистрации событий 4.2.1. 2 Компонент отчетности 4.2.2 3 Компонент визуализации 4.2.3 4 «Интерактивная карта» (компонент создается) 4.2.4 5 Компонент администрирования 4.2.5

4.2. Требования к дорабатываемым функциям модуля СЦ 4.2.1. Развитие компонента регистрации событий (1 очередь) Должны быть выполнены следующие доработки: – обеспечение логирования действий пользователя, связанных с карточкой события; – доработка объектной модели в части создания новых типов сущностей (карточек) с учетом реализуемых интеграций с информационными ресурсами (силы и средства предупреждения и ликвидации ЧС и нештатных ситуаций на транспорте, ТС, ограничения воздушного пространства, неблагоприятные и опасные природные явления); – реализация механизма установления связи между сущностями в Модуле СЦ автоматизированным и ручным способами (события, природные явления, силы и средства предупреждения и ликвидации ЧС и нештатных ситуаций на транспорте, ограничения воздушного пространства, ОТИ, ТС и др.); – отображение в карточке установленных связей между сущностями.

4.2.2. Развитие компонента отчетности (3 очередь) Должна быть обеспечена автоматизация процессов формирования отчетов о ЧС и нештатных ситуациях на транспорте, в т.ч. на основе данных из внешних систем. Включает следующие доработки: – разработка шаблонов отчетов в различных форматах (табличный, текстовый); – реализация выбора фотоматериалов для включения в справку; – форматирование содержимого справок с учетом правил русского языка в отношении окончаний слов (в зависимости от падежа, склонения, числа и рода); – автоматизированное формирование выводов к содержимому справки на основе настраиваемых критериев; – создание интерфейса выбора параметров (фильтрации) для формирования отчетов: o состав полей для включения в отчёт; o настройка диапазонов значений характеристик и дат; o порядок отображения полей; o настройка заголовка. – реализация способа подготовки отчётов в асинхронном режиме (очереди); – реализация интерфейса компонента формирования отчетности для отображения очереди формирования отчетов и статусов их подготовки; – экспорт отчётов в форматы xlsx, csv и справок в форматы pdf, docx. Необходимо разработать не менее 10 шаблонов отчетов и/или справок. Перечень, структура и содержание шаблонов должны быть согласованы с Заказчиком на этапе технического проектирования.

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

– отображение на карте связанных сущностей и ОТИ; – реализация функции выбора темного и светлого стилей отображения элементов интерфейса, карточек сущностей, картографической основы и объектов, отображаемых на карте; – реализация механизма для выбора картографической основы в одном из распространенных форматов WMTS, TMS, MVT и др. Должна быть предусмотрена возможность настройки перечня картографических основ и параметров доступа к ним; – настройка базового набора дашбордов, содержащих преднастроенные виджеты о количестве событий в разрезе видов транспорта с возможностью перехода к исходным данным (карточкам событий, ОТИ и т.д.), с фильтрацией по параметрам. Параметры фильтрации должны быть определены на этапе технического проектирования. Должно быть обеспечено автоматическое и принудительное обновление данных, отображаемых на дашбордах

4.2.4. Создание компонента «Интерактивная карта» (2 очередь) В составе создаваемого компонента должны отображаться данные, доступные в компоненте визуализации. Требования к интерфейсу интерактивной карты: – интерактивная карта должна быть представлена в виде объемной карты с учетом макетов, представленных в Приложении А к ТЗ; – интерфейс должен корректно отображаться на экранах мониторов (разрешение Full HD 1920?1080), телевизоров (разрешение 4К 3840?2160), жидкокристаллических панелей для видеостены, используемой Заказчиком, с параметрами каждой панели: диагональ 55 дюймов, разрешение 1920x1080; – интерфейс должен корректно отображаться на планшетных устройствах с диагональю экрана 10-12 дюймов, конкретные требования должны быть уточнены на этапе технического проектирования; – должна быть обеспечена кластеризация и генерализация отображения объектов на карте при изменении масштаба; – должно быть обеспечено отображение основных характеристик объектов при выборе их на карте; – должно быть обеспечено управление отображением слоев на карте; – должна быть обеспечена настройка цветовой индикации отображаемых объектов транспортной инфраструктуры; – должно быть обеспечено отображение легенды карты, содержащей отображаемые объекты на карте; – должна быть обеспечена возможность одновременного отображения не менее 5 000 ОТИ и ТС на карте.

На интерактивной карте должны быть отображены подвижные объекты совместно с объектами транспортной инфраструктуры (ОТИ), включая следующие возможности: § отображение местоположения транспортных средств (воздушный, водный и автомобильный транспорт) на карте в режиме реального времени (с заданным периодом обновления данных); § отображение маршрутов движения всех ТС за выбранный период времени, в том числе с использованием эффектов анимации; § отображение маршрутов движения ТС, связанных с карточкой события: ТС, являющихся участниками события, и ТС, находящиеся в заданном радиусе от события; § управление отображением сущностей и ОТИ на карте, включая настройку состава отображаемых объектов, поиск, фильтрацию, с использованием соответствующей панели управления и наглядным представлением результатов; § автоматическое изменение вида отображения объектов (цветовая индикация) по заданным условиям (например, при достижении критических значений параметров, характеризующих функционирование объекта); Должна обеспечиваться производительность обновления изображения на экране в 30 кадров в секунду на тестовой конфигурации пользовательского устройства (модель Бештау AIO2402/B560, входящая в Реестр российской промышленной продукции под номером 10394100 или аналог) при одновременном отображении не менее 5 000 объектов и 200 уникальных моделей объектов. Макеты интерфейсов Модуля СЦ должны быть предварительно согласованы с Заказчиком и разработаны с учетом требований ГОСТ Р ИСО 9241-161-2016 «Элементы графического пользовательского интерфейса»

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

4.5.3. Требования по диагностированию Модуля СЦ Диагностирование Модуля СЦ должно осуществляться путем анализа записей в системных журналах СУБД, операционных систем серверов, а также с помощью встроенных средств диагностирования общего программного обеспечения Модуля СЦ. Диагностированию подлежат: – сбои и нарушения функционирования технического обеспечения (серверов) Модуля СЦ; – сбои и нарушения функционирования системного программного обеспечения серверов, используемых для работы Модуля СЦ; – сбои и нарушения функционирования прикладного программного обеспечения серверов, используемых для работы Модуля СЦ; – случаи недоступности (отсутствия ответа) или некорректные ответы внешних систем; – сбои и нарушения функционирования СУБД; – сбои при выполнении регламентных операций резервного копирования. При возникновении аварийных ситуаций либо ошибок в программном обеспечении диагностические инструменты должны позволять сохранять набор информации, необходимой для идентификации и устранения проблемы. Модуль СЦ и ее компоненты должны обеспечивать возможность диагностики своей работоспособности с возможностью интеграции с модулем мониторинга АСУ ТК. Набор передаваемых журналов и метрик должен быть определен на этапе технического проектирования

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

4.2.6. Взаимосвязи с внешними автоматизированными системами (1 очередь) Способы взаимодействия с внешними информационными системами должны быть определены на этапе технического проектирования. Должны быть выполнены следующие доработки: – интеграции с информационными ресурсами в целях получения данных о движении подвижных ТС (воздушные суда, суда водного транспорта); – интеграция с информационным ресурсом в целях получения данных о событиях на железнодорожном транспорте. Реализация интеграций должна включать проектирование и реализацию интеграционных механизмов обмена данными с учетом доступных вариантов реализации, обеспечение защищенных способов взаимодействия, настройку отображения отдельных данных на карте (настройка слоев). Взаимодействия, имеющие каналы связи, выходящие за пределы контролируемой зоны взаимодействующих систем, считаются защищенными, если для их защиты используются программные и/или программно-аппаратные шифровальные (криптографические) средства, сертифицированные ФСБ России (далее – СКЗИ). Выбор СКЗИ, схемы подключения и требуемого класса криптостойкости должен производиться в соответствии с Техническими условиями на подключение к информационным ресурсам ФГБУ «СИЦ Минтранса России» и инструкциями по подключению пользователей к ресурсам инфраструктуры Головного центра обработки данных, утвержденных приказом директора ФБГУ «СИЦ Минтранса России» от 24.05.2024 № 21-ОД

4.3. Требования к оказанию услуг по технической поддержке Модуля СЦ 4.3.1. Общие требования к оказанию Услуг Техническая поддержка Модуля СЦ должна осуществляться с учетом требований постановления Правительства Российской Федерации от 06.07.2015 N 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации». Подрядчик обязан выполнять требования законодательства в сфере защиты информации, требования по защите информации, информационной безопасности, указанные в локальных нормативных актах ФГБУ «СИЦ Минтранса России», регламентирующих условия информационного взаимодействия, защиты информации и подключения к информационным ресурсам ФГБУ «СИЦ Минтранса России», участвующих в информационном взаимодействии в рамках оказания услуг по технической поддержке АСУ ТК в 2026 году

Для обеспечения взаимодействия с Заказчиком Подрядчик со своей стороны определяет ответственных лиц, уполномоченных в структуре Подрядчика за своевременное и качественное оказание Услуг в рамках настоящего ТЗ, а также контактную информацию ответственных лиц (телефон, электронную почту). Подрядчик должен предоставить Заказчику единый адрес электронной почты для приема обращений (заявок) в течение 3 (трех) рабочих дней после заключения Контракта. Указанный в настоящем пункте адрес электронной почты (способ направления обращений (заявок) применяется в случае сбоя в работе СРО Заказчика. Со своей стороны, Заказчик предоставляет Подрядчику перечень и контактную информацию (телефон, электронную почту) уполномоченных лиц для осуществления взаимодействия с указанием зон ответственности. О любых изменениях в контактной информации ответственных лиц Стороны должны уведомить друг друга в течение 1 (одного) рабочего дня с момента возникновения таких изменений посредством уведомления на электронную почту ответственных лиц и/или в письменной форме. В результате оказания услуг по настоящему ТЗ не должны быть изменены исходные коды, дистрибутивы и иные компоненты Модуля СЦ вне согласованных с Заказчиком изменений. Любые изменения исходных кодов, дистрибутивов и иных компонентов Модуля СЦ должны производиться только после согласования с Заказчиком уполномоченными лицами по электронной почте или иным заранее согласованным способом. Не должна быть ухудшена надежность и производительность Модуля СЦ. Оказание услуг по Контракту не должно нарушать требования к информационной безопасности, описанной в документации на Модуль СЦ

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

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

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

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

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

4.3.4. Требования к документированию результатов оказываемых услуг Для обеспечения контроля оказываемых услуг по поддержке Модуля СЦ со стороны Заказчика, по окончании каждого отчетного периода по контракту в соответствии с календарным планом, Подрядчик обязан предоставить Заказчику Отчет об оказанных услугах. Отчет должен содержать детальную информацию об оказанных услугах с указанием даты выполненных мероприятий и приложением обосновывающих документов (заявок, запросов, требований) или ссылкой на такие документы, если они содержатся в Модуле СЦ. Информация о выполненных мероприятиях по заявкам должна быть сформирована на основании соответствующих записей СРО по каждому этапу исполнения Контракта. В случае оказания услуги адаптационного, конфигурационного и коррекционного сопровождения Модуля СЦ, должны быть предоставлены документы, подтверждающие выполнение требований п. 29.3 приказа ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации». Фактическое время реагирования и время решения по всем обращениям, поступившим в СРО, формируется в СРО по итогам отчетного периода в разделе «Отчеты». Фактическое время реагирования и время решения по обращениям учитывает суммарное время, затраченное на реагирование и, соответственно, на работу по обращению с момента назначения обращения специалисту Подрядчика или группе исполнителей, ответственным за оказание услуг технической поддержки 3 уровня от начала до завершения работ Подрядчиком. При этом принимается суммарное время нахождения заявки в соответствующих статусах заявки СРО на стороне Подрядчика

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

Таблица 6. Категории обращений и заявок Категория Примеры Запрос на обслуживание Подготовка SQL запроса к СУБД для решения прикладной задачи и д.р. – запрос на любое действие, не являющееся запросом информации и несовершенный на основе происшествия, прямо или косвенно влияющего на работу Модуля СЦ Консультация «Где взять / куда обратиться...?», «Как сделать / выполнить…», «Как это работает…?» - запрос, имеющий своей целью получение информационной поддержки Инцидент Разбор ошибок/сбоев и подготовка материалов (корректировочных релизов, инструкций) для Заказчика для устранения ошибок/сбоев, которые приводят к частичному и полному нарушению работоспособности всех или отдельных функций ППО. Подготовка изменения и материалов, необходимых для проведения аварийно-восстановительных работ для возобновления работоспособности Модуля СЦ ЗНИ Подготовка изменений, связанных с изменением, улучшением/оптимизацией Модуля СЦ и выводом новой модифицированной функциональности в штатном режиме. Подготовка изменений, связанных с модификацией существующих и/или реализация новых интеграционных механизмов для получения/обработки данных внешних систем. Подготовка изменений графического интерфейса по требованиям Заказчика. Перечень статусов обращений (заявок) приведен в пункте 3.3. Регламента оказания Услуг. Назначение обращению (заявке) статуса «Закрыто» осуществляется Заказчиком только после получения от инициатора обращения (заявки) подтверждения о его исполнении или нахождения обращения (заявки) в статусе «Выполнено» и отсутствия повторных вопросов/запросов по данному обращению (заявки) в течение 5 рабочих дней. Категории и статусы обращений (заявок) могут быть скорректированы в процессе оказания услуг исключительно по согласованию с Заказчиком

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

4.3.6.2. Требования к услугам информационно-консультационной поддержки работников Заказчика и пользователей Модуля СЦ Услуги информационно-консультационной поддержки сотрудников Заказчика включают: – обработку обращений и заявок, поступивших от сотрудников Заказчика; – консультирование сотрудников Заказчика и пользователей Модуля СЦ; – актуализацию документации, и других материалов по работе с Модулем СЦ при необходимости. – консультирование и разработку рекомендаций по настройке Модуля СЦ (без изменения программного кода), включая изменение настроек функционирования; – консультации по вопросам использования, настройки и возможностям Модуля СЦ; – консультации по проведению превентивных мер для недопущения аварийных ситуаций в Модуле СЦ; – консультации по предварительной диагностике и локализации возникшей неисправности Модуля СЦ; – консультации по вопросам обеспечения информационной безопасности Модуля СЦ и настройки функций, обеспечивающих корректную работу программного обеспечения для совершения юридически значимых действий в Модуле СЦ; – другие вопросы, связанные с работой Модуля СЦ. 4.3.6.2.1. Требования к порядку оказания услуг информационно-консультационной поддержки работников Заказчика и пользователей Модуля СЦ Подрядчик выполняет консультирование сотрудников Заказчика и пользователей Модуля СЦ. Консультация может быть предоставлена по согласованным с представителем Заказчика каналам коммуникации с регистрацией результата консультации в СРО Подрядчиком. Детальный порядок оказания консультационных услуг определен в Регламенте оказания Услуг

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

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

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

4.3.6.4. Требования к услугам адаптационного, конфигурационного и коррекционного сопровождения и доработки Модуля СЦ (в рамках действующих программных модулей и функциональностей) Услуги адаптационного, конфигурационного и коррекционного сопровождения и доработки Модуля СЦ включают: – управление изменениями и адаптация функций Модуля СЦ; – изменение настроек функционирования Модуля СЦ; – внесение изменений и/или модификаций Модуля СЦ (в рамках действующих программных модулей и функциональностей), направленных на улучшение их работоспособности и функциональных возможностей; – подготовка и передача Заказчику SQL запросов в СУБД для получения агрегированной информации из Модуля СЦ, которую невозможно получить с использованием графического пользовательского интерфейса; – адаптация модулей интеграций со смежными информационными системами

4.3.6.4.2. Требования к изменению настроек функционирования Изменение настроек функционирования может проводиться в рамках допустимых пределов изменения функционирования, заложенных в архитектуру Модуля СЦ. Изменение настроек функционирования включает в себя изменение данных и справочников, изменение форм документов, формируемых Модулем СЦ, изменение и настройку форматов и версий передачи данных в смежные системы. Доработка программного кода Модуля СЦ может допускаться (в случае необходимости) при выполнении работ по адаптации функций Модуля СЦ в части изменения формата передачи данных в смежные информационные системы при условии соблюдения требований пункта 29.3 приказа ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации»

4.3.6.5. Требования к услугам по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности По запросу Заказчика Подрядчик должен провести работу по приведению ППО в соответствие с требованиями по обеспечению информационной безопасности. Критичность уязвимости оценивается в соответствии в соответствии с Методическим документом ФСТЭК России «Методика оценки уровня критичности уязвимостей программных, программно-аппаратных средств» (утвержден ФСТЭК России 30.06.2025), а также с учетом ГОСТ 56545-2015 и международными стандартами (CVSS 3.0 и выше), и задает необходимый срок устранения. В процессе проведения Заказчиком обследования Модуля СЦ и выявления уязвимостей в ППО, связанных с исходным кодом Модуля СЦ и/или используемыми компонентами (библиотеками), Заказчик направляет Подрядчику обращение (заявку) на устранение, с указанием критичности и срочности принятия мер по устранению в СРО.

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

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

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

4.4. Требования к видам обеспечения 4.4.1. Требования к лингвистическому обеспечению Документация на Модуль СЦ должна разрабатываться на русском языке. Взаимодействие пользователей с Модулем СЦ посредством графического интерфейса должно происходить на русском языке за исключением сообщений, зависящих от настроек системного программного обеспечения, установленного на рабочих местах пользователей. При разработке программных решений Модуля СЦ должно быть предусмотрено использование языков программирования высокого уровня, приведенных в Таблице 7. Таблица 7. Языки и средства разработки, специального программного обеспечения Модуля СЦ Категория Наименование Назначение Языки программирования Kotlin Разработка серверной логики и сервисов (backend) JavaScript / TypeScript Разработка клиентской части (frontend) Python Разработка скриптов интеграции, обработки данных и автоматизации Фреймворки и библиотеки Vue.JS Разработка пользовательских интерфейсов (веб-интерфейсы компонентов визуализации и отчетности) React Разработка пользовательских интерфейсов (при необходимости создания сложных интерактивных компонентов) Решения по лингвистическому обеспечению, включая перечень используемых языков программирования, должны быть согласованы с Заказчиком на этапе технического проектирования

4.4.2. Требования к математическому обеспечению Требования к математическому обеспечению не предъявляются. 4.4.3. Требования к метрологическому обеспечению Требования к метрологическому обеспечению не предъявляются. 4.4.4. Требования к организационному обеспечению Требования к организационному обеспечению не предъявляются. 4.4.5. Требования к методическому обеспечению Задачи методического обеспечения Модуля СЦ должны быть обеспечены за счет использования технологических и методических документов касающихся вопросов функционирования транспортного комплекса и разработки и эксплуатации ПО. 4.4.6. Требования к информационному обеспечению Состав, структура и способы организации информационного обеспечения в Модуле СЦ должны быть определены на этапе технического проектирования. Факты информационного обмена с внешними системами должны фиксироваться в соответствующем журнале

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

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

4.4.7.1. Требования к инструментам разработки и процессу контроля версий программного обеспечения 4.4.7.1.1. Система контроля версий Для управления исходным кодом должна использоваться система контроля версий кода, развернутая в инфраструктуре Заказчика. 4.4.7.1.2. Правила именования веток Имя ветки должно соответствовать следующему формату: / / Категории веток: ? feature/ — разработка новой функциональности, а также рефакторинг или удаление существующей; ? fix/ — исправление ошибок; ? hotfix/ — срочные исправления, применяемые в обход стандартного процесса разработки; ? test/ — для проведения экспериментов, не влияющих на основную разработку. Идентификатор задачи: после категории указывается ссылка на задачу (issue) в системе контроля версий кода. Описание: добавляется краткое описание решаемой задачи в формате kebab-case (слова разделяются дефисами, например, add-user-auth). Примеры именования веток: ? feature/#123/add-payment-integration; ? fix/#45/correct-calculation-logic; ? hotfix/#67/urgent-database-connection-patch. 4.4.7.1.3. Правила именования коммитов Сообщение коммита должно соответствовать соглашению Conventional Commits и состоять из категории и описания: : ? fix — исправление ошибки. Примеры сообщений коммитов: ? feat: добавление формы регистрации пользователя; ? fix: исправление ошибки валидации email-адреса; ? refactor: оптимизация алгоритма сортировки данных; ? chore: обновление версий в файле dependencies. 4.4.7.1.4. Модель ветвления В процессе разработки используются следующие основные ветви: ? main / master — стабильная ветка, содержит только код, прошедший полное тестирование и развернутый в продуктивных контурах; ? dev — ветка для интеграции завершенных задач, предназначенная для сборки и тестирования в тестовых средах. Попадание кода в main осуществляется только через Merge Request (MR) из dev

4.4.7.1.5. Требования к используемым зависимостям (библиотекам) Все внешние зависимости проекта должны быть зафиксированы с указанием точных версий. Для контроля версий зависимостей в репозиторий обязательно должны быть включены следующие файлы: · Для JavaScript: package-lock.json или yarn.lock; · Для Python: requirements.txt (с зафиксированными версиями) или Pipfile.lock; · Для Go: go.mod и go.sum; Загрузка всех зависимостей должна производиться исключительно через внутренний прокси-репозиторий Заказчика, настроенный в соответствующем системе менеджере пакетов. Запрещается: · Использование плавающих версий (например, ^1.2.3, ~4.5.0, latest); · Использование библиотек, содержащих критические уязвимости, в том числе зарегистрированные в реестре CVE (Common Vulnerabilities and Exposures). 4.4.7.1.6. Требования к процессу непрерывной интеграции (CI) Сборка программного обеспечения, включая этапы компиляции, тестирования и анализа кода, должна выполняться исключительно в инфраструктуре непрерывной интеграции Заказчика. 4.4.7.1.7. Требования к хранению артефактов сборки Все артефакты сборки (результирующие пакеты, Docker-образы и т.д.) подлежат обязательному хранению в предназначенной для этого инфраструктуре Заказчика (артефакторий). Запрещается размещение финальных артефактов сборки на сторонних ресурсах

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

4.5. Общие технические требования 4.5.1. Требования к численности и квалификации персонала и пользователей Модуля СЦ Программное обеспечение Модуля СЦ не должно требовать изменения штатной численности персонала Заказчика. Программное обеспечение Модуля СЦ не должно требовать наличия у пользователей дополнительной квалификации в сфере информационных технологий, кроме базовых знаний в обращении с персональным компьютером, базовых навыков работы в интернет-обозревателях и знаний о Модуле СЦ в объеме документов Руководство пользователя, Руководство администратора

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

В аварийном режиме осуществляется поиск неисправностей и проведение работ по их устранению. Перевод в аварийный режим должен осуществляться при возникновении сбоев, аварий и прочих незапланированных воздействий, сразу после наступления одной или нескольких аварийных ситуаций, с последующим возвратом в штатный режим функционирования сразу после окончания восстановительных работ. ПО Модуля СЦ должно обладать надежностью, обеспечивающей работу пользователей в произвольном режиме и оперативное восстановление работоспособности при сбоях. В целях обеспечения надежного функционирования ПО должно предусматривать: – сохранение целостности данных при нештатном завершении работы компонентов Модуля СЦ; – сохранение работоспособности программного обеспечения при некорректных действиях пользователя; – резервное копирование базы данных Модуля СЦ. – время восстановления работоспособности Модуля СЦ после отказа не более 4 часов. – отказоустойчивость на уровне 99% при единовременной количестве не менее 200 пользовательских сессий в Модуле СЦ. Указанные характеристики приведены без учета характеристик надежности инфраструктуры и времени передачи информации по каналам связи. При возникновении сбоев в аппаратном обеспечении, включая аварийное отключение электропитания, Модуль СЦ должен автоматически восстанавливать свою работоспособность (не требовать перенастройки) после устранения сбоев и корректного перезапуска аппаратного обеспечения

4.5.5. Требования к информационной безопасности Работы по защите информации/информационной безопасности, не включенные в состав настоящего раздела, требуемые в соответствии с требованиями постановления Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации», а также нормативно правовых актов в области защиты персональных данных и обеспечения безопасности объектов критической информационной инфраструктуры, будут проведены в рамках исполнения отдельного контракта, заключенного по результатам отдельной закупочной процедуры (не является частью данного ТЗ), включающего: – определение актуальных угроз безопасности информации и актуализация модели угроз безопасности информации (при необходимости); – выполнение требований о согласовании технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России в установленном порядке; – выполнение требований по устранению Подрядчиком замечаний и недостатков, в случае их выявления при согласовании Заказчиком технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России; – выполнение требований к классу защищенности ГИС, уровню защищенности персональных данных и категории значимости объекта КИИ РФ, установленных для Головного центра обработки данных ФГБУ «СИЦ Минтранса России» (далее – ГЦОД);

– определение перечня объектов защиты информационной системы; – описание (актуализированных) требований к системе защиты информации, а также к мерам защиты информации информационной системы в зависимости от установленных классов защищенности, уровня защищенности персональных данных и категории значимости объектов КИИ РФ (приказы ФСТЭК России № 21, 117, 239); – выполнение требований к мерам по защите ГИС от атак, направленных на отказ в обслуживании, в соответствии с пунктами 30, 34, 59, 63 Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений, утвержденных приказом ФСТЭК России от 11.04.2025 № 117; – описание (актуализированных) требований по защите информации, подлежащих реализации в информационно телекоммуникационной инфраструктуре ГЦОД; – выполнение требований о применении сертифицированных средств защиты информации, включая их классы защиты и уровни доверия; – выполнение требований о запрете использования с 01.01.2025 органами (организациями) средств защиты информации странами происхождения, которых являются иностранные государства в соответствии с пунктом 6 Указа Президента Российской Федерации от 01.05.2022 № 250; – выполнение требований по обеспечению непрерывного взаимодействия с ГосСОПКА в установленном порядке;

– выполнение требований по обеспечению в автоматизированном режиме с Национальной системой противодействия DDoS-атакам (НСПА) Центра мониторинга и управления сетью связи общего пользования ФГУП «ГРЧЦ» в рамках реализации мер по защите ГИС от атак, направленных на отказ в обслуживании; – детализированные требования к составу и содержанию работ по аттестации, а также к их результатам в соответствии с пунктами 13, 15 и 16 требований приказа ФСТЭК России от 29.04.2021 № 77 «Об утверждении Порядка организации и проведения работ по аттестации объектов информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну»

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

Подрядчик должен обеспечить реализацию и проведение внутренних проверок мер по разработке безопасного ПО, приведенных в Руководстве. Подрядчик должен провести анализ угроз безопасности информации программного обеспечения в соответствии с ГОСТ 58412-2019 «Защита информации. Разработка безопасного программного обеспечения. Угрозы безопасности информации при разработке программного обеспечения». Подрядчик должен провести испытания по выявлению уязвимостей в программном обеспечении Системы: · проведение статического анализа исходного кода программы; · проведение динамического анализа исходного кода программы; · проведение композитного анализа исходного кода и образов программы; · проведение фаззинг-тестирования программы, направленного на выявление в ней уязвимостей. Испытания по выявлению уязвимостей в программном обеспечении Системы должны быть проведены в рамках: · предварительных испытаний; · опытной эксплуатации; · приемочных испытаний

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

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

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

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

4.5.8. Требования к защите от влияния внешних воздействий Требования к защите от влияния внешних воздействий не предъявляются

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

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

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

4.5.11. Требования к показателям назначения 4.5.11.1. Требования к показателям назначения мероприятий по развитию Модуля СЦ В рамках выполнения работ по развитию Модуля СЦ, предусмотренных ТЗ, показатель назначения «Количество пользователей» должен соответствовать значениям, приведенным в данном разделе. Пояснения по показателям, связанным с количеством пользователей, приведены в Таблице 8. Таблица 8. Определения показателей, связанных с количеством пользователей в Модуле СЦ № Показатель Определение Расчетное количество пользователей Количество пользователей, работу которых должен обеспечить Модуль СЦ к моменту сдачи работ по Контракту с учетом достижения всех показателей назначения Расчетное количество одновременно работающих пользователей Количество одновременно работающих пользователей, работу которых должен обеспечивать Модуль СЦ к моменту сдачи работ по Контракту с учетом достижения всех показателей назначения Значения показателей количества пользователей, достижение которых необходимо обеспечить, представлено в Таблице 9

Таблица 9. Значения показателей количества пользователей № Показатель Значение 1. Расчетное количество пользователей 1 000 2. Расчетное среднее количество одновременно работающих пользователей 200 Развитие Модуля СЦ должно быть направлено на достижение следующего эффекта (показателя), подставленного в мероприятии 103.002 «Информационно-аналитическая система регулирования на транспорте (АСУ ТК)» ВПЦТ Минтранса России: Выполнение работ по развитию Модуля СЦ предусмотрено мероприятием по развитию АСУ ТК, приведенном в ВПЦТ Минтранса России на 2026-2028 гг: № 103.002 «АСУ ТК» в составе ИТ расхода 103.26.000005 «Развитие предусматривает реализацию ОКР и эффектов, приведенных в Таблице 10. Таблица 10. ОКР и эффекты, приведенные в ВПЦТ Минтранса России на 2026 г. № ОКР Дата ОКР Эффекты 1 Обеспечено информационное взаимодействие с Минобороны России о происшествиях на транспортных объектах 25.12.2026 Сокращено время сбора и передачи сведений для Минобороны России о ЧС и НС на транспорте с 120 до 10 минут 2 Обеспечена автоматизация формирования отчетов о нештатных ситуациях на транспорте, в том числе по данным внешних систем 25.12.2026 Сокращено время на подготовку отчетов о нештатных ситуациях на транспорте с 20 до 5 минут Реализация остальных ОКР не является предметом данного ТЗ и проводится в рамках отдельного технического задания.

4.5.11.2. Требования к показателям назначения мероприятий по эксплуатации Модуля СЦ. Работы по эксплуатации Модуля СЦ не должны обеспечивать режимы функционирования Модуля СЦ, приведенные в разделе 4.5.2 данного ТЗ

5. СОСТАВ И СОДЕРЖАНИЕ РАБОТ ПО РАЗВИТИЮ И ТЕХНИЧЕСКОЙ ПОДДЕРЖКЕ МОДУЛЯ СЦ (КАЛЕНДАРНЫЙ ПЛАН) - 1 Техническое проектирование Сопроводительным письмом предоставляются Заказчику: · Технический проект, включая следующие документы: – Ведомость технического проекта; – Ведомость машинных носителей информации – Пояснительная записка; – Описание информационного обеспечения системы; – Описание автоматизируемых функций; – Схема функциональной структуры; – Описание организации информационной базы; – Описание программного обеспечения; · Макеты экранных форм компонента «Интерактивная карта»; · Руководство по безопасной разработке программного обеспечения; · Документ о приемке Начало: с даты заключения контракта Окончание: не позднее 31.07.2026 - - Значение характеристики не может изменяться участником закупки

2 Услуги по технической поддержке Модуля СЦ (с даты заключения контракта по 10.09.2026) По окончании оказания Услуг сопроводительным письмом предоставляются Заказчику: – Отчет об оказанных Услугах по технической поддержке; – Актуальные на дату окончания оказания Услуг по данному этапу исходные коды прикладного ПО на электронном носителе (в случае внесения изменений); – Инструкция по сборке и развертыванию (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство пользователя (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство администратора (в случае внесения изменений); – Документ о приемке Начало: с даты заключения контракта Окончание: не позднее 10.09.2026

3 Разработка программного обеспечения (1 очередь, пп. 4.2.1, 4.2.6 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ; – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 1 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 1 очереди; – Руководство по резервному копированию; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 16.09.2026

4 Разработка программного обеспечения (2 очередь, пп. 4.2.3, 4.2.4 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ. – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 2 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 2 очереди; – Руководство по резервному копированию; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 25.09.2026

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

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

5 Разработка программного обеспечения (3 очередь, пп. 4.2.2, 4.2.5 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ; – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 3 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 3 очереди; – Руководство по резервному копированию; – Описание ролевой модели; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 09.10.2026

6 Опытная эксплуатация (1 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акт о завершении опытной эксплуатации 1 очереди; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке 17.09.2026 Окончание: не позднее 26.10.2026

7 Опытная эксплуатация (2 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акт о завершении опытной эксплуатации 2 очереди; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке 26.09.2026 Окончание: не позднее 26.10.2026

8 Опытная эксплуатация (3 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Акт о завершении опытной эксплуатации 3 очереди; – Документ о приемке Начало: с 10.10.2026 Окончание: не позднее 26.10.2026

9 Приемочные испытания Сопроводительным письмом предоставляются Заказчику: – Программа и методика приёмочных испытаний; – Протокол приемочных испытаний; – Исходные коды и дистрибутивы на электронном носителе (при условии внесения изменений, с учетом доработок по результатам опытной эксплуатации и проведенных испытаний); – Комплект рабочей документации на Модуль СЦ (при условии внесения изменений, с учетом доработок по результатам опытной эксплуатации и проведенных испытаний); – Акт приемки Системы в эксплуатацию; – Акт приемки-передачи исключительных прав на объект; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке; – Документы в соответствии с разделом 4.5.9 ТЗ; – Обеспечение гарантийных обязательств Начало: с 27.10.2026 Окончание: не позднее 10.11.2026

10 Услуги по технической поддержке Модуля СЦ (с 11.09.2026 по 15.12.2026) По окончании оказания Услуг сопроводительным письмом предоставляются Заказчику: – Отчет об оказанных Услугах по технической поддержке; – Актуальные на дату окончания оказания Услуг по данному этапу исходные коды прикладного ПО на электронном носителе (в случае внесения изменений); – Инструкция по сборке и развертыванию (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство пользователя (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство администратора (в случае внесения изменений); – Документ о приемке Начало: с 11.09.2026 Окончание: не позднее 15.12.2026

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

6.1. Сведения о гарантийном обслуживании Модуля СЦ Под гарантией понимается устранение Подрядчиком своими силами и за свой счет допущенных по его вине недостатков, выявленных после приемки выполненных Работ, как в работе самой Модуля СЦ, так и недостатков в отчетной документации. Если в период гарантийного срока обнаружатся недостатки, то Подрядчик обязан устранить их за свой счет, в сроки, установленные Заказчиком. Гарантийный срок в этом случае продлевается на период устранения недостатков. Срок гарантии: 1 год с даты приемки Заказчиком результатов исполнения Этапа № 9 контракта. Подрядчиком должны быть внесены соответствующие исправления в техническую и рабочую документацию (указанную в пунктах 5 и 6 настоящего ТЗ), связанные с устранением замечаний к работе Модуля СЦ или в случае выявления Заказчиком недостатков в такой документации в период гарантийного срока. Внесение изменений в документацию технического и рабочего проектирования осуществляется в соответствии с ГОСТ 2.503-2023 и ГОСТ Р 2.504-2021.

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

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

8. ТРЕБОВАНИЯ К СОСТАВУ И СОДЕРЖАНИЮ РАБОТ ПО ПОДГОТОВКЕ МОДУЛЯ СЦ К ВВОДУ В ЭКСПЛУАТАЦИЮ - По результатам проведения приемочных испытаний оформляется Протокол приемочных испытаний и Акт приемки в эксплуатацию. В случае, если взаимодействие с внешними системами не может быть проверено на средах постоянной эксплуатации взаимодействующих систем (по причине неготовности со стороны внешней системы или иным причинам), функции взаимодействия, разработанные в соответствии с требованиями ТЗ, должны быть проверены на тестовых данных с использованием программ-имитаторов взаимодействия. По результатам выполнения этапа приемочных испытаний должны быть подготовлены материалы для регистрации доработанной версии Модуля СЦ (объекта учета) в НФАП в соответствии с требованиями постановления Правительства Российской Федерации от 30 января 2013?г. №?62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин» (с изменениями и дополнениями) в части обязательности размещения результатов работ в национальном фонде алгоритмов и программ для электронных вычислительных машин. Сдача-приемка результатов выполнения Работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная, техническая документация, а также программное обеспечение предоставляется Заказчику в порядке, предусмотренном Контрактом и ТЗ до размещения Подрядчиком в Единой информационной системе в сфере закупок документа о приемке. Результаты проведения опытной эксплуатации, предварительных и приемочных испытаний должны быть зафиксированы в соответствующих протоколах и актах. Выявленные отклонения от настоящего ТЗ, оформляются как недостатки Модуля СЦ - - Значение характеристики не может изменяться участником закупки

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

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

9. ТРЕБОВАНИЯ К ДОКУМЕНТИРОВАНИЮ - 9.1. Общие требования Документация на Модуль СЦ должна быть разработана в составе, указанном в разделах 5-8 данного ТЗ, и должна удовлетворять требованиям комплекса стандартов и руководящих документов на автоматизированные системы: – ГОСТ Р 2.105-2019 в части оформления текстовых документов; – ГОСТ 34.201-2020 в части наименования и обозначения документов. Документация на Модуль СЦ должны оформляться на листах формата А4. Допускается для размещения рисунков и таблиц использование листов формата А3 с подшивкой по короткой стороне листа. Документы объемом более 25 (двадцати пяти) листов должны содержать информационную часть, состоящую из аннотации и содержания. Исходные коды должны быть представлены в 1 (одном) экземпляре на электронном носителе, отчетные материалы должны быть представлены в 2 (двух) экземплярах на бумажном носителе (по одному экземпляру для Заказчика и Подрядчика) и в 1 (одном) экземпляре на электронном носителе в формате документов DOCX и PDF. При разработке документов на Модуль СЦ допускается отклонение от требований комплекса стандартов, описанных выше. Документам на Модуль СЦ должны в обязательном порядке присваиваться уникальные децимальные номера в соответствии с порядком, установленном в ГОСТ 34.201-2020. Документ «Программа и методика предварительных испытаний» должен включать приложения с формой протокола предварительных испытаний и формой акта приемки в опытную эксплуатацию. Документ «Программа опытной эксплуатации» должен включать приложение с формой журнала опытной эксплуатации. Документ «Программа и методика приемочных испытаний» должен включать приложения с формой протокола приемочных испытаний и формой акта приемки в эксплуатацию - - Значение характеристики не может изменяться участником закупки

10. ИСТОЧНИКИ РАЗРАБОТКИ - 10.1. Список литературы Специальная литература для разработки ТЗ не использовалась. 10.2. Нормативно-методические документы Список используемых нормативно-методических документов представлен в разделе 1.6 технического задания. ? Приложение А Эскизы визуального оформления компонента «Интерактивная карта» - - Значение характеристики не может изменяться участником закупки

Приложение Б Параметры оказания услуг - Б.1. Базовые параметры оказания Услуг Базовые параметры оказания Услуг приведены ниже: – режимы оказания Услуг (таблица Б.1.1); – сроки предоставления отчетности (таблица Б.1.2). Таблица Б.1.1 - Режимы оказания Услуг № п/п Параметр Значение - - Значение характеристики не может изменяться участником закупки

Б.2. Приоритеты и регламентные сроки решения обращений (заявок) В зависимости от уровня сбоя в работе Системы обращению (заявке) присваивается один из следующих приоритетов, а также в зависимости от приоритета обращения (заявки) устанавливаются следующие контрольные сроки решения в соответствии с таблицей ниже (Таблица Б.2.1). Таблица Б.2.1 – Приоритеты и регламентные сроки решения обращений (заявок) № п/п Приоритет Максимальное время реагирования Время решения (срок выполнения) Описание приоритета По информационно-консультационной поддержке сотрудников Заказчика и пользователей Системы 1 - не более 1 часа не более 10 часов - По решению инцидентов, связанных с работой ППО: 1 Критический не более 30 минут не более 4 часов - полная недоступность ППО; - недоступность ключевых функций - ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО; - невозможность информационного обмена с ППО для ИС более 4 часов 2 Высокий не более 1 часа не более 8 часов - ошибки/сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; - снижение быстродействия СПО (время отклика ППО на операции превышает 30 секунд); - недоступность управления правами и ролями пользователей 3 Средний не более 4 часов не более 24 часов - невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым -недоступность функции формирования отчетов 4 Низкий не более 8 часов не более 40 часов - отклонение в работе ППО, не влияющее на корректную работу функций; - другие сбои и ошибки, затрагивающие основные функции ППО

По адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) 1 Критический не более 40 минут не более 8 часов - изменения, необходимые при проведении аварийно-восстановительных работ для возобновления работоспособности Системы; - изменения, связанные с критичными ошибками, блокирующими возможность оказания государственных услуг и/или чтение и внесение данных в Систему 2 Высокий не более 1 часа не более 40 часов - изменения, относящиеся к обеспечению работоспособности основной функциональности Системы, устраняют выявленные дефекты в работе Системы, оказывающие существенное влияние на работу пользователей в Системе; - изменения, затрагивающие три и более подсистемы/модуля Системы для адаптации 3 Средний не более 4 часов не более 72 часов - изменения, связанные с развитием/улучшением/оптимизацией Системы и выводом новой функциональности в штатном режиме для одного-двух модулей/подсистем; - изменения, связанные с развитием интеграционных механизмов Системы, например обновление существующих и/или реализация новых видов сведений СМЭВ, обновление существующих и/или реализация новых API, адаптация и/или изменение механизмов импорта и экспорта данных Системы и т.д. 4 Низкий не более 8 часов не более 160 часов - изменения, связанные с ошибками/корректировкой/изменением в отображении информации в пользовательском графическом интерфейсе Системы (графика, текст, органы управления, элементы интерфейса)

1 Режим работы Системы Круглосуточно (24х7) 2 Режим доступности информационно-консультационной поддержки пользователей Системы 2.1 Прием и регистрация обращений (заявок) в СРО Регистрация обращений (заявок) производится круглосуточно в режиме 24х7, без праздников и выходных дней. Обработка заявок первой линией поддержки осуществляется в рабочие дни с 9 до 18 часов 2.2 Консультирование сотрудников Заказчика и пользователей Системы в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 3 Режим доступности по решению инцидентов, связанных с работой ППО: 3.1 - приоритет «Критический» Круглосуточно (24х7) 3.2 - приоритет «Высокий» Круглосуточно (24х7) 3.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 3.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4 Режим доступности услуг по адаптации, конфигурации и коррекционному сопровождению Системы 4.1 - приоритет «Критический» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.2 - приоритет «Высокий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 5 Режим доступности по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности 5.1 - приоритет «Критический» Круглосуточно (24х7) 5.2 - приоритет «Высокий» Круглосуточно (24х7) 5.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 5.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням)

Таблица Б.1.2. Сроки предоставления отчетности, с момента получения запроса № п/п Параметр Значение 1 Предоставление отчета об оказанных услугах за произвольный период 10 рабочих дней 2 Предоставление подробной информации по инциденту с приоритетом «Критический» 16 рабочих часов 3 Предоставление актуализированной документации 10 рабочих дней

По устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности 1 Критический не более 30 минут не более 24 часов - критические уязвимости, влияющие на возможную полную недоступность ППО, ключевых функций Системы, ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО без возможности восстановления работоспособности Системы. - Критический уровень CVSS > 8.0 2 Высокий не более 1 часа не более 84 часов - критические уязвимости, влияющие на ошибки и сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО. - Высокий уровень CVSS 5.0 - 8.0 3 Средний не более 4 часов не более 120 часов - уязвимости, влияющие на невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым - Средний уровень CVSS 2.0 - 4.9 4 Низкий не более 8 часов не более 160 часов - уязвимости, влияющие на отклонение в работе ППО, не влияющее на корректную работу функций; - другие сбои и ошибки, затрагивающие основные функции ППО - Низкий уровень CVSS < 2.0

Взаимодействие Заказчика и Подрядчика в части регистрации и контроля времени реагирования и решения обращения (заявки) осуществляется через СРО. Заказчик предоставляет Подрядчику доступ к СРО после заключения Контракта. Поступившие от разных пользователей заявки по поводу однотипных инцидентов или имеющие общую причину должны объединяться в одну заявку. Срок выполнения включает время диагностики инцидента, в ходе которого определяется причина инцидента (проблемы) и способ его устранения. Подрядчик должен обеспечить функционирование Модуля СЦ в соответствии с требованиями и параметрами, указанными в настоящем ТЗ и Регламенте оказании услуг. Основные параметры быстродействия типовых операций в Модуле СЦ указаны в таблице ниже (таблица Б.2.2). Таблица Б.2.2 - Параметры быстродействия Модуля СЦ № п/п Наименование параметра Значение (секунд) 1 Среднее время получения сообщения из очереди сообщений 10 2 Среднее время получения ответа от Системы 5 3 Среднее время открытия карточки реестра 5

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

На рисунке 8 приведена форма обращения (заявки) типа «Инцидент» в СРО. Рисунок 8 - Форма обращения (заявки) типа «Инцидент» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуги по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности, заполненную в свободной форме

Приложение 1 к Регламенту Матрица ответственных за взаимодействия в рамках выполнения работ по техническому сопровождению Системы Таблица 1 – Ответственные за взаимодействия в рамках выполнения работ по техническому сопровождению Системы со стороны Исполнителя ФИО Должность Адрес электронной почты Телефон — — — Общий контакт

Приложение 2 к Регламенту Приоритеты и регламентные сроки решения обращений (заявок) Приоритеты и регламентные сроки решения обращений (заявок) приведены в таблице 1. Таблица 1 – Приоритеты и регламентные сроки решения обращений (заявок) № п/п Приоритет Максимальное время реагирования Время решения (срок выполнения) Описание приоритета

По информационно-консультационной поддержке сотрудников Заказчика и пользователей Системы 1 – не более 1 часа не более 10 часов –

По решению инцидентов, связанных с работой ППО 1 Критический не более 30 минут не более 4 часов – полная недоступность ППО; – недоступность ключевых функций; – ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО; – невозможность информационного обмена с ППО для ИС более 4 часов 2 Высокий не более 1 часа не более 8 часов – ошибки/сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; – снижение быстродействия СПО (время отклика ППО на операции превышает 30 секунд); – невозможность управления правами и ролями пользователей 3 Средний не более 4 часов не более 24 часов – невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым недоступность функции формирования отчетов 4 Низкий не более 8 часов не более 40 часов – отклонение в работе ППО, не влияющее на корректную работу функций; – другие сбои и ошибки, затрагивающие основные функции ППО

По адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) 1 Критический не более 40 минут не более 8 часов – изменения необходимые при проведении аварийно-восстановительных работ для возобновления работоспособности Системы; – изменения, связанные с критичными ошибками, блокирующими возможность оказания государственных услуг и/или чтение и внесение данных в Систему 2 Высокий не более 1 часа не более 40 часов – изменения относящиеся к обеспечению работоспособности основной функциональности Системы, устраняют выявленные дефекты в работе Системы, оказывающие существенное влияние на процесс оказания государственных услуг и работу пользователей в Системе; – изменения, затрагивающие три и более подсистемы/модуля Системы для адаптации 3 Средний не более 4 часов не более 72 часов – изменения, связанные с развитием/улучшением/оптимизацией Системы и выводом новой функциональности в штатном режиме для одного-двух модулей/подсистем; – изменения, связанные с развитием интеграционных механизмов Системы, например, обновление существующих и/или реализация новых видов сведений СМЭВ, обновление существующих и/или реализация новых API, адаптация и/или изменение механизмов импорта и экспорта данных Системы и т.д. 4 Низкий не более 8 часов не более 160 часов – изменения, связанные с ошибками/ корректировкой/изменение в отображении информации в пользовательском графическом интерфейсе Системы (графика, текст, органы управления, элементы интерфейса)

По устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности 1 Критический не более 30 минут не более 24 часов – критические уязвимости, влияющие на возможную полную недоступность ППО, ключевых функций Системы, ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО без возможности восстановления работоспособности Системы; – Критический уровень CVSS > 8.0 2 Высокий не более 1 часа не более 84 часов – критические уязвимости, влияющие на ошибки и сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; – Высокий уровень CVSS 5.0 - 8.0 3 Средний не более 4 часов не более 120 часов – уязвимости, влияющие на невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым; – Средний уровень CVSS 2.0 - 4.9 4 Низкий не более 8 часов не более 160 часов – уязвимости, влияющие на отклонение в работе ППО, не влияющее на корректную работу функций; – другие сбои и ошибки, затрагивающие основные функции ППО; – Низкий уровень CVSS < 2.0

Приложение Г Форма Отчета об оказанных услугах Отчет об оказанных услугах за этап «наименование этапа» в период с «__» _________ по «__» _________. № п/п Наименование услуги Общее количество Номер ОРС Краткое Описание Время реагирования по ТЗ Время реагирования фактическое Время решения по ТЗ Время решения фактическое Результат соблюдения времени реагирования Результат соблюдения времени решения Примечание 1 Услуги по информационно-консультационной поддержке работников Заказчика 2 546782 Консультация по работе Модуля СЦ 1 2 10 часов 11 часов Нет Нет 567123 Консультация по схеме БД 1 1 10 часов 1 час Да Да 2 … … Заказчик Подрядчик /Должность/ /Должность/ ____________________ /Ф.И.О/ ___________________ /Ф.И.О/ М.П. М.П. «_____»_______________________202_г. «_____»_______________________202_г

Приложение 1 к Отчету об оказанных услугах Журнал обращений (заявок) на оказание услуги по информационно-консультационной поддержке пользователей Системы (шаблон) Наименование Исполнителя в этапе «наименование этапа» в период с ________________ по _______________ оказал(о) Услугу по поддержке пользователей Системы в объеме, указанном в Таблице 1 Таблица 1 - Журнал обращений (заявок) пользователей Системы № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. ИТОГО зарегистрировано: Всего обращений (заявок): ________ ИТОГО решено: Всего обращений (заявок): ________

Приложение 2 к Отчету об оказанных услугах Журнал обращений (заявок) по решению инцидентов, связанных с работой ППО (шаблон) Наименование Исполнителя в этапе «наименование этапа» в период с ________________ по _______________ оказал(о) Услугу по решению инцидентов в объеме, указанном в Таблице 1. Таблица 1 - Журнал по решению инцидентов № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. ИТОГО зарегистрировано: Всего инцидентов: ________ ИТОГО решено: Всего инцидентов: ________

Приложение 3 к Отчету об оказанных услугах Журнал обращений (заявок) выполнения адаптационного, конфигурационного и коррекционного сопровождения Системы (шаблон) Журнал выполнения адаптации, конфигурации и коррекции Системы сформирован за этап «наименование этапа» в период с «__» _________ по «__» ____________ и представлен в таблице ниже (Таблица 1). Таблица 1 - Журнал выполнения адаптации, конфигурации и коррекции сопровождения Системы № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. Количество выполненных заявок за этап: ________

Приложение 4 к Отчету об оказанных услугах Журнал обращений (заявок) по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности (шаблон) Журнал обращений (заявок) по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности сформирован за этап «наименование этапа» в период с «__» _________ по «__» ____________ и представлен в таблице ниже (Таблица 1). Таблица 1 - Журнал выполнения заявок по устранению уязвимостей в ППО № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. Количество выполненных заявок за этап: ________

Приложение Д Форма Протокола проверки результатов организационно-штатных и подготовительных мероприятий (шаблон) Протокол проверки результатов организационно-штатных и подготовительных мероприятий Настоящий Протокол содержит результаты проверки организационно-штатных и подготовительных мероприятий, проведенных Исполнителем (Таблица Д.1). Таблица Д.1. Протокол проверки результатов № Мероприятия Подготовительного этапа Результат проверки 1. Определить и направить Заказчику документ «Ответственные за взаимодействия в рамках выполнения работ по техническому сопровождению Системы со стороны Исполнителя». Документ содержит контактную информацию (ФИО, должность, адрес электронной рабочей почты, номер телефона) не менее чем о 2 лицах, ответственных за оказание услуг со стороны Подрядчика Выполнено/Не выполнено 2. Обеспечить подключение специалистов Подрядчика к Системе Выполнено/Не выполнено 3. Обеспечить подключение специалистов Подрядчика к СРО Выполнено/Не выполнено Заказчик Подрядчик /Должность/ /Должность/ ____________________ /Ф.И.О/ ___________________ /Ф.И.О/ М.П. М.П. «_____»_______________________202_г. «_____»_______________________202_г

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

4 Формы обращений (заявок) на оказание услуг по технической поддержке Системы, заполняемые в СРО 4.1. Форма обращения (заявки) на оказание услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы При подаче обращения (заявки) типа «ЗНО» в СРО указывается (Таблица 5): Таблица 5 – Описание атрибутов формы обращения (заявки) на оказание услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 5) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 5) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 5) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 5) Категория обращения: информационно-консультационная поддержка Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 5) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 5) Текст запроса на оказание услуги по информационно-консультационной поддержке сотрудников Заказчика Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 5)

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

4.2. Форма обращения (заявки) на оказание услуги по решению инцидентов, связанных с работой ППО При подаче обращения (заявки) типа «Инцидент» в СРО указывается (Таблица 6): Таблица 6 – Описание атрибутов формы обращения (заявки) на оказание услуги по решению инцидентов, связанных с работой ППО Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 6) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 6) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 6,) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 6) Категория обращения (заявки): инцидент Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 6) Приоритет изменения Время - одно из значений: Низкий, Средний, Высокий или Критический. Определяет, очередность решения обращения (заявки), ресурсы, привлекаемые для решения обращения (заявки), порядок/процедура действий при решении обращения (заявки) – поле СРО «Приоритет» (см. рисунок 6,)

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

На рисунке 6 приведена форма обращения (заявки) типа «Инцидент» в СРО. Рисунок 6 - Форма обращения (заявки) типа «Инцидент» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуги по решению инцидентов, связанных с работой ППО, заполненную в свободной форме

4.3. Форма обращения (заявки) на оказание услуг по адаптационному конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) При подаче обращения (заявки) типа «ЗНИ» в СРО указывается (Таблица 7): Таблица 7 – Описание атрибутов формы обращения (заявки) на оказание услуг по адаптационному, конфигурационному и коррекционному сопровождению Системы Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 10) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 9) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 10) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 10) Категория обращения (заявки): запрос на изменение Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 7) Приоритет изменения Время, очередность решения обращения (заявки), ресурсы, привлекаемые для решения обращения (заявки), порядок/процедура действий при решении обращения (заявки) – поле СРО «Приоритет» (см. рисунок 7) Тип изменения Справочник, классифицирующий типовые запросы характерные для Системы – поле СРО «Предмет обращения» (см. рисунок 7) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 7) Текст запроса на оказание услуги по адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 7)

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

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

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

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

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

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

3.4.1 Инцидент На рисунке 2 представлена функциональная схема регистрации и сопровождения обращений (заявок) типа «Инцидент». Рисунок 2 - Функциональная схема регистрации и сопровождения обращений (заявок) типа «Инцидент» 3.4.2 Запрос на обслуживание На рисунке 3 представлена функциональная схема регистрации и сопровождения обращения (заявки) типа «ЗНО». Рисунок 3 - Функциональная схема регистрации и сопровождения обращения (заявки) типа «ЗНО» 3.4.3 Запрос на изменение На рисунке 4 представлена функциональная схема регистрации и сопровождения обращений (заявок) типа «ЗНИ». Рисунок 4 - Функциональная схема регистрации и сопровождения обращений (заявок) типа «ЗНИ»

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

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

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

Уровень технической поддержки Организационно-структурная часть технической поддержки, имеющая определённые организационно-нормативными документами зоны ответственности, обязанности, а также временные нормативы, в течение которых эти обязательства должны выполняться либо эскалироваться на следующий уровень технической поддержки Услуги Услуги по технической поддержке Информационно-аналитической системы регулирования на транспорте АСУ ТК ФИО Фамилия, имя, отчество Эскалация Процедура повышения внимания к обращению (заявке) путем повышения его приоритета и/или передачи на следующий уровень технической поддержки, а также привлечение ролей, которые могут принимать решения без передачи на следующий уровень технической поддержки API Англ. Application Programming Interface — программный интерфейс приложения, интерфейс прикладного программирования — описание способов (набор классов, процедур, функций, структур или констант), которыми одна компьютерная программа может взаимодействовать с другой программой

CVSS Англ. Common Vulnerability Scoring System - открытый стандарт, используемый для расчета количественных оценок уязвимости в безопасности компьютерной системы, обычно с целью понять приоритет ее исправления. В современном инструментарии информационной безопасности используется версия 3.0 и выше с дополнительными метриками к базовым оценкам ID Англ. Identifier – идентификатор, уникальный признак объекта, позволяющий отличать его от других объектов, то есть, идентифицировать SLA Англ. Service Level Agreement - утвержденные условия по обработке обращения (заявки) с установленными метриками времени, которые определяют пороговые значения для эскалации в зависимости от статуса обращения (заявки) (например, время реакции – время от регистрации до осуществления первичной обработки, время решения – время от регистрации обращения (заявки) до его решения и т.д.) SQL Англ. Structured Query Language — «язык структурированных запросов», — декларативный язык программирования, применяемый для создания, модификации и управления данными в реляционной базе данных, управляемой соответствующей СУБД

1 Общие сведения 1.1 Полное наименование Услуг Оказание услуг по технической поддержке Модуля СЦ АСУ ТК в 2026 году. 1.2 Предмет Регламента оказания услуг Требования Технического задания

2 Общие положения 2.1 Цель и задачи оказания услуг Целью технической поддержки Системы является обеспечение ее стабильного и безопасного функционирования и эксплуатации, предупреждение, выявление и устранение сбоев в работе Системы и минимизация их неблагоприятного влияния. Для достижения поставленной цели требуется решение следующих задач: 1. Обеспечение информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы. 2. Поддержание параметров функционирования ППО Системы, удовлетворяющих требованиям производственных процессов, включая их непрерывность. 3. Обеспечение бесперебойного функционирования ППО и своевременное устранение сбоев и аварийных ситуаций в Системе. 4. Своевременное устранение уязвимостей при выявлении таковых, в соответствии с требованиями к обеспечению информационной безопасности. 5. Адаптация, конфигурирование, коррекция программного обеспечения в соответствии с изменениями нормативно-правовой базы и запросами уполномоченных сотрудников органов государственной власти, включая выполнение процедур тестирования и участие в обновлениях ППО на стендах Заказчика. 6. Обеспечение сохранения работоспособности ППО в изменяемой среде эксплуатации. 7. Ведение документации по настоящему контракту и инициирование актуализации документации на Систему по результатам обработки запросов Заказчика и внесения соответствующих изменений в ППО

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

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

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

Таблица 1 - Типы обращений (заявок) Тип обращения (заявки) Описание Запрос на обслуживание Подготовка SQL запроса к СУБД для решения прикладной задачи и д р. – запрос на любое действие, не являющееся запросом информации и несовершенный на основе происшествия, прямо или косвенно влияющего на работу Системы Консультация (входит в тип обращения (заявки) «Запрос на обслуживание») «Где взять / куда обратиться...?», «Как сделать / выполнить…», «Как это работает…?» - запрос, имеющий своей целью получение информационной поддержки Инцидент Разбор ошибок/сбоев и подготовка материалов (корректировочных релизов, инструкций) для Заказчика для устранения ошибок/сбоев, которые приводят к частичному и полному нарушению работоспособности всех или отдельных функций ППО. Подготовка изменения и материалов, необходимых для проведения аварийно-восстановительных работ для возобновления работоспособности Системы. ЗНИ Подготовка изменений, связанных с изменением, улучшением/оптимизацией Системы и выводом новой модифицированной функциональности в штатном режиме. Подготовка изменений, связанных с модификацией существующих и/или реализация новых интеграционных механизмов для получения/обработки данных внешних систем. Подготовка изменений графического интерфейса по требованиям Заказчика

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

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

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

- 62.01.11.000 - Этап№8: Опытная эксплуатация (3 очередь) ОКПД2: 62.01.11.000 ОПРЕДЕЛЕНИЯ, ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ Автоматизированная система (АС) Система, состоящая из комплекса средств автоматизации, реализующего информационную технологию выполнения установленных функций, и персонала, обеспечивающего его функционирование (ГОСТ Р 59853-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения») АРМ Автоматизированное рабочее место АСУ ТК, Система Информационно-аналитическая система регулирования на транспорте АТС Автоматическая телефонная станция БД База данных ГИС Государственная информационная система ГОСТ Государственный стандарт ГЦОД СИЦ Минтранса России, ГЦОД Головной центр обработки данных ФГБУ «СИЦ Минтранса России» Дашборд Интерактивная аналитическая панель, графический интерфейс. ЕИС Единая информационная система в сфере закупок ЕСИА Единая система идентификации и аутентификации Заказчик Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» КИИ Критическая информационная инфраструктура Кластер Кла?стер (англ. cluster) – объединение нескольких однородных элементов, которое может рассматриваться как самостоятельная единица, обладающая определёнными свойствами Компонент Часть АС, выделенная по определенному признаку или совокупности признаков и рассматриваемая как единое целое (ГОСТ Р 59853-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения») Контракт Контракт на выполнение работ по развитию и оказанию услуг по технической поддержке Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК в 2026 году, заключаемый по результатам проведения конкурентной процедуры закупки в соответствии с требованиями Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» ... 1. ОБЩИЕ СВЕДЕНИЯ 1.1. Наименование Системы Полное наименование системы: Информационно-аналитическая система регулирования на транспорте. Условное обозначение системы: АСУ ТК. Полное наименование модуля: Модуль сбора, ведения и анализа информации о нештатных ситуациях на транспорте. Условное обозначение модуля: Модуль СЦ. Модуль СЦ создан в рамках контракта от 05.08.2024 № ОК/24_04 на выполнение работ по развитию АСУ ТК в части создания модуля «Сбора, ведения и анализа информации о нештатных ситуациях на транспорте». Развитие Модуля СЦ осуществлено в рамках контракта от 19.05.2025 № ОК/25_09 на выполнение работ по развитию Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК ... 2. ЦЕЛИ И НАЗНАЧЕНИЕ ВЫПОЛНЕНИЯ РАБОТ 2.1. Назначение АСУ ТК АСУ ТК предназначена для автоматизации и информационно-аналитического обеспечения процессов управления развитием транспортного комплекса Российской Федерации, обеспечения публичности деятельности органов государственного управления транспортным комплексом. Основными целями АСУ ТК являются: – повышение эффективности процессов управления функционированием и развитием транспортного комплекса на основе создания единой информационной среды и комплекса информационно-аналитических услуг на уровне органов государственного управления ТК; – повышение уровня безопасности ТК на базе получения полной, достоверной и оперативной информации о происходящих изменениях, своевременного выявления негативных тенденций и для принятия соответствующих мер по их устранению и ликвидации последствий ... - Условная единица - 1,00 - 1 956 154,70 - 1 956 154,70

- Наименование характеристики Значение характеристики Единица измерения характеристики Инструкция по заполнению характеристик в заявке ОПРЕДЕЛЕНИЯ, ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ Автоматизированная система (АС) Система, состоящая из комплекса средств автоматизации, реализующего информационную технологию выполнения установленных функций, и персонала, обеспечивающего его функционирование (ГОСТ Р 59853-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения») АРМ Автоматизированное рабочее место АСУ ТК, Система Информационно-аналитическая система регулирования на транспорте АТС Автоматическая телефонная станция БД База данных ГИС Государственная информационная система ГОСТ Государственный стандарт ГЦОД СИЦ Минтранса России, ГЦОД Головной центр обработки данных ФГБУ «СИЦ Минтранса России» Дашборд Интерактивная аналитическая панель, графический интерфейс. ЕИС Единая информационная система в сфере закупок ЕСИА Единая система идентификации и аутентификации Заказчик Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» КИИ Критическая информационная инфраструктура Кластер Кла?стер (англ. cluster) – объединение нескольких однородных элементов, которое может рассматриваться как самостоятельная единица, обладающая определёнными свойствами Компонент Часть АС, выделенная по определенному признаку или совокупности признаков и рассматриваемая как единое целое (ГОСТ Р 59853-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения») Контракт Контракт на выполнение работ по развитию и оказанию услуг по технической поддержке Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК в 2026 году, заключаемый по результатам проведения конкурентной процедуры закупки в соответствии с требованиями Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» Значение характеристики не может изменяться участником закупки Модуль iМинтранс Модуль сбора данных и представления показателей деятельности Министерства транспорта Российской Федерации iМинтранс АСУ ТК Модуль СЦ Модуль сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК НС Нештатная ситуация НСИ Нормативно-справочная информация ОТИ Объект транспортной инфраструктуры П-ГИС Геоинформационная подсистема П-ИВ Подсистема информационного взаимодействия П-НСИ Подсистема ведения нормативно-справочной информации и метаданных ПО Программное обеспечение Подрядчик, Исполнитель Организация, с которой будет заключен контракт на выполнение работ по развитию Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК П-СД Подсистема сбора данных Работы Работы по развитию Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК СЗИ Средство защиты информации СМЭВ Система межведомственного электронного взаимодействия СУБД Система управления базами данных ТЗ Техническое задание (настоящий документ) ТС Транспортное средство ТК Транспортный комплекс Учреждение Учреждения в области информационной безопасности ФГБУ «СИЦ Минтранса России» Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации», Заказчик Федеральный закон № 44-ФЗ Федеральный закон от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» ФЗ Функциональная задача ФЗ «Реестр объектов» Функциональная задача «Формирование и ведение единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации» ФСБ России Федеральная служба безопасности Российской Федерации ФСТЭК России Федеральная служба по техническому и экспортному контролю ЧС Чрезвычайная ситуация ЭВМ Электронно-вычислительная машина API От англ. Application Programming Interface – интерфейс прикладного программирования – совокупность инструментов и функций в виде интерфейса для взаимодействия с программой CSS От англ. Cascading Style Sheets — каскадные таблицы стилей FPS От англ. frame per second - количество кадров в секунду HTML От англ. HyperText Markup Language - стандартный язык разметки документов, создающий основу и структуру всех веб-страниц JSON От англ. JavaScript Object Notation – текстовый формат обмена данными, основанный на JavaScript WebAssembly (Wasm) Открытый стандарт, представляющий собой низкоуровневый бинарный формат инструкций, который позволяет выполнять код, написанный на языках C++, Rust или Go, в браузерах с производительностью, близкой к нативной 1. ОБЩИЕ СВЕДЕНИЯ 1.1. Наименование Системы Полное наименование системы: Информационно-аналитическая система регулирования на транспорте. Условное обозначение системы: АСУ ТК. Полное наименование модуля: Модуль сбора, ведения и анализа информации о нештатных ситуациях на транспорте. Условное обозначение модуля: Модуль СЦ. Модуль СЦ создан в рамках контракта от 05.08.2024 № ОК/24_04 на выполнение работ по развитию АСУ ТК в части создания модуля «Сбора, ведения и анализа информации о нештатных ситуациях на транспорте». Развитие Модуля СЦ осуществлено в рамках контракта от 19.05.2025 № ОК/25_09 на выполнение работ по развитию Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК Значение характеристики не может изменяться участником закупки 1.2. Шифр темы или номер контракта Присваивается Заказчиком по результатам организации закупочных процедур. 1.2.1. Предмет контракта Выполнение работ по развитию Модуля СЦ. Код по ОКПД2: 62.01.11.000 – услуги по проектированию и разработке информационных технологий для прикладных задач и тестированию программного обеспечения. Оказание услуг по технической поддержке Модуля СЦ. Код по ОКПД2: 62.02.30.000 – услуги по технической поддержке информационных технологий. Выполнение работ по развитию Модуля СЦ предусмотрено с учетом ключевых результатов (ОКР) Ведомственной программы цифровой трансформации Минтранса России на 2026-2028 (далее - ВПЦТ Минтранса России) в составе мероприятия № 103.002 «АСУ ТК» ИТ расхода 103.26.000005 «Развитие Информационно-аналитической системы регулирования на транспорте (АСУ ТК)»: · «Обеспечено информационное взаимодействие с Минобороны о происшествиях на транспортных объектах»; · «Обеспечена автоматизация формирования отчетов о нештатных ситуациях на транспорте, в том числе по данным внешних систем». Выполнение работ по технической поддержке АСУ ТК предусмотрено ВПЦТ Минтранса России в составе мероприятия № 103.002 «АСУ ТК» ИТ расхода 103.26.000021 «Эксплуатация Информационно-аналитической системы регулирования на транспорте (АСУ ТК)» 1.3. Заказчик Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» (ФГБУ «СИЦ Минтранса России»). Адрес: 107078, Москва, Садовая-Спасская ул., д.18, стр. 1. Оператором Системы является Заказчик - Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» (ФГБУ «СИЦ Минтранса России) 1.4. Подрядчик Определяется по результатам проведения конкурентной процедуры закупки в соответствии с требованиями Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (далее – Федеральный закон № 44-ФЗ) 1.5. Основания для выполнения работ Работы осуществляются на основании следующих документов: – постановление Правительства Российской Федерации от 30.12.2003 № 794 «О единой государственной системе предупреждения и ликвидации чрезвычайных ситуаций»; – постановление Правительства Российской Федерации от 08.11.2013 № 1007 «О силах и средствах единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций»; – распоряжение Правительства Российской Федерации от 27.11.2021 № 3363-р «О Транспортной стратегии Российской Федерации до 2030 года с прогнозом на период до 2035 года»; – Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 26.08.2025 №ЕФ-3; – Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 27.11.2025 №ЕФ-23; – Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 19.02.2026 №ЕФ-1; – План мероприятий по профилактике случаев непроизводственного травматизма граждан на железнодорожном транспорте, являющийся приложением к постановлению коллегии Министерства транспорта Российской Федерации от 11.03.2026 № 2 1.6. Перечень документов, требования которых должны быть учтены при выполнении работ – Федеральный закон Российской Федерации от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации»; – Федеральный закон Российской Федерации от 27.07.2006 № 152-ФЗ «О персональных данных»; – Федеральный закон Российской Федерации от 06.04.2011 № 63-ФЗ «Об электронной подписи»; – Федеральный закон Российской Федерации от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации»; – Указ Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации»; – Указ Президента Российской Федерации от 01.05.2022 № 250 «О дополнительных мерах по обеспечению информационной безопасности Российской Федерации»; – Указ Президента Российской Федерации от 31.03.2010 № 403 «О создании комплексной системы обеспечения безопасности населения на транспорте»; – постановление Правительства Российской Федерации от 30.07.2004 № 395 «Об утверждении Положения о Министерстве транспорта Российской Федерации»; – постановление Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации»; – постановление Правительства Российской Федерации от 16.11.2015 № 1236 «Об установлении запрета на допуск программного обеспечения, происходящего из иностранных государств, для целей осуществления закупок для обеспечения государственных и муниципальных нужд»; – постановление Правительства Российской Федерации от 23.12.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 Федерального закона «Об электронной подписи»; – постановление Правительства Российской Федерации от 08.06.2011 № 451 «Об инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг и исполнения государственных и муниципальных функций в электронной форме»; – постановление Правительства Российской Федерации от 30.01.2013 № 62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин»; – приказ ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации»; – приказ ФСТЭК России от 11.04.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений»; – приказ ФСБ России от 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.7. Сроки начала и окончания работ Начало работ: с даты заключения Контракта. Окончание работ: не позднее 15.12.2026. Работы выполняются в соответствии с этапами. Сроки выполнения этапов работ по развитию и технической поддержке Модуля СЦ определяются Календарным планом. Календарный план, приведен в разделе 5 настоящего ТЗ 1.8. Общие сведения об источниках и порядке финансирования работ Источником финансирования являются средства субсидии федерального бюджета Российской Федерации, предоставленной в соответствии с абзацем вторым пункта 1 статьи 78.1 Бюджетного кодекса Российской Федерации (код цели 08-01) 1.9. Порядок оформления и предъявления результатов работ Подрядчик должен передать Заказчику результаты работ в порядке, определенном Контрактом в сроки, установленные п. 5 настоящего ТЗ, в соответствии с Календарным планом 1.10. Место выполнения Работ Работы выполняются удаленно на комплексе технических средств Заказчика. Адрес размещения комплекса технических средств Заказчика: Московская обл., Богородский район, пос. Горбуша, Радиоцентр. Техническая возможность удаленного подключения обеспечивается Заказчиком (в части предоставления параметров доступа). Оплата телематических и иных услуг, технических и программных средств, необходимых Подрядчику для удаленного подключения и для выполнения требований по информационной безопасности, осуществляется Подрядчиком самостоятельно за свой счет 2. ЦЕЛИ И НАЗНАЧЕНИЕ ВЫПОЛНЕНИЯ РАБОТ 2.1. Назначение АСУ ТК АСУ ТК предназначена для автоматизации и информационно-аналитического обеспечения процессов управления развитием транспортного комплекса Российской Федерации, обеспечения публичности деятельности органов государственного управления транспортным комплексом. Основными целями АСУ ТК являются: – повышение эффективности процессов управления функционированием и развитием транспортного комплекса на основе создания единой информационной среды и комплекса информационно-аналитических услуг на уровне органов государственного управления ТК; – повышение уровня безопасности ТК на базе получения полной, достоверной и оперативной информации о происходящих изменениях, своевременного выявления негативных тенденций и для принятия соответствующих мер по их устранению и ликвидации последствий Значение характеристики не может изменяться участником закупки Основными задачами АСУ ТК являются: – автоматизация процессов прогнозирования развития транспортного комплекса и поддержки принятия управленческих решений; – автоматизация процессов мониторинга безопасности и устойчивости транспортного комплекса, управления в чрезвычайных и нештатных ситуациях; – автоматизация процессов управления программами и проектами развития и модернизации транспортного комплекса; – автоматизация процессов мониторинга состояния транспортного комплекса, в том числе с использованием набора ключевых показателей эффективности деятельности транспортного комплекса; – информационно-технологическая поддержка взаимодействия субъектов транспортного комплекса Российской Федерации, органов государственного управления и контроля, международных организаций на основе создания единой технологической среды взаимодействия и управления движением данных (и связанных с ними документов) в транспортном комплексе; – использование в процессах управления транспортным комплексом РФ современных технологий электронного документооборота и электронного обмена данными; – организация межведомственного электронного взаимодействия подразделений Министерства транспорта Российской Федерации, подведомственных агентств и службы с другими организациями 2.2. Назначение и цели развития и технической поддержки Модуля СЦ Назначение Модуля СЦ: – оперативный мониторинг нештатных и чрезвычайных ситуаций на транспорте ; – оповещение заинтересованных лиц и структур о нештатных и чрезвычайных ситуациях; – сбор, обработка и хранение данных о нештатных и чрезвычайных ситуациях. Целями развития Модуля СЦ являются: – расширение состава данных об оперативной обстановке на транспорте; – оптимизация процесса сбора данных об оперативной обстановке на транспорте; – повышение информированности пользователей за счет визуализация данных Модуля СЦ; – автоматизация процесса формирования отчетов о ЧС и нештатной ситуации на транспорте; – обеспечение информационного взаимодействия с заинтересованными организациями по вопросам ведения. Целями оказания услуг по технической поддержке являются: – обеспечение информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы; – поддержание параметров функционирования ППО Системы, удовлетворяющих требованиям производственных процессов, включая их непрерывность; – обеспечение бесперебойного функционирования ППО и своевременное устранение сбоев и аварийных ситуаций в Системе; – своевременное устранение уязвимостей при выявлении таковых, в соответствии с требованиями к обеспечению информационной безопасности; – адаптация, конфигурирование, коррекция программного обеспечения в соответствии с изменениями нормативно-правовой базы и запросами уполномоченных сотрудников органов государственной власти, включая выполнение процедур тестирования и участие в обновлениях ППО на стендах Заказчика; – обеспечение сохранения работоспособности ППО в изменяемой среде эксплуатации; – ведение документации по настоящему ТЗ, инициирование и актуализация документации на Систему по результатам обработки запросов Заказчика и внесении соответствующих изменений в ППО. Модуль СЦ применяется в деятельности Министерства транспорта Российской Федерации, подведомственных агентств и службы и другими организациями в соответствии с соглашениями об информационном обмене 3. ХАРАКТЕРИСТИКА ОБЪЕКТА АВТОМАТИЗАЦИИ 3.1. Описание объекта автоматизации АСУ ТК Объектом автоматизации являются процессы основной и обеспечивающей деятельности, направленные на управление транспортным комплексом, в том числе, процессы информационного взаимодействия с другими организациями и субъектами транспортного комплекса. АСУ ТК относится к государственным информационным системам, а также к информационным системам персональных данных и значимым объектам критической информационной инфраструктуры Российской Федерации. АСУ ТК соответствует требованиям, предъявляемым к: – ГИС второго класса защищенности в соответствии с приказом ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах»; – ИС персональных данных при обеспечении третьего уровня защищенности персональных данных в соответствии с требованиями постановления Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»; – значимым объектам КИИ Российской Федерации второй категории значимости с постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении Правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений». Модуль СЦ является подсистемой АСУ ТК. Перечень платформенных решений и функциональных задач АСУ ТК представлен в Таблице 1 Значение характеристики не может изменяться участником закупки Таблица 1 – Перечень платформенных решений и функциональных задач АСУ ТК № Наименование подсистемы/ функциональной задачи/ модуля Назначение 1 Подсистема сбора данных и централизованного хранилища данных Подсистема обеспечивает выполнение сбора данных в АСУ ТК, и в т. ч., в рамках функциональных задач «Формирование и ведение межрегионального транспортного баланса пассажирских перевозок в дальнем (межрегиональном) сообщении» и «Формирование и ведение транспортного паспорта региона» 2 Подсистема информационного взаимодействия Подсистема информационного предназначена для обеспечения информационного взаимодействия подсистем АСУ ТК, а также, взаимодействия АСУ ТК с АС федеральных органов исполнительной власти 3 Подсистема ведения нормативно-справочной информации и метаданных Подсистема предназначена для автоматизации функций формирования и актуализации справочников, классификаторов, реестров и регистров, необходимых для обеспечения информационной поддержки пользователей НСИ и интеграции подсистем АСУ ТК в части применения НСИ 4 Модуль СМЭВ Модуль взаимодействия со СМЭВ представляет собой набор сервисов взаимодействия: сервис синхронного взаимодействия и сервис отправки, осуществляющих дополнительную обработку сообщений, отправляемых в СМЭВ и принимаемых из СМЭВ 5 Геоинформационная подсистема Программное обеспечение геоинформационной подсистемы предназначено для обеспечения смежных подсистем АСУ ТК возможностью работы с картографической информацией, в том числе, отображения на электронных картах объектов транспортной инфраструктуры и получения информации о местоположении, характеристиках контролируемых транспортных объектов 6 Подсистема информационного портала АСУ ТК Подсистема информационного портала предназначена для отображения и входа в функциональные задачи АСУ ТК 7 Подсистема технического портала АСУ ТК Подсистема технического портала АСУ ТК предназначена для управления заявками пользователей и технологического документооборота заявок 8 Подсистема проектного архива АСУ ТК Подсистема проектного архива АСУ ТК предназначена для автоматизации деловых процессов должностных лиц Министерства транспорта Российской Федерации, подведомственных агентств и службы, в том числе, и процессов информационного взаимодействия внутреннего и внешнего характера 9 ФЗ «Реестр объектов» Функциональная задача предназначена для формирования и ведения единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации 10 ФЗ «СТП» Функциональная задача предназначена для организации информационно-аналитической поддержки процессов территориального планирования Российской Федерации в области федерального транспорта 11 ФЗ «МРТБ ПП» Функциональная задача предназначена для формирования и ведения межрегионального транспортного баланса пассажирских перевозок в дальнем (межрегиональном) сообщении 12 ФЗ «МДД» Функциональная задача предназначена для осуществления мониторинга дорожного движения 13 ФЗ «ТПР» Функциональная задача предназначена для формирования и ведения транспортного паспорта региона 14 ФЗ «Данные по грузообороту» Функциональная задача предназначена для обеспечения подсистем и пользователей АСУ ТК данными по грузообороту между Российской Федерацией и зарубежными странами 15 ФЗ «МЖТ» Функциональная задача предназначена для осуществления мониторинга железнодорожного транспорта 16 ФЗ «МГМП» Функциональная задача предназначена для осуществления мониторинга грузопотоков в морских портах с целью формирования единой цифровой среды мониторинга и планирования перевозок в/из портов Дальнего Востока 17 Модуль ГЭТ Модуль предназначен для получения, хранения данных инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по отдельно взятому предприятию-перевозчику. Формирования отчетов об инвентаризации с детальными данными по каждому разделу инвентаризации с маршрутизацией в муниципалитет / регион / Минтранс. Содержит агрегированные данные инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по всем перевозчикам, относящихся к данному муниципалитету. Формирует сводный отчет по муниципалитету по каждому разделу инвентаризации с маршрутизацией в регион / Минтранс. Формирует агрегированные данные инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по всем перевозчикам, относящиеся к данному региону и по всем муниципалитетам, относящимся к данному региону. Аналитические и статистические данные о состоянии ГЭТ региона. Содержит данные о видах транспорта, цифровых транспортных сервисах и платежных инструментах Региона. Формирует сводный отчет по каждому разделу инвентаризации с маршрутизацией в Минтранс. Формирует агрегированную статистику и аналитику по всем регионам страны в разрезе транспортных средств, маршрутов, пассажиропотоков, инфраструктуры ГЭТ. Данные о рейтинге регионов и перевозчиков на основании выбранных параметров, документооборот с участниками Системы: получение подписанных печатных форм, их утверждение, возврат на доработку. 18 Модуль iМинтранс Модуль создан для отчета по ключевым показателям транспортного комплекса России (Отраслевые и статистические показатели, исполнение бюджета, исполнение поручений, аналитика СМИ, происшествия по видам транспорта). 19 Модуль СЦ Модуль СЦ предназначен для оперативного мониторинга нештатных ситуаций транспортной отрасли, оповещения заинтересованных лиц и структур и предоставления данных о нештатных ситуациях АСУ ТК осуществляет идентификацию и авторизацию посредством Единой системы идентификации и аутентификации (ЕСИА). Информационный обмен с внешними информационными системами осуществляется посредством СМЭВ 3 и СМЭВ 4. АСУ ТК развернута на вычислительных мощностях ГЦОД СИЦ Минтранса России 3.2. Описание и текущее состояние объекта автоматизации Модуля СЦ Объектом автоматизации является процесс организации мониторинга информации о НС и ЧС на транспорте. Предметом деятельности Учреждения являются следующие функции: – информационное обеспечение в области транспортной безопасности, защиты населения и территорий от чрезвычайных ситуаций природного и техногенного характера в транспортном комплексе; – подготовка справочных материалов при угрозе возникновения и возникновении чрезвычайных ситуаций и иных происшествий в транспортном комплексе; – взаимодействие и обмен оперативной информацией с органами управления Единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций; – организация оперативного мониторинга обстановки на объектах транспорта при угрозе и возникновении чрезвычайных ситуаций и иных происшествий. Перечень компонентов Модуля СЦ и выполняемые ими функции представлены в Таблице 2 Таблица 2. Перечень компонентов Модуля СЦ и их функции № п/п Компонент Выполняемые функции 1 Регистрация событий – ведение карточки события; – удаление комментария; – динамическое отображение существующих событий в заданном радиусе и за заданный период; – возможность автоматической проверки вводимых данных в части количества пострадавших; – отображение карточки ОТИ, ТС в соответствии с ФЗ Реестр объектов; – сохранение и отображение версии карточки события; – привязка события к координатам по картографической основе; – указание признака выполнения действия по отработке события; – перевод статуса события; – закрытие карточки события; – публикация информации о событии в канале мессенджера; – возможность перехода из карточки события на картографическую основу для просмотра местоположения события 2 Визуализация – отображение событий на картографической основе в виде пиктограмм; – масштабирование карты; – отображение краткой карточки события при выборе события на картографической основе; – отображение списка событий; – отображение карточки события; – отображение журнала действий пользователя; – отображение дополнительной информации (текстовая информация и приложенные файлы); – отображение справки о событиях и отчета о событиях; – отображение фильтров и количества отфильтрованных объектов; – отображение результатов поиска; – отображение статистики по событиям на экране; – возможность создания события с картографической основы; – отображения картографических слоев в зависимости от примененных фильтров; – возможность настройки шага картографической сети; – возможность настройки географической точки центра карты; – отображение количества непрочитанных сообщений; – возможность перехода к детальной карточке события из краткой карточки события при выборе события на картографической основе 3 Информирование – ведение справочника способов оповещения (веб-интерфейс, мессенджер); – формирование сценария выполнения оповещения (настройка условий, способа, параметров оповещения); – выполнение оповещений пользователей 4 Отчетность – формирование отчета и справки о событиях; – фильтрация событий для выгрузки в справку о событиях или в отчет о событиях 5 Администрирование – ведение ролей пользователей; – ведение учетных данных пользователей; – ведение справочника организаций; – ведение справочника групп системы мгновенного обмена сообщениями; – выполнение исходящего звонка на контактный телефонный номер организации; – формирование матрицы эскалации событий Архитектура Модуля СЦ представлена на рисунке 1. Рисунок 1. Архитектура Модуля СЦ 3.3. Состав используемого ПО Модуля СЦ Программная архитектура Модуля СЦ разработана как трехуровневая клиент-серверная архитектура. Архитектура включает в себя следующие уровни: • уровень представления – презентационный уровень, обеспечивающий взаимодействие с пользователя с клиентскими приложениями с использованием веб-браузера («тонкий» клиент); • уровень приложений – реализован в виде сервисов, обеспечивает обработку запросов, поступающих от клиентских приложений, формирование ответов на запрос в доступном пользователю виде (формирование пользовательских интерфейсов); • уровень хранения данных – реализуется как сервер БД и обеспечивает хранение и целостность хранимых данных, создание резервных копий, ведение журнала транзакций, восстановление данных после сбоев. Программная архитектура Модуля СЦ включает в себя сервисы и интерфейсы, указанные в Таблице 3. Таблица 3. Программная архитектура Модуля СЦ Программный сервис/интерфейс Технологии реализации Уровень представления Интерфейс пользователя и администратора (front-end) Javascript Уровень приложений Сервис (GateWay) Kotlin Сервис геокодирования (geocoding-service) Kotlin Сервис уведомлений (notifiсation-service) Kotlin Сервис работы с файлами (file-service) Kotlin Сервис отчетности (report-service) Kotlin Сервис управления событиями (event-service) Kotlin Сервис информирования через мессенджер (messenger-notifier) Python Сервис внешних интеграций (integration-service) Сбор информации из внешних систем и сервисов Брокер сообщений Kafka Уровень хранения данных Файловое хранилище MinIO S3 СУБД Postgres Pro Enterprise 3.4. Информационное взаимодействие программных сервисов и интерфейсов Модуля СЦ Объект автоматизации функционирует в распределенной информационной среде. Обмен данными осуществляется по защищенным каналам связи (в том числе ведомственным сетям передачи данных). Источники информации включают: · внешние автоматизированные системы (органов государственной власти); · внутренние базы данных (реестры объектов транспортной инфраструктуры, паспорта регионов и пр.); · оперативная информация от персонала, поступающая через автоматизированные рабочие места (АРМ) и мобильные устройства. 3.4.1. Взаимодействие Модуля СЦ со смежными подсистемами АСУ ТК Модуль СЦ входит в состав АСУ ТК и взаимодействует со следующими ее функциональными задачами и подсистемами: · Функциональной задачей «Формирование и ведение единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации» (ФЗ «Реестр объектов»); · Геоинформационной подсистемой АСУ ТК (П-ГИС); · Подсистемой ведения нормативно-справочной информации и метаданных (П-НСИ); · Подсистемой сбора данных и централизованное хранилище данных (П-СД); · Подсистемой информационного взаимодействия (П-ИВ). 3.4.2. Взаимодействие с внешними информационными системами Список внешних информационных систем, с которыми осуществляется взаимодействие Модуля СЦ: · ЕСИА; · мессенджер; · Яндекс Геокодер; · Информационная система «Централизованная система сбора информации систем-112»; · ПВК «Поиск-Море», АИС РПТ; · облачная АТС 3.5. Требования к эксплуатации Применяемое в Системе программное обеспечение, программно-аппаратные и аппаратные комплексы должны соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации» 4. ТРЕБОВАНИЯ К МОДУЛЮ СЦ 4.2.4.1. Требования к технической реализации компонента «Интерактивная карта» При реализации компонента «Интерактивная карта» должны учитываться требования, указанные ниже. 4.2.4.1.1. Требования к отображению элементов Повторяющихся элементы карты (ТС, ОТИ, события и пр.) должны отрисовываться с использованием аппаратного создания экземпляров объектов на пользовательском устройстве (WebGL/WebGPU)). Отрисовка каждого объекта отдельным запросом не допускается, должна обеспечиваться возможность одновременного отображения не менее 5 000 объектов без снижения производительности (30 кадров в секунду на тестовой конфигурации). 4.2.4.1.2. Уровни детализации объектов Для управления отображением сложных объектов должно быть создано не менее 3-х уровней детализации, отображаемых при изменении масштаба с возможностью автоматического переключения между уровнями. Все отображаемые объекты должны масштабироваться с учетом разрешения экрана пользователя с сохранением качества детализации. 4.2.4.1.3. Полигональная оптимизация и текстурирование При реализации компонента «Интерактивная карта» должна обеспечиваться технология рельефного тестурирования объектов. Не должны использоваться высокополигональные трехмерные модели. Все повторяющиеся элементы должны генерироваться единоразово и повторно использоваться при последующих отображениях. 4.2.4.1.4. Управление памятью Требуется реализовать потоковую загрузку на устройство пользователя элементов карты и текстур. Загрузка данных целиком при старте приложения не допускается. Необходимо реализовать механизм очистки памяти от элементов, которые находятся вне области видимости камеры в течение заданного времени. 4.2.4.1.5. Требования к взаимодействию пользователя с интерфейсом компонента «Интерактивная карта» Программная реализация механизмов управление камерой (масштабирование и навигация) должна быть выполнена с поддержкой технологии WebAssembly (WASM). Элементы управления должны являться неотъемлемой частью интерактивной карты. Значение характеристики не может изменяться участником закупки 4.2.5. Развитие компонента администрирования (3 очередь) Должна быть выполнена доработка ролевой модели. Ролевая модель должна обеспечивать управление доступом к отдельным объектам Модуля СЦ и их элементам (атрибутам) с разграничением по видам транспорта, регионам и пр., в частности: – определение набора конкретных действий, доступных пользователям (выполняемых над объектом доступа, например, удаление записи, редактирование записи, формирование отчета и др.); – реализация возможности объединения пользователей в группы; – определение прав доступа для групп пользователей; – реализация интерфейса визуальной настройки прав доступа пользователей к объектам Модуля СЦ Технические меры по обеспечению надежности должны предусматривать: – резервирование критически важных компонентов и данных Системы и отсутствие единой точки отказа; – использование программного резервирования (программной избыточности); – изменение конфигурации используемых средств и применение специализированного ПО, обеспечивающего высокую надёжность. Организационные меры по обеспечению надежности должны быть направлены на минимизацию ошибок пользователей (а также обслуживающего персонала при эксплуатации и проведении работ по обслуживанию), минимизацию времени ремонта или замены вышедших из строя компонентов за счёт: – обеспечения для обслуживающего персонала требуемого уровня квалификации; – регламентации и нормативного обеспечения выполнения работ обслуживающим персоналом; – своевременной диагностики неисправностей. Расчетное значение коэффициента доступности Модуля СЦ должно составлять не менее 0,95. 4.5.3. Требования по диагностированию Модуля СЦ Диагностирование Модуля СЦ должно осуществляться путем анализа записей в системных журналах СУБД, операционных систем серверов, а также с помощью встроенных средств диагностирования общего программного обеспечения Модуля СЦ. Диагностированию подлежат: – сбои и нарушения функционирования технического обеспечения (серверов) Модуля СЦ; – сбои и нарушения функционирования системного программного обеспечения серверов, используемых для работы Модуля СЦ; – сбои и нарушения функционирования прикладного программного обеспечения серверов, используемых для работы Модуля СЦ; – случаи недоступности (отсутствия ответа) или некорректные ответы внешних систем; – сбои и нарушения функционирования СУБД; – сбои при выполнении регламентных операций резервного копирования. При возникновении аварийных ситуаций либо ошибок в программном обеспечении диагностические инструменты должны позволять сохранять набор информации, необходимой для идентификации и устранения проблемы. Модуль СЦ и ее компоненты должны обеспечивать возможность диагностики своей работоспособности с возможностью интеграции с модулем мониторинга АСУ ТК. Набор передаваемых журналов и метрик должен быть определен на этапе технического проектирования 4.5.4. Требования к надежности Должно быть предусмотрено сохранение работоспособности Модуля СЦ при некорректных действиях пользователя и сохранение целостности данных при нештатном завершении работы Модуля СЦ (отказ рабочей станции, потеря сетевого доступа и т.п.). Модуль СЦ должен предоставлять механизмы обеспечения сохранности данных через применение процедур резервного копирования и восстановления, описанных в документации на Систему. Ключевые показатели надежности информационной системы — допустимое время на восстановление работоспособности Модуля СЦ (RTO - recovery time objective) и/или допустимый интервал времени потери изменений в данных при сбоях/отказах (RPO – recovery point objective) должны быть определены Подрядчиком и согласованы с Заказчиком на этапе технического проектирования 4.2.6. Взаимосвязи с внешними автоматизированными системами (1 очередь) Способы взаимодействия с внешними информационными системами должны быть определены на этапе технического проектирования. Должны быть выполнены следующие доработки: – интеграции с информационными ресурсами в целях получения данных о движении подвижных ТС (воздушные суда, суда водного транспорта); – интеграция с информационным ресурсом в целях получения данных о событиях на железнодорожном транспорте. Реализация интеграций должна включать проектирование и реализацию интеграционных механизмов обмена данными с учетом доступных вариантов реализации, обеспечение защищенных способов взаимодействия, настройку отображения отдельных данных на карте (настройка слоев). Взаимодействия, имеющие каналы связи, выходящие за пределы контролируемой зоны взаимодействующих систем, считаются защищенными, если для их защиты используются программные и/или программно-аппаратные шифровальные (криптографические) средства, сертифицированные ФСБ России (далее – СКЗИ). Выбор СКЗИ, схемы подключения и требуемого класса криптостойкости должен производиться в соответствии с Техническими условиями на подключение к информационным ресурсам ФГБУ «СИЦ Минтранса России» и инструкциями по подключению пользователей к ресурсам инфраструктуры Головного центра обработки данных, утвержденных приказом директора ФБГУ «СИЦ Минтранса России» от 24.05.2024 № 21-ОД 4.3. Требования к оказанию услуг по технической поддержке Модуля СЦ 4.3.1. Общие требования к оказанию Услуг Техническая поддержка Модуля СЦ должна осуществляться с учетом требований постановления Правительства Российской Федерации от 06.07.2015 N 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации». Подрядчик обязан выполнять требования законодательства в сфере защиты информации, требования по защите информации, информационной безопасности, указанные в локальных нормативных актах ФГБУ «СИЦ Минтранса России», регламентирующих условия информационного взаимодействия, защиты информации и подключения к информационным ресурсам ФГБУ «СИЦ Минтранса России», участвующих в информационном взаимодействии в рамках оказания услуг по технической поддержке АСУ ТК в 2026 году 4.3.1.1. Требования к составу и содержанию услуг третьего уровня технической поддержки Оказание услуг по технической поддержке Системы осуществляется в рамках этапов в соответствии с календарным планом. Подрядчик в течение 5 рабочих дней с даты заключения Контракта должен предоставить со своей стороны, а Заказчик со своей стороны Матрицу ответственных за взаимодействия в соответствии с Приложением 1 к Регламенту оказания услуг по третьему уровню технической поддержки Модуля СЦ (далее – Регламент, Приложение В). Подрядчик в течение 10 рабочих дней с даты заключения Контракта должен провести мероприятия по организации третьего уровня технической поддержки в соответствии с Регламентом. Услуги по третьему уровню технической поддержки Модуля СЦ должны включать: – организацию Подрядчиком третьего уровня технической поддержки; – информационно-консультационную поддержку работников Заказчика; – решение инцидентов, связанных с работой ППО; – адаптационное, конфигурационное и коррекционное сопровождение Модуля СЦ (в рамках действующих программных модулей и функциональности); – устранение уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности 4.5.5. Требования к информационной безопасности Работы по защите информации/информационной безопасности, не включенные в состав настоящего раздела, требуемые в соответствии с требованиями постановления Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации», а также нормативно правовых актов в области защиты персональных данных и обеспечения безопасности объектов критической информационной инфраструктуры, будут проведены в рамках исполнения отдельного контракта, заключенного по результатам отдельной закупочной процедуры (не является частью данного ТЗ), включающего: – определение актуальных угроз безопасности информации и актуализация модели угроз безопасности информации (при необходимости); – выполнение требований о согласовании технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России в установленном порядке; – выполнение требований по устранению Подрядчиком замечаний и недостатков, в случае их выявления при согласовании Заказчиком технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России; – выполнение требований к классу защищенности ГИС, уровню защищенности персональных данных и категории значимости объекта КИИ РФ, установленных для Головного центра обработки данных ФГБУ «СИЦ Минтранса России» (далее – ГЦОД); – определение перечня объектов защиты информационной системы; – описание (актуализированных) требований к системе защиты информации, а также к мерам защиты информации информационной системы в зависимости от установленных классов защищенности, уровня защищенности персональных данных и категории значимости объектов КИИ РФ (приказы ФСТЭК России № 21, 117, 239); – выполнение требований к мерам по защите ГИС от атак, направленных на отказ в обслуживании, в соответствии с пунктами 30, 34, 59, 63 Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений, утвержденных приказом ФСТЭК России от 11.04.2025 № 117; – описание (актуализированных) требований по защите информации, подлежащих реализации в информационно телекоммуникационной инфраструктуре ГЦОД; – выполнение требований о применении сертифицированных средств защиты информации, включая их классы защиты и уровни доверия; – выполнение требований о запрете использования с 01.01.2025 органами (организациями) средств защиты информации странами происхождения, которых являются иностранные государства в соответствии с пунктом 6 Указа Президента Российской Федерации от 01.05.2022 № 250; – выполнение требований по обеспечению непрерывного взаимодействия с ГосСОПКА в установленном порядке; 4.3.1.2. Требования к общему порядку оказания услуг Техническая поддержка Модуля СЦ должна быть организована на трех уровнях: – первый и второй уровни технической поддержки организуется Заказчиком; – третий уровень технической поддержки организуется Подрядчиком. Перечень действий на каждом уровне технической поддержки указан в Таблице 5: Таблица 5 – Перечень действий на каждом уровне технической поддержки Уровень технической поддержки Доступные действия Условия передачи задачи на следующий уровень Первый уровень технической поддержки (далее – 1-й уровень) – принимает обращения (заявки) пользователей Модуля СЦ и работников Заказчика; – регистрирует обращения в Модуле СЦ регистрации обращений; – присваивает уникальный идентификационный номер, классифицирует обращения; – самостоятельно решает обращения, которые связаны с недостаточной квалификацией пользователей или настройками в рамках своей компетенции; – взаимодействует с пользователями Модуля СЦ при решении проблемы Передает обращение на второй уровень поддержки в случае невозможности решения на своем уровне Второй уровень технической поддержки (далее – 2-й уровень) – принимает обращения от 1-го уровня; – уточняет классификацию обращения в результате дополнительного анализа; – самостоятельно решает обращения в рамках своей компетенции; – осуществляет техническую и консультационную поддержку Модуля СЦ; – взаимодействует с сотрудниками 1-го и 3-го уровня и пользователями Модуля СЦ; – формирует заявки для 3-го уровня и контролирует исполнение Передает обращение на третий уровень поддержки в случае невозможности решения на своем уровне Третий уровень технической поддержки (далее – 3-й уровень) – принимает обращения от 2-го уровня; – обеспечивает выполнение требований, предъявляемых Контрактом и настоящим Техническим заданием к Услугам, оказываемым Подрядчиком Все поступающие обращения должны быть исполнены Подрядчиком Для обеспечения взаимодействия с Заказчиком Подрядчик со своей стороны определяет ответственных лиц, уполномоченных в структуре Подрядчика за своевременное и качественное оказание Услуг в рамках настоящего ТЗ, а также контактную информацию ответственных лиц (телефон, электронную почту). Подрядчик должен предоставить Заказчику единый адрес электронной почты для приема обращений (заявок) в течение 3 (трех) рабочих дней после заключения Контракта. Указанный в настоящем пункте адрес электронной почты (способ направления обращений (заявок) применяется в случае сбоя в работе СРО Заказчика. Со своей стороны, Заказчик предоставляет Подрядчику перечень и контактную информацию (телефон, электронную почту) уполномоченных лиц для осуществления взаимодействия с указанием зон ответственности. О любых изменениях в контактной информации ответственных лиц Стороны должны уведомить друг друга в течение 1 (одного) рабочего дня с момента возникновения таких изменений посредством уведомления на электронную почту ответственных лиц и/или в письменной форме. В результате оказания услуг по настоящему ТЗ не должны быть изменены исходные коды, дистрибутивы и иные компоненты Модуля СЦ вне согласованных с Заказчиком изменений. Любые изменения исходных кодов, дистрибутивов и иных компонентов Модуля СЦ должны производиться только после согласования с Заказчиком уполномоченными лицами по электронной почте или иным заранее согласованным способом. Не должна быть ухудшена надежность и производительность Модуля СЦ. Оказание услуг по Контракту не должно нарушать требования к информационной безопасности, описанной в документации на Модуль СЦ – выполнение требований по обеспечению в автоматизированном режиме с Национальной системой противодействия DDoS-атакам (НСПА) Центра мониторинга и управления сетью связи общего пользования ФГУП «ГРЧЦ» в рамках реализации мер по защите ГИС от атак, направленных на отказ в обслуживании; – детализированные требования к составу и содержанию работ по аттестации, а также к их результатам в соответствии с пунктами 13, 15 и 16 требований приказа ФСТЭК России от 29.04.2021 № 77 «Об утверждении Порядка организации и проведения работ по аттестации объектов информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну» 4.5.5.1. Требования к безопасности исходного кода Процесс разработки исходного кода должен соответствовать требованиям законодательства, нормативным правовым актам Российской Федерации, приказу ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по безопасности значимых объектов критической информационной инфраструктуры Российской Федерации», а также учитывать отраслевые практики безопасной разработки. Подрядчик должен предоставить Заказчику Руководство по безопасной разработке программного обеспечения (далее – Руководство), применяемое при разработке исходного кода Модуля СЦ. Руководство должно содержать: · описание процесса безопасной разработки и ролевой модели, отражающей зоны ответственности сотрудников Подрядчика; · описание процессов моделирования, оценки и формирования мер предотвращения угроз, применяемых Подрядчиком; · описание методик, применяемых Подрядчиком при разработке исходного кода (правила написания кода); · описание методик, периодичности проведения и инструментария статического, динамического, композитного и фаззинг тестирования исходного кода, включающего критерии отбора релизных версий ПО, применяемые Подрядчиком в процессе разработки; · описание механизмов безопасности в процессе сборки и доставки (безопасность образов, безопасность секретов, безопасность окружения и сборочной среды), применяемые Подрядчиком; · утвержденные шаблоны отчетной документации (в том числе акты), в соответствии с которыми Заказчик принимает результаты проверок (артефакты сборочного процесса), проведенных Подрядчиком; · описание процедур отслеживания и исправления обнаруженных ошибок и уязвимостей программного обеспечения; · описание способов и сроков доведения Подрядчиком до Заказчика информации об уязвимостях программного обеспечения, о компенсирующих мерах по защите информации или ограничениях по применению программного обеспечения, способов получения пользователями программного обеспечения его обновлений, проверки их целостности и подлинности Подрядчик должен обеспечить реализацию и проведение внутренних проверок мер по разработке безопасного ПО, приведенных в Руководстве. Подрядчик должен провести анализ угроз безопасности информации программного обеспечения в соответствии с ГОСТ 58412-2019 «Защита информации. Разработка безопасного программного обеспечения. Угрозы безопасности информации при разработке программного обеспечения». Подрядчик должен провести испытания по выявлению уязвимостей в программном обеспечении Системы: · проведение статического анализа исходного кода программы; · проведение динамического анализа исходного кода программы; · проведение композитного анализа исходного кода и образов программы; · проведение фаззинг-тестирования программы, направленного на выявление в ней уязвимостей. Испытания по выявлению уязвимостей в программном обеспечении Системы должны быть проведены в рамках: · предварительных испытаний; · опытной эксплуатации; · приемочных испытаний Оказание услуг в рамках данного технического задания осуществляется Подрядчиком по обращению (заявке) Заказчика, направляемой посредством СРО Заказчика. Регистрация обращений, поступивших непосредственно в Модуль СЦ регистрации обращений Заказчика, производится сотрудниками Заказчика, которые обеспечивают первый уровень технической поддержки Модуля СЦ. В случае назначения приоритета «Критический» или «Высокий», информация о назначении также дублируется оповещением ответственных представителей Подрядчика посредством звонка на предоставленные номера телефонов. Обращение (заявка) должна содержать следующую информацию: – контакты пользователя/организации; – приоритет обращения, соответствующий Приложению 2 к Регламенту; – время обнаружения; – наименование компонента АСУ ТК - Модуль СЦ; Информация может быть расширена по согласованию с Заказчиком. Обращения (заявки) сотрудников Заказчика должны приниматься Подрядчиком через веб-интерфейс СРО. В процессе обработки обращений (заявок) Подрядчик должен обеспечить выполнение следующих процедур: – прием обращений(заявок) от сотрудников Заказчика; – оказание информационно-консультационной поддержки в соответствии с требованиями настоящего Технического задания; – информирование сотрудников Заказчика о статусе обработки и результатах обработки обращений(заявок). Подрядчик осуществляет обязательную регистрацию и учет всех обращений и заявок, поступивших к Подрядчику от представителей Заказчика в рамках оказания настоящих услуг Примечание: в случае приостановки работы по обращению или заявке (обращение или заявка находится в статусе «Приостановлено»), указываются причины, по которым работы по обращению или заявке приостановлены с указанием перечня действий/информации, запрошенных у инициатора обращения, а также даты, формы и адресата такого запроса. В случае отклонения обращения или заявки (заполняется в случае, если обращению или заявке присваивается статус «Отклонено»), указываются подробно причины такого отклонения, а также фиксируется дата и время перехода в статус «Отклонено». В случае, если обращение или заявка отклонены (отменены) самим Инициатором, то указывается дата и способ, которым от инициатора получено соответствующее уведомление. В случае невыполнения Подрядчиком регламентного времени реагирования или решения обращения (заявки) Заказчик вправе отозвать обращение и направить его Подрядчику повторно. При этом каждое отозванное обращение учитывается в Отчёте об оказанных услугах, как обращение с превышением времени реагирования или решения, но оплате не подлежит. В случае, если обращение (заявка) связано с некачественным выполнением Подрядчиком другой задачи, такое обращение решается в регламентное время, установленное Техническим заданием, при этом оплате такие обращения не подлежат, о чем указывается в Отчете об оказанных услугах в графе «Примечание» По результатам анализа угроз безопасности информации программного обеспечения и испытаний по выявлению уязвимостей в программном обеспечении Системы должна быть предоставлена отчетная документация по формам, утвержденным в Руководстве, и артефакты сборочной среды, подтверждающие проведение испытаний по выявлению уязвимостей в программном обеспечении Систем. Уязвимости подлежат устранению в сроки, обозначенные Заказчиком. В случае обнаружения уязвимого компонента Подрядчик должен заменить/обновить библиотеки. В случае, если уязвимость не подлежит исправлению на программном уровне, Подрядчик должен разработать меры предотвращения угроз безопасности, в том числе правила безопасности для наложенных средств защиты, рекомендации по безопасной настройке конфигурации для устранения потенциальных уязвимостей и снижения рисков информационной безопасности. Уязвимости, найденные ФСБ России, ФСТЭК России, Минцифры России, Роскомнадзором в ходе исполнения Контракта, а также в течение гарантийного периода, должны быть устранены Подрядчиком за свой счет в сроки, согласованные с Заказчиком 4.5.6. Требования к эргономике и технической эстетике Взаимодействие пользователей с Модулем СЦ должно осуществляться посредством визуального графического интерфейса. Ввод-вывод данных, прием управляющих команд и отображение результатов их исполнения должны выполняться в интерактивном режиме. Интерфейс должен быть рассчитан на преимущественное использование манипулятора типа «мышь», то есть управление Модулем СЦ должно осуществляться с помощью набора экранных меню, кнопок, значков и т. п. элементов. Клавиатурный режим ввода должен использоваться главным образом при заполнении и/или редактировании текстовых и числовых полей экранных форм. Все надписи экранных форм, а также сообщения, выдаваемые пользователю (кроме системных сообщений), должны быть на русском языке. Модуль СЦ должен обеспечивать проверку вводимых пользователем данных и предупреждать о некорректно введённых значениях Экранные формы должны проектироваться с учетом требований унификации: – все экранные формы пользовательского интерфейса должны быть выполнены в едином графическом дизайне, с одинаковым расположением основных элементов управления и навигации; – для обозначения сходных операций должны использоваться сходные графические элементы, кнопки и другие управляющие (навигационные) элементы. Термины, используемые для обозначения типовых операций, а также последовательности действий пользователя при их выполнении должны быть унифицированы; – внешнее поведение сходных элементов интерфейса (реакция на наведение указателя «мыши», переключение фокуса, нажатие кнопки) должно реализовываться одинаково. Структура размещения информации и представление этой структуры в Модуле СЦ должны соответствовать следующим требованиям: – пункты меню в пользовательском веб-интерфейсе должны быть сгруппированы в соответствии с тематикой информации, функциональными задачами и технологией работы; – каждому пункту меню должна соответствовать только одна выполняемая функция; – при совершении пользователями ошибочных действий должны выдаваться сообщения об ошибках. Эскизы визуального оформления компонента «Интерактивная карта» представлены в Приложении А. 4.3.1.3. Требования к регламенту оказания услуг Подрядчик должен руководствоваться Регламентом оказания услуг по технической поддержке Модуля СЦ. Регламент оказания услуг содержит следующую информацию: – порядок оказания услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Модуля СЦ; – порядок оказания услуги по решению инцидентов, связанных с работой ППО; – порядок оказания услуги адаптационного, конфигурационного и коррекционного сопровождения Модуля СЦ (в рамках действующих программных модулей и функциональностей); – порядок оказания услуги по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности. – Регламент содержит следующие формы заявок на оказание услуг: – форма заявки на оказание услуги по информационно-консультационной поддержке сотрудников Заказчика; – форма заявки на оказание услуги по решению инцидентов, связанных с работой ППО; – форма заявки на оказание услуг адаптационного, конфигурационного и коррекционного сопровождения Модуля СЦ (в рамках действующих программных модулей и функциональностей) (приоритет заявки определяется Заказчиком); – форма заявки на оказание услуги по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности 4.3.2. Требования к режиму обеспечения функционирования Модуля СЦ Режим оказания услуг определен в Приложении Б к настоящему ТЗ. По согласованию с Заказчиком, в целях недопущения остановки функционирования Модуля СЦ в период интенсивной работы пользователей в Модуле СЦ, отдельные услуги могут оказываться по специальному графику (в нерабочее время Подрядчика) в соответствии с заявками Заказчика 4.3.3. Требования к качеству оказываемых услуг Качество оказываемых услуг поддерживается Подрядчиком в соответствии с определяемыми данным ТЗ условиями и правилами и контролируется Заказчиком на постоянной основе, в том числе по соблюдению сроков исполнения и подтверждениям исполнения от инициаторов обращений и другим параметрам. По результатам выполнения работ по устранению инцидента должна быть устранена корневая причина инцидента с окончательным решением, устраняющим причину возникновения проблемы и исключающим вероятность повторного возникновения проблемы (инцидента). Время устранения корневых причин проблемы (инцидента) не должно составлять более 40 рабочих часов 4.5.7. Требования по сохранности информации при авариях В случае возникновения аварии или сбоя в процессе выполнения пользовательских задач должно быть обеспечено восстановление баз данных до состояния на момент последней завершенной Модулем СЦ транзакции, и структуры файлового хранилища. Все аварийные ситуации должны обрабатываться программно с выдачей соответствующих сообщений, с корректной обработкой ситуации (завершение транзакций, закрытие файлов и т.п.), без потери обрабатываемой информации. В Модуле СЦ должны быть предусмотрены меры, обеспечивающие целостность данных в случае отказа программного обеспечения или аппаратных средств, исключая случаи физического уничтожения носителя или нарушения функциональности носителя, операционной системы или СУБД по вине их производителя либо обслуживающего персонала. Используемые аппаратные и системные платформы должны обеспечивать сохранность и целостность информации в Модуле СЦ при полном или частичном отключении электропитания, аварии сетей телекоммуникации, полном или частичном отказе технических средств Модуля СЦ. Технические решения должны обеспечивать сохранность информации в случае возникновения следующих событий (аварий, отказов и т.п.): – отказ аппаратного обеспечения на сервере; – отключение питания на сервере; – отказ аппаратного обеспечения на рабочей станции; – отключение питания на рабочей станции администратора; – отказ линий связи, в том числе при осуществлении обмена данными 4.5.8. Требования к защите от влияния внешних воздействий Требования к защите от влияния внешних воздействий не предъявляются 4.5.9. Требования к патентной чистоте и патентоспособности 4.5.9.1. Исключительные права на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, базы данных, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, принадлежат Российской Федерации в лице Заказчика. Право собственности на результаты работ, отчетные документы и материалы, полученные в ходе выполнения работ по Контракту, принадлежат Российской Федерации в лице Заказчика и считаются переданными с момента подписания Сторонами Акта сдачи-приемки выполненных работ. Разработанное программное обеспечение поставляется вместе с исходными кодами. 4.5.9.2. Все проектные и технические решения должны отвечать требованиям четвертой части Гражданского кодекса Российской Федерации. Результаты Работ должны быть свободными от возможности предъявления любых прав и притязаний третьих лиц, основанных на промышленной, интеллектуальной или другой собственности. 4.5.9.3 Результаты выполненных Работ не должны повлечь необходимость осуществления Заказчиком закупок программного обеспечения (как исключительных, так и неисключительных прав) для обеспечения функциональности Системы в соответствии с Техническим заданием. При выполнении работ Подрядчик должен использовать только объекты интеллектуальной собственности, права на которые приобретены (получены) и используются без нарушений прав на интеллектуальную собственность третьих лиц или предоставлены Заказчиком 4.3.4. Требования к документированию результатов оказываемых услуг Для обеспечения контроля оказываемых услуг по поддержке Модуля СЦ со стороны Заказчика, по окончании каждого отчетного периода по контракту в соответствии с календарным планом, Подрядчик обязан предоставить Заказчику Отчет об оказанных услугах. Отчет должен содержать детальную информацию об оказанных услугах с указанием даты выполненных мероприятий и приложением обосновывающих документов (заявок, запросов, требований) или ссылкой на такие документы, если они содержатся в Модуле СЦ. Информация о выполненных мероприятиях по заявкам должна быть сформирована на основании соответствующих записей СРО по каждому этапу исполнения Контракта. В случае оказания услуги адаптационного, конфигурационного и коррекционного сопровождения Модуля СЦ, должны быть предоставлены документы, подтверждающие выполнение требований п. 29.3 приказа ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации». Фактическое время реагирования и время решения по всем обращениям, поступившим в СРО, формируется в СРО по итогам отчетного периода в разделе «Отчеты». Фактическое время реагирования и время решения по обращениям учитывает суммарное время, затраченное на реагирование и, соответственно, на работу по обращению с момента назначения обращения специалисту Подрядчика или группе исполнителей, ответственным за оказание услуг технической поддержки 3 уровня от начала до завершения работ Подрядчиком. При этом принимается суммарное время нахождения заявки в соответствующих статусах заявки СРО на стороне Подрядчика 4.3.5. Требования к классификации обращений и заявок Обращения и заявки Заказчика классифицируются в соответствии с приоритетами и регламентными сроками, указанными в Приложении 2 к Регламенту. Регистрация обращений и заявок предусматривает создание новой записи в СРО с присвоением поступившему обращению или заявке (новой записи) уникального идентификатора. Запись в СРО должна содержать вопрос или проблему, которую требуется решить или оказать консультацию. Состав обязательной информации, которую должно содержать обращение или заявка, зафиксирован в Регламенте оказания Услуг. Если обращение или заявка автоматически зарегистрированы в СРО при отправке представителем Заказчика, Подрядчик проверяет корректность классификации обращения или заявки и может обратиться к Заказчику с просьбой корректировки, предоставив обоснования в соответствии с настоящей классификацией (Таблица 6) 4.5.9.4. Подрядчик подтверждает, что обладает всеми правами на передачу Заказчику исключительных прав в соответствии с требованиями настоящего раздела Технического задания. В случае, если к Заказчику по вине Подрядчика будут предъявлены претензии в этой части, иски третьих лиц, связанные с нарушением их прав, Подрядчик принимает на себя такие претензии и иски и возмещает Заказчику все расходы и весь ущерб, понесенный в связи с ними. 4.5.9.5. Подрядчик обязан согласовать с Заказчиком необходимость использования при выполнении работ охраняемых результатов интеллектуальной деятельности, права на которые принадлежат Подрядчику или третьим лицам. 4.5.9.6. В случае, если при выполнении Работ используется готовое программное обеспечение (платформа, подсистема, СУБД и т.д.), которое становится частью (компонентом) Системы, Заказчику передаются полные исключительные права, или неисключительные права (путем заключения лицензионного/сублицензионного договора/соглашения) на такое программное обеспечение со следующими возможностями: – права передаются бессрочно (на весь срок действия исключительных прав); – территория действия Российская Федерация; – должно быть обеспечено право Российской Федерации (в лице Заказчика) передавать, дорабатывать, распространять, развивать результаты работ, созданные в процессе исполнения Контракта, а также перерабатывать такое программное обеспечение. Лицензионное (сублицензионное) соглашение (договор), Акт передачи прав, подписанные Подрядчиком, согласие правообладателя, оформленное в соответствии с положениями Гражданского кодекса Российской Федерации (в случае, если Подрядчик не является правообладателем такого программного обеспечения), инструкция по инсталляции, руководство администратора, руководство пользователя передаются Заказчику в сроки, установленные Техническим заданием для соответствующего функционала Системы Лицензионное (сублицензионное) соглашение (договор) не может возлагать на Заказчика какие-либо обязанности (в т.ч. в части конфиденциальности, предоставления отчетности), не предусмотренные Контрактом. 4.5.9.7. Передача Заказчику исключительных прав, или простых (неисключительных) прав не может повлечь увеличение стоимости Контракта и/или изменение иных существенных условий Контракта. 4.5.9.8. Функциональность Модуля СЦ передается в объеме и в сроки, установленные Техническим заданием. 4.5.9.9. Нарушение условий настоящего раздела Технического задания, в т.ч. отсутствие соответствующего лицензионного (сублицензионного) соглашения (или договора), либо предоставление лицензионного (сублицензионного) соглашения (или договора), не соответствующего требованиям действующего законодательства Российской Федерации или требованиям Контракта, является нарушением существенных условий Контракта. 4.5.9.10. В случае, если в соответствии с пунктом 4.5.9.6 Заказчику передается исключительное право, такая передача осуществляется в порядке, установленном Гражданским кодексом Российской Федерации. 4.5.9.11. В случае, если при выполнении Работ положения пунктов 4.5.9.5-4.5.9.6 не применялись, Подрядчик в составе отчетной документации предоставляет об этом декларацию в свободной форме. Декларация должна содержать сведения о полном соответствии результата Работ требованиям Контракта, а также о неприменении при выполнении работ готового программного обеспечения (платформ, подсистем, СУБД и т.д.), которое стало частью (компонентом) Системы Таблица 6. Категории обращений и заявок Категория Примеры Запрос на обслуживание Подготовка SQL запроса к СУБД для решения прикладной задачи и д.р. – запрос на любое действие, не являющееся запросом информации и несовершенный на основе происшествия, прямо или косвенно влияющего на работу Модуля СЦ Консультация «Где взять / куда обратиться...?», «Как сделать / выполнить…», «Как это работает…?» - запрос, имеющий своей целью получение информационной поддержки Инцидент Разбор ошибок/сбоев и подготовка материалов (корректировочных релизов, инструкций) для Заказчика для устранения ошибок/сбоев, которые приводят к частичному и полному нарушению работоспособности всех или отдельных функций ППО. Подготовка изменения и материалов, необходимых для проведения аварийно-восстановительных работ для возобновления работоспособности Модуля СЦ ЗНИ Подготовка изменений, связанных с изменением, улучшением/оптимизацией Модуля СЦ и выводом новой модифицированной функциональности в штатном режиме. Подготовка изменений, связанных с модификацией существующих и/или реализация новых интеграционных механизмов для получения/обработки данных внешних систем. Подготовка изменений графического интерфейса по требованиям Заказчика. Перечень статусов обращений (заявок) приведен в пункте 3.3. Регламента оказания Услуг. Назначение обращению (заявке) статуса «Закрыто» осуществляется Заказчиком только после получения от инициатора обращения (заявки) подтверждения о его исполнении или нахождения обращения (заявки) в статусе «Выполнено» и отсутствия повторных вопросов/запросов по данному обращению (заявки) в течение 5 рабочих дней. Категории и статусы обращений (заявок) могут быть скорректированы в процессе оказания услуг исключительно по согласованию с Заказчиком 4.3.6. Требования к услугам технической поддержки 4.3.6.1. Требования к организации третьего уровня технической поддержки Основными задачами организации третьего уровня технической поддержки в рамках оказания услуг по технической поддержке Модуля СЦ являются организация эксплуатационной службы Подрядчика, проверка готовности технических и программных средств для обеспечения непрерывного функционирования ППО Модуля СЦ. Подрядчиком должны быть проведены организационно-штатные и подготовительные мероприятия (в т. ч. технические) в рамках организации технической поддержки Модуля СЦ. Подрядчик в течение 5 (пяти) рабочих дней с даты заключения Контракта должен: – определить и направить Заказчику документ «Перечень уполномоченных специалистов», содержащий контактную информацию (ФИО, должность, адрес рабочей электронной почты) лиц, ответственных за оказание услуг со стороны Подрядчика; – обеспечить подключение специалистов Подрядчика к Системе регистрации обращений (заявок) (СРО предоставляется Заказчиком) для оказания услуг; – согласовать с Заказчиком способ доступа Подрядчика к Модулю СЦ. Результат выполнения мероприятий фиксируется в Протоколе проверки результатов организационно-штатных и подготовительных мероприятий (см. Приложение Д к настоящему ТЗ) 4.5.9.12. Передача Заказчику комплекта документов, материалов и сведений, предусмотренных нормативными правовыми актами Российской Федерации в сфере информационных технологий, защиты информации, правовой защиты интересов государства в области интеллектуальной собственности, включая документы, подтверждающие отказ авторов (разработчиков) от исключительных прав на передаваемые объекты интеллектуальной собственности в пользу Подрядчика, с проектами заявок на государственную регистрацию в установленном порядке прав Заказчика на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, базы данных, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, осуществляется Подрядчиком в составе отчетной документации, предусмотренной условиями Контракта. 4.5.9.13. По результатам выполнения работ по развитию системы должны быть подготовлены материалы для регистрации доработанной версии Системы (объекта учета) в НФАП в соответствии с требованиями постановления Правительства Российской Федерации от 30 января 2013?г. №?62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин» (с изменениями и дополнениями) в части обязательности размещения результатов работ в национальном фонде алгоритмов и программ для электронных вычислительных машин 4.5.10. Требования по стандартизации и унификации К Модулю СЦ предъявляются следующие требования в части стандартизации и унификации: – работы по развитию Модуля СЦ должны производиться в соответствии с действующими стандартами и нормами Российской Федерации; – при создании и модернизации элементов Модуля СЦ следует руководствоваться действующими в Российской Федерации национальными стандартами и другими нормативно-техническими документами; – используемые оборудование и материалы, подлежащие обязательной сертификации, должны иметь соответствующие сертификаты; – ПО Модуля СЦ должно проектироваться и разрабатываться с учётом обеспечения требований унификации; – применяемые при создании Модуля СЦ технические (форматы данных, протоколы передачи и прочие) и организационные (регламенты, требования, инструкции) решения должны быть доступны и документированы в виде, достаточном для независимой (без обращения к Подрядчику) реализации третьими сторонами; – термины, обозначения и наименования, используемые в ПО, должны быть стандартизованы и унифицированы, выполнены на русском языке; – взаимодействие элементов и их внешнее поведение должно быть реализовано одинаково и производиться по единым правилам 4.3.6.2. Требования к услугам информационно-консультационной поддержки работников Заказчика и пользователей Модуля СЦ Услуги информационно-консультационной поддержки сотрудников Заказчика включают: – обработку обращений и заявок, поступивших от сотрудников Заказчика; – консультирование сотрудников Заказчика и пользователей Модуля СЦ; – актуализацию документации, и других материалов по работе с Модулем СЦ при необходимости. – консультирование и разработку рекомендаций по настройке Модуля СЦ (без изменения программного кода), включая изменение настроек функционирования; – консультации по вопросам использования, настройки и возможностям Модуля СЦ; – консультации по проведению превентивных мер для недопущения аварийных ситуаций в Модуле СЦ; – консультации по предварительной диагностике и локализации возникшей неисправности Модуля СЦ; – консультации по вопросам обеспечения информационной безопасности Модуля СЦ и настройки функций, обеспечивающих корректную работу программного обеспечения для совершения юридически значимых действий в Модуле СЦ; – другие вопросы, связанные с работой Модуля СЦ. 4.3.6.2.1. Требования к порядку оказания услуг информационно-консультационной поддержки работников Заказчика и пользователей Модуля СЦ Подрядчик выполняет консультирование сотрудников Заказчика и пользователей Модуля СЦ. Консультация может быть предоставлена по согласованным с представителем Заказчика каналам коммуникации с регистрацией результата консультации в СРО Подрядчиком. Детальный порядок оказания консультационных услуг определен в Регламенте оказания Услуг 4.3.6.3. Требования к услугам по решению инцидентов, связанных с работой ППО Подрядчик устраняет неисправности Модуля СЦ, связанные с работой ППО, выявленные в рамках оказания услуг согласно настоящему Техническому заданию, при этом в зону ответственности Подрядчика не входит устранение неисправностей, выявленных на стороне Заказчика и на стороне третьих лиц (провайдера связи, поставщика электропитания и т.д.). Первичная диагностика выявленной неисправности проводится на 1 и 2 уровнях технической поддержки и не входит в зону ответственности Подрядчика. Если при проведении первичной диагностики и попытке устранить неисправности на 1 и 2 уровнях технической поддержки, данную неисправность устранить не удалось и в процессе диагностики было выявлено, что проблема связана с работоспособностью ППО, обращение (заявка) назначается сотруднику Подрядчика, ответственному за оказание услуг технической поддержки 3 уровня. Инцидентами вне зоны ответственности Подрядчика являются: – работоспособность функциональности, выходящая за рамки текущей реализации функций в Модуле СЦ и/или являющаяся расширением требований Заказчика к функциям Модуля СЦ; – проведение профилактических и плановых работ, согласованных с Заказчиком; – нарушение работоспособности функций Модуля СЦ, вызванное проведением работ на стороне Заказчика 4.5.11. Требования к показателям назначения 4.5.11.1. Требования к показателям назначения мероприятий по развитию Модуля СЦ В рамках выполнения работ по развитию Модуля СЦ, предусмотренных ТЗ, показатель назначения «Количество пользователей» должен соответствовать значениям, приведенным в данном разделе. Пояснения по показателям, связанным с количеством пользователей, приведены в Таблице 8. Таблица 8. Определения показателей, связанных с количеством пользователей в Модуле СЦ № Показатель Определение Расчетное количество пользователей Количество пользователей, работу которых должен обеспечить Модуль СЦ к моменту сдачи работ по Контракту с учетом достижения всех показателей назначения Расчетное количество одновременно работающих пользователей Количество одновременно работающих пользователей, работу которых должен обеспечивать Модуль СЦ к моменту сдачи работ по Контракту с учетом достижения всех показателей назначения Значения показателей количества пользователей, достижение которых необходимо обеспечить, представлено в Таблице 9 Таблица 9. Значения показателей количества пользователей № Показатель Значение 1. Расчетное количество пользователей 1 000 2. Расчетное среднее количество одновременно работающих пользователей 200 Развитие Модуля СЦ должно быть направлено на достижение следующего эффекта (показателя), подставленного в мероприятии 103.002 «Информационно-аналитическая система регулирования на транспорте (АСУ ТК)» ВПЦТ Минтранса России: Выполнение работ по развитию Модуля СЦ предусмотрено мероприятием по развитию АСУ ТК, приведенном в ВПЦТ Минтранса России на 2026-2028 гг: № 103.002 «АСУ ТК» в составе ИТ расхода 103.26.000005 «Развитие предусматривает реализацию ОКР и эффектов, приведенных в Таблице 10. Таблица 10. ОКР и эффекты, приведенные в ВПЦТ Минтранса России на 2026 г. № ОКР Дата ОКР Эффекты 1 Обеспечено информационное взаимодействие с Минобороны России о происшествиях на транспортных объектах 25.12.2026 Сокращено время сбора и передачи сведений для Минобороны России о ЧС и НС на транспорте с 120 до 10 минут 2 Обеспечена автоматизация формирования отчетов о нештатных ситуациях на транспорте, в том числе по данным внешних систем 25.12.2026 Сокращено время на подготовку отчетов о нештатных ситуациях на транспорте с 20 до 5 минут Реализация остальных ОКР не является предметом данного ТЗ и проводится в рамках отдельного технического задания. 4.5.11.2. Требования к показателям назначения мероприятий по эксплуатации Модуля СЦ. Работы по эксплуатации Модуля СЦ не должны обеспечивать режимы функционирования Модуля СЦ, приведенные в разделе 4.5.2 данного ТЗ Работы по устранению неисправности приостанавливаются (по согласованию с Заказчиком) в следующих случаях: – если Подрядчиком в результате диагностики выявлено, что неисправность находится в зоне ответственности Заказчика. Подрядчик информирует Заказчика о выявленной неисправности в зоне его ответственности по согласованным каналам связи; – требуется действие со стороны Заказчика – до момента выполнения данного действия Заказчика. Заказчик информируется о необходимых действиях по согласованным каналам связи; – отсутствие возможности связаться со специалистами Заказчика, участие которых необходимо для устранения неисправности; – требуется доставить оборудование на объект – до момента доставки и установки оборудования. В случаях, представленных выше, время приостановки работ не входит в учет продолжительности устранения неисправности. Учет времени устранения неисправности Подрядчиком считается с момента назначения Инцидента специалисту Подрядчика, ответственному за оказание услуг технической поддержки 3 уровня. Подтверждение необходимости приостановления работ находится в зоне ответственности Подрядчика. Приостановление сроков выполнения задач в соответствии с настоящим пунктом подтверждается Заказчиком по мотивированному обращению Подрядчика в СРО, основанному на данных диагностики или на иных фактических обстоятельствах В случае непринятия Подрядчиком необходимых мер по информированию Заказчика (отсутствие надлежащего обращения от Подрядчика или отсутствие уведомления о необходимости осуществления каких-либо действий Заказчиком) не может являться основанием для приостановления работ по устранению неисправности. В отдельных случаях Подрядчику может потребоваться выполнение технологических работ для устранения причин неисправности или недопущения повторения их в будущем. Для обеспечения устранения неисправности Модуля СЦ Заказчиком проводится классификация в соответствии с приоритетами по степени срочности их устранения. Продолжительность устранения неисправности, а также периодичность информирования Подрядчиком Заказчика о ходе устранения неисправности, определены в Регламенте оказания услуг. При подаче обращения (заявки) наивысшего приоритета через СРО Заказчик должен дополнительно проинформировать службу поддержки Подрядчика о созданном обращении (заявки) по телефону уполномоченного сотрудника Подрядчика. При этом временем подачи обращения (заявки) считается время подачи обращения (заявки) через СРО 4.3.6.3.1. Требования к порядку оказания услуги по решению инцидентов, связанных с работой ППО При поступлении от Заказчика обращения (заявки), являющегося неисправностью в работе Модуля СЦ (инцидентом), Исполнитель реагирует на инцидент в СРО в срок не более 30 минут с момента поступления. В случае необходимости, для решения инцидента ответственный специалист должен связаться с инициатором обращения (заявки) для уточнения условий воспроизведения проблемы или для получения дополнительных сведений. После получения необходимых сведений от инициатора обращения (заявки) ответственный специалист производит диагностику с целью выявления причины инцидента и возможных путей устранения. В случае, если инцидент невозможно решить без получения дополнительных сведений от инициатора, и не удается связаться с инициатором в течение пяти рабочих дней, обращение (заявка) отклоняется в связи с недостатком данных для его решения, Заказчику направляется уведомление об отклонении обращения (заявки). Время, в течение которого невозможно связаться с инициатором, вычитается из общего времени обработки обращения (заявки). Все попытки связаться с инициатором должны фиксироваться с указанием даты и времени попытки, используемого способа связи (номер телефона, адрес электронной почты) и результата попытки (не удалось дозвониться, абонент недоступен, и т.д.) Факт и время решения инцидента должны быть зафиксированы и отражены в СРО. В случае, если причиной сбоя в работе Модуля СЦ является выход из строя аппаратного обеспечения или неработоспособность смежной информационной системы, время работы над инцидентом приостанавливается до момента устранения неисправности. В ходе решения инцидентов могут быть выявлены дефекты ППО Модуля СЦ. В случае обнаружения дефектов ППО, Подрядчик информирует об этом Заказчика. Исполнитель может быть привлечен к проверке результата устранения дефекта по инициативе Заказчика. Приоритеты инцидентов приведены в Приложении Б к ТЗ. Детальный порядок оказания услуги по решению инцидентов, связанных с работой ППО Модуля СЦ определен в Регламенте оказания Услуг 4.3.6.4. Требования к услугам адаптационного, конфигурационного и коррекционного сопровождения и доработки Модуля СЦ (в рамках действующих программных модулей и функциональностей) Услуги адаптационного, конфигурационного и коррекционного сопровождения и доработки Модуля СЦ включают: – управление изменениями и адаптация функций Модуля СЦ; – изменение настроек функционирования Модуля СЦ; – внесение изменений и/или модификаций Модуля СЦ (в рамках действующих программных модулей и функциональностей), направленных на улучшение их работоспособности и функциональных возможностей; – подготовка и передача Заказчику SQL запросов в СУБД для получения агрегированной информации из Модуля СЦ, которую невозможно получить с использованием графического пользовательского интерфейса; – адаптация модулей интеграций со смежными информационными системами 4.3.6.4.1. Требования к проведению изменений Основанием для внесения изменений является запрос от Заказчика. Все активности по внесению изменений должны быть согласованы с Заказчиком, а действия Подрядчика при оказании данной услуги должны быть зафиксированы. В рамках данного Технического задания изменениями считаются локальные доработки функционала Модуля СЦ, которые не должны приводить к необходимости выполнения дополнительных аттестационных испытаний или переаттестации АСУ ТК в соответствии с п. 33 приказа от 29.04.2021 № 77 «Об утверждении Порядка организации и проведения работ по аттестации объектов информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну». При необходимости внесения изменений в Модуль СЦ, не связанных с критичным инцидентом, существенно нарушающим работоспособность Модуля СЦ, Заказчик направляет Подрядчику обращение (заявку), в котором излагает суть изменения, которое требуется внести в Модуль СЦ. Исполнитель, в течение 3 (трех) рабочих дней с момента поступления соответствующего обращения (заявки), оценивает техническую возможность реализации запрашиваемого изменения и варианты реализации. По итогу проведения оценки Подрядчик направляет Заказчику заключение о возможности реализации данного изменения с описанием возможных вариантов реализации и согласует с Заказчиком проведение данного изменения При проведении работ по изменению и адаптации Подрядчик должен: – обеспечить выполнение требований безопасной разработки программного обеспечения; – обеспечить предварительное проектирование технических решений и согласование с Заказчиком проекта реализации изменения; – использовать семантическое версионирование (SemVer) в работе, передать Заказчику все артефакты разработки (исходный код и сторонние библиотеки, конфигурации, сборочные и собранные образы и др.); – подготовить полноценное описание функционала, включенного в релиз, с необходимыми схемами и пояснениями к обновлению на стендах Заказчика; – обеспечить тестирование разработанного функционала на стендах Заказчика силами Подрядчика; – решение о переносе измененного ППО на продуктивный стенд принимается Заказчиком по итогу результатов проведенного тестирования; – обеспечить техническое сопровождение процедуры тестирования ППО и переноса измененного ППО на продуктивный стенд Заказчика; – обеспечить экстренное внесение соответствующих изменений в случае выявления некорректной работы продуктивного стенда Заказчика после проведения обновления по итогам разработанного изменения в кратчайшие сроки; – актуализировать при необходимости комплект эксплуатационной документации: o руководство пользователя; o руководство администратора; o иные документы (при необходимости). Результат выполнения изменений должен быть отражен в Отчете по оказанию услуг. Типы и приоритеты изменений могут быть скорректированы в процессе оказания услуг исключительно по согласованию с Заказчиком 4.3.6.4.2. Требования к изменению настроек функционирования Изменение настроек функционирования может проводиться в рамках допустимых пределов изменения функционирования, заложенных в архитектуру Модуля СЦ. Изменение настроек функционирования включает в себя изменение данных и справочников, изменение форм документов, формируемых Модулем СЦ, изменение и настройку форматов и версий передачи данных в смежные системы. Доработка программного кода Модуля СЦ может допускаться (в случае необходимости) при выполнении работ по адаптации функций Модуля СЦ в части изменения формата передачи данных в смежные информационные системы при условии соблюдения требований пункта 29.3 приказа ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации» 4.3.6.5. Требования к услугам по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности По запросу Заказчика Подрядчик должен провести работу по приведению ППО в соответствие с требованиями по обеспечению информационной безопасности. Критичность уязвимости оценивается в соответствии в соответствии с Методическим документом ФСТЭК России «Методика оценки уровня критичности уязвимостей программных, программно-аппаратных средств» (утвержден ФСТЭК России 30.06.2025), а также с учетом ГОСТ 56545-2015 и международными стандартами (CVSS 3.0 и выше), и задает необходимый срок устранения. В процессе проведения Заказчиком обследования Модуля СЦ и выявления уязвимостей в ППО, связанных с исходным кодом Модуля СЦ и/или используемыми компонентами (библиотеками), Заказчик направляет Подрядчику обращение (заявку) на устранение, с указанием критичности и срочности принятия мер по устранению в СРО. Подрядчик при оказании услуг по обновлению или устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности должен: – провести анализ уязвимостей и связанных с ними исходным кодом и/или используемыми компонентами (библиотеками); – выработать варианты устранения указанных уязвимостей и согласовать с Заказчиком их реализацию; – своевременно внести изменения в исходный код Модуля СЦ и/или используемые компоненты (библиотеки) и подготовить соответствующее обновление; – провести обновление Модуля СЦ в тестовом контуре Заказчика и проинформировать Заказчика о готовности проведения тестирования; – протестировать успешность обновления или устранения уязвимостей в ППО и корректность функционирования Модуля СЦ на тестовом контуре, совместно с Заказчиком; – при невозможности незамедлительного устранения уязвимости приоритетов «Критический» и «Высокий» Подрядчик обязан предоставить исчерпывающий список причин и согласовать план достаточных компенсирующих мер с ответственными сотрудниками Заказчика. Результат внесения изменений отображается в соответствующей записи в СРО и в составе Отчета об оказанных услугах 4.3.6.5.1. Требования к порядку оказания услуг по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности Подрядчик в соответствии с приоритетами обращений и контрольными сроками исполнения (см. Приложение Б к ТЗ) оценивает техническую возможность и сроки устранения уязвимостей, и реализацию обновления Модуля СЦ. По итогу проведения оценки Подрядчик направляет в заявке СРО Заказчику заключение о возможности устранения уязвимостей и/или обновления в ППО и согласует с Заказчиком проведение данных работ При проведении работ по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности необходимо выполнить следующее: – Заказчику сформировать заявку на устранение (обновление) в СРО с полным списком обнаруженных уязвимостей и планируемыми работами; – согласовать в рабочем порядке время начала и завершения работ, перечень работ, выполняемых в рамках обновления или устранения уязвимостей в ППО с Заказчиком; – оповестить Заказчика о начале проведения работ на тестовом контуре; – провести работы по обновлению или устранению уязвимостей в ППО на тестовом контуре Модуля СЦ в установленные сроки; – протестировать выполнение работ в тестовом контуре и проинформировать Заказчика о готовности переноса ППО на продуктивный контур; – силами Заказчика обновить продуктивный контур Модуля СЦ, в соответствии с планом устранения и выполненными работами; – совместно с Заказчиком проверить корректность функционирования Модуля СЦ и устранения уязвимостей в продуктивном контуре Модуля СЦ по результатам обновления; – при необходимости актуализировать документацию (описание архитектуры, анкеты постановки на мониторинг и иные документы). Любые изменения в части обновления или устранения уязвимостей в ППО на промышленном контуре Модуля СЦ должны применяться только в случае успешного проведения аналогичных работ на тестовом контуре. Детальный порядок оказания услуги по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности определен в Регламенте оказания Услуг 4.4. Требования к видам обеспечения 4.4.1. Требования к лингвистическому обеспечению Документация на Модуль СЦ должна разрабатываться на русском языке. Взаимодействие пользователей с Модулем СЦ посредством графического интерфейса должно происходить на русском языке за исключением сообщений, зависящих от настроек системного программного обеспечения, установленного на рабочих местах пользователей. При разработке программных решений Модуля СЦ должно быть предусмотрено использование языков программирования высокого уровня, приведенных в Таблице 7. Таблица 7. Языки и средства разработки, специального программного обеспечения Модуля СЦ Категория Наименование Назначение Языки программирования Kotlin Разработка серверной логики и сервисов (backend) JavaScript / TypeScript Разработка клиентской части (frontend) Python Разработка скриптов интеграции, обработки данных и автоматизации Фреймворки и библиотеки Vue.JS Разработка пользовательских интерфейсов (веб-интерфейсы компонентов визуализации и отчетности) React Разработка пользовательских интерфейсов (при необходимости создания сложных интерактивных компонентов) Решения по лингвистическому обеспечению, включая перечень используемых языков программирования, должны быть согласованы с Заказчиком на этапе технического проектирования 4.4.2. Требования к математическому обеспечению Требования к математическому обеспечению не предъявляются. 4.4.3. Требования к метрологическому обеспечению Требования к метрологическому обеспечению не предъявляются. 4.4.4. Требования к организационному обеспечению Требования к организационному обеспечению не предъявляются. 4.4.5. Требования к методическому обеспечению Задачи методического обеспечения Модуля СЦ должны быть обеспечены за счет использования технологических и методических документов касающихся вопросов функционирования транспортного комплекса и разработки и эксплуатации ПО. 4.4.6. Требования к информационному обеспечению Состав, структура и способы организации информационного обеспечения в Модуле СЦ должны быть определены на этапе технического проектирования. Факты информационного обмена с внешними системами должны фиксироваться в соответствующем журнале 4.1. Требования к структуре Модуля СЦ В процессе работ по развитию Системы должны сохраниться основные требования к построению архитектуры Системы в соответствии с принципами трехуровневой архитектуры: 1. уровень хранения данных или уровень базы данных (сервер СУБД); 2. уровень сервера приложений (сервер аналитической обработки); 3. презентационный уровень, обеспечивающий взаимодействие с клиентскими приложениями. В состав Системы должны входить следующие основные компоненты: 4. сервер баз данных; 5. сервер приложений; 6. веб-сервер. Сервер баз данных должен обеспечивать хранение и целостность хранимых данных, создание резервных копий, ведение журнала транзакций, восстановление данных после сбоев. Сервер приложений должен обеспечивать обработку запросов, поступающих от клиентских приложений (через веб-сервер), формирование ответов на запрос в доступном пользователю виде (формирование пользовательских интерфейсов). Веб-сервер должен обеспечивать взаимодействие с оператором и внешними системами по HTTP / HTTPS протоколу в режиме «запрос-ответ» (получения запросов от пользователя и передачи ответа в виде соответствующей информации, обработанной серверами приложений). Взаимодействие Системы с пользователем должно отвечать требованиям модели «тонкого клиента» (т.е. представлять на стороне клиента (пользователя) лишь графический пользовательский интерфейс). Все составляющие Системы должны использовать единую методологию и отвечать единым принципам взаимодействия, надежности и управления. Перечень компонентов Модуля СЦ представлен в Таблице 4. Таблица 4. Перечень компонентов Модуля СЦ, в отношении которых выполняются работы по развитию № п.п. Наименование компонента Модуля СЦ Раздел ТЗ 1 Компонент регистрации событий 4.2.1. 2 Компонент отчетности 4.2.2 3 Компонент визуализации 4.2.3 4 «Интерактивная карта» (компонент создается) 4.2.4 5 Компонент администрирования 4.2.5 4.2. Требования к дорабатываемым функциям модуля СЦ 4.2.1. Развитие компонента регистрации событий (1 очередь) Должны быть выполнены следующие доработки: – обеспечение логирования действий пользователя, связанных с карточкой события; – доработка объектной модели в части создания новых типов сущностей (карточек) с учетом реализуемых интеграций с информационными ресурсами (силы и средства предупреждения и ликвидации ЧС и нештатных ситуаций на транспорте, ТС, ограничения воздушного пространства, неблагоприятные и опасные природные явления); – реализация механизма установления связи между сущностями в Модуле СЦ автоматизированным и ручным способами (события, природные явления, силы и средства предупреждения и ликвидации ЧС и нештатных ситуаций на транспорте, ограничения воздушного пространства, ОТИ, ТС и др.); – отображение в карточке установленных связей между сущностями. 4.4.7. Требования к программному обеспечению Общесистемное ПО, используемое в составе Модуля СЦ, должно быть зарегистрировано в Едином реестре российских программ для электронных вычислительных машин и баз данных и соответствовать рекомендованным показателям эффективности и соответствующим им значениям индикаторов эффективности перехода подведомственных организаций на использование российского ПО, заданных Приказом Минцифры России от 18.01.2023 № 21 «Об утверждении методических рекомендаций по переходу на использование российского программного обеспечения, в том числе на значимых объектах критической информационной инфраструктуры Российской Федерации, и о реализации мер, направленных на ускоренный переход органов государственной власти и организаций на использование российского программного обеспечения в Российской Федерации». Применяемое в системе программное обеспечение должно соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации, постановления Правительства Российской Федерации от 23 декабря 2024 г. № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц» Прикладное программное обеспечение должно отвечать следующим требованиям: – совместимость программных продуктов в части используемых технических средств, системного программного обеспечения и общесистемной инфраструктуры в пределах требований к техническому обеспечению, а также их информационная совместимость в пределах требований к информационному обмену; – обеспечение трехуровневой архитектуры с разделением на уровень хранения данных (сервер БД), уровень бизнес-логики (сервер приложений) и уровень представления ( 4.4.7.1. Требования к инструментам разработки и процессу контроля версий программного обеспечения 4.4.7.1.1. Система контроля версий Для управления исходным кодом должна использоваться система контроля версий кода, развернутая в инфраструктуре Заказчика. 4.4.7.1.2. Правила именования веток Имя ветки должно соответствовать следующему формату: / / Категории веток: ? feature/ — разработка новой функциональности, а также рефакторинг или удаление существующей; ? fix/ — исправление ошибок; ? hotfix/ — срочные исправления, применяемые в обход стандартного процесса разработки; ? test/ — для проведения экспериментов, не влияющих на основную разработку. Идентификатор задачи: после категории указывается ссылка на задачу (issue) в системе контроля версий кода. Описание: добавляется краткое описание решаемой задачи в формате kebab-case (слова разделяются дефисами, например, add-user-auth). Примеры именования веток: ? feature/#123/add-payment-integration; ? fix/#45/correct-calculation-logic; ? hotfix/#67/urgent-database-connection-patch. 4.4.7.1.3. Правила именования коммитов Сообщение коммита должно соответствовать соглашению Conventional Commits и состоять из категории и описания: : ? fix — исправление ошибки. Примеры сообщений коммитов: ? feat: добавление формы регистрации пользователя; ? fix: исправление ошибки валидации email-адреса; ? refactor: оптимизация алгоритма сортировки данных; ? chore: обновление версий в файле dependencies. 4.4.7.1.4. Модель ветвления В процессе разработки используются следующие основные ветви: ? main / master — стабильная ветка, содержит только код, прошедший полное тестирование и развернутый в продуктивных контурах; ? dev — ветка для интеграции завершенных задач, предназначенная для сборки и тестирования в тестовых средах. Попадание кода в main осуществляется только через Merge Request (MR) из dev 4.2.2. Развитие компонента отчетности (3 очередь) Должна быть обеспечена автоматизация процессов формирования отчетов о ЧС и нештатных ситуациях на транспорте, в т.ч. на основе данных из внешних систем. Включает следующие доработки: – разработка шаблонов отчетов в различных форматах (табличный, текстовый); – реализация выбора фотоматериалов для включения в справку; – форматирование содержимого справок с учетом правил русского языка в отношении окончаний слов (в зависимости от падежа, склонения, числа и рода); – автоматизированное формирование выводов к содержимому справки на основе настраиваемых критериев; – создание интерфейса выбора параметров (фильтрации) для формирования отчетов: o состав полей для включения в отчёт; o настройка диапазонов значений характеристик и дат; o порядок отображения полей; o настройка заголовка. – реализация способа подготовки отчётов в асинхронном режиме (очереди); – реализация интерфейса компонента формирования отчетности для отображения очереди формирования отчетов и статусов их подготовки; – экспорт отчётов в форматы xlsx, csv и справок в форматы pdf, docx. Необходимо разработать не менее 10 шаблонов отчетов и/или справок. Перечень, структура и содержание шаблонов должны быть согласованы с Заказчиком на этапе технического проектирования. 4.2.3. Развитие компонента визуализации (2 очередь) В рамках развития компонента визуализации должны быть выполнены следующие доработки, обеспечивающие: – вывод перечней (списков) сил и средств предупреждения и ликвидации ЧС и нештатных ситуаций на транспорте с отображением мест их постоянного размещения (дислокации) на карте, включая: o отображение зон ответственности на карте; o возможность их фильтрации (по видам транспорта, регионам и пр.); o реализацию инструмента расчета расстояния (с использованием сети автомобильных и железных дорог) между местом события и местами дислокации сил и средств, а также вывода маршрутов на карте; – отображение зон (полигонов) с установленными ограничениями движения в воздушном пространстве на карте; – отображение термических точек; – реализация возможности отображения данных из паспорта региона, отображаемого в модуле iМинтранс (модуль АСУ ТК); – отображение краткой карточки сущностей и ОТИ (краткой информации и/или динамических характеристик объекта) при выборе объекта на карте с возможностью перехода в полную карточку сущности и ОТИ; – отображение данных от Росгидромета, предусматривающих: o отображение неблагоприятных и опасных природных явлений на карте (с заданным периодом обновления данных); o управление отображением явлений на карте, включая настройку состава отображаемых объектов, поиск, фильтрацию, с использованием соответствующей панели управления; o выведение краткой карточки явления при выборе объекта, с возможностью перехода в полную карточку объекта – отображение на карте связанных сущностей и ОТИ; – реализация функции выбора темного и светлого стилей отображения элементов интерфейса, карточек сущностей, картографической основы и объектов, отображаемых на карте; – реализация механизма для выбора картографической основы в одном из распространенных форматов WMTS, TMS, MVT и др. Должна быть предусмотрена возможность настройки перечня картографических основ и параметров доступа к ним; – настройка базового набора дашбордов, содержащих преднастроенные виджеты о количестве событий в разрезе видов транспорта с возможностью перехода к исходным данным (карточкам событий, ОТИ и т.д.), с фильтрацией по параметрам. Параметры фильтрации должны быть определены на этапе технического проектирования. Должно быть обеспечено автоматическое и принудительное обновление данных, отображаемых на дашбордах 4.4.7.1.5. Требования к используемым зависимостям (библиотекам) Все внешние зависимости проекта должны быть зафиксированы с указанием точных версий. Для контроля версий зависимостей в репозиторий обязательно должны быть включены следующие файлы: · Для JavaScript: package-lock.json или yarn.lock; · Для Python: requirements.txt (с зафиксированными версиями) или Pipfile.lock; · Для Go: go.mod и go.sum; Загрузка всех зависимостей должна производиться исключительно через внутренний прокси-репозиторий Заказчика, настроенный в соответствующем системе менеджере пакетов. Запрещается: · Использование плавающих версий (например, ^1.2.3, ~4.5.0, latest); · Использование библиотек, содержащих критические уязвимости, в том числе зарегистрированные в реестре CVE (Common Vulnerabilities and Exposures). 4.4.7.1.6. Требования к процессу непрерывной интеграции (CI) Сборка программного обеспечения, включая этапы компиляции, тестирования и анализа кода, должна выполняться исключительно в инфраструктуре непрерывной интеграции Заказчика. 4.4.7.1.7. Требования к хранению артефактов сборки Все артефакты сборки (результирующие пакеты, Docker-образы и т.д.) подлежат обязательному хранению в предназначенной для этого инфраструктуре Заказчика (артефакторий). Запрещается размещение финальных артефактов сборки на сторонних ресурсах 4.4.8. Требования к техническому обеспечению Количество серверов, подключаемых и настраиваемых сервисов, их параметров, схемы соединений и настройки межсетевого взаимодействия должны быть согласованы с Заказчиком на этапе № 1 Техническое проектирование. Доступ к комплексу технических средств предоставляется Заказчиком по письменному запросу Подрядчика. Применяемые в Системе программно-аппаратные и аппаратные комплексы должны соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации», требованиям Постановления Правительства Российской Федерации от 23 декабря 2024 г. № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц». Модуль СЦ, работающий в составе АСУ ТК, развернут на вычислительных мощностях ГЦОД СИЦ Минтранса России 4.5. Общие технические требования 4.5.1. Требования к численности и квалификации персонала и пользователей Модуля СЦ Программное обеспечение Модуля СЦ не должно требовать изменения штатной численности персонала Заказчика. Программное обеспечение Модуля СЦ не должно требовать наличия у пользователей дополнительной квалификации в сфере информационных технологий, кроме базовых знаний в обращении с персональным компьютером, базовых навыков работы в интернет-обозревателях и знаний о Модуле СЦ в объеме документов Руководство пользователя, Руководство администратора 4.2.4. Создание компонента «Интерактивная карта» (2 очередь) В составе создаваемого компонента должны отображаться данные, доступные в компоненте визуализации. Требования к интерфейсу интерактивной карты: – интерактивная карта должна быть представлена в виде объемной карты с учетом макетов, представленных в Приложении А к ТЗ; – интерфейс должен корректно отображаться на экранах мониторов (разрешение Full HD 1920?1080), телевизоров (разрешение 4К 3840?2160), жидкокристаллических панелей для видеостены, используемой Заказчиком, с параметрами каждой панели: диагональ 55 дюймов, разрешение 1920x1080; – интерфейс должен корректно отображаться на планшетных устройствах с диагональю экрана 10-12 дюймов, конкретные требования должны быть уточнены на этапе технического проектирования; – должна быть обеспечена кластеризация и генерализация отображения объектов на карте при изменении масштаба; – должно быть обеспечено отображение основных характеристик объектов при выборе их на карте; – должно быть обеспечено управление отображением слоев на карте; – должна быть обеспечена настройка цветовой индикации отображаемых объектов транспортной инфраструктуры; – должно быть обеспечено отображение легенды карты, содержащей отображаемые объекты на карте; – должна быть обеспечена возможность одновременного отображения не менее 5 000 ОТИ и ТС на карте. На интерактивной карте должны быть отображены подвижные объекты совместно с объектами транспортной инфраструктуры (ОТИ), включая следующие возможности: § отображение местоположения транспортных средств (воздушный, водный и автомобильный транспорт) на карте в режиме реального времени (с заданным периодом обновления данных); § отображение маршрутов движения всех ТС за выбранный период времени, в том числе с использованием эффектов анимации; § отображение маршрутов движения ТС, связанных с карточкой события: ТС, являющихся участниками события, и ТС, находящиеся в заданном радиусе от события; § управление отображением сущностей и ОТИ на карте, включая настройку состава отображаемых объектов, поиск, фильтрацию, с использованием соответствующей панели управления и наглядным представлением результатов; § автоматическое изменение вида отображения объектов (цветовая индикация) по заданным условиям (например, при достижении критических значений параметров, характеризующих функционирование объекта); Должна обеспечиваться производительность обновления изображения на экране в 30 кадров в секунду на тестовой конфигурации пользовательского устройства (модель Бештау AIO2402/B560, входящая в Реестр российской промышленной продукции под номером 10394100 или аналог) при одновременном отображении не менее 5 000 объектов и 200 уникальных моделей объектов. Макеты интерфейсов Модуля СЦ должны быть предварительно согласованы с Заказчиком и разработаны с учетом требований ГОСТ Р ИСО 9241-161-2016 «Элементы графического пользовательского интерфейса» 4.5.2. Требования к режимам функционирования Модуля СЦ Модуль СЦ должен предусматривать наличие следующих режимов работы: – штатный; – регламентный (профилактический); – аварийный. Основным режимом функционирования является штатный. В штатном режиме все компоненты корректно и полностью выполняют свои функции. Перерывов в работе как Модуля СЦ в целом, так и одного, либо нескольких компонентов не предусмотрено. Режим регламентного (профилактического) обслуживания предназначен для проведения работ по обновлению и техническому обслуживанию компонентов Модуля СЦ, а также резервному копированию данных. При работе в данном режиме допускаются перерывы в работе Модуля СЦ с предварительным информированием пользователей. Состав процедур по регламентному обслуживанию Модуля СЦ и их периодичность определяются Подрядчиком в процессе выполнения работ по созданию Модуля СЦ. В режиме регламентного (профилактического) обслуживания Модуль СЦ может функционировать с частичным ограничением своих функциональных возможностей, либо без ограничения, но со снижением показателей надежности и производительности. Перевод в данный режим работы должен осуществляться сразу после начала выполнения любой операции, отнесенной к этому режиму, с последующим возвратом в штатный режим функционирования сразу после ее завершения. Перевод в указанный режим должен осуществляться при возникновении необходимости проведения работ по обновлению и техническому обслуживанию компонентов Модуля СЦ, а также резервному копированию данных с условием предварительного оповещения пользователей. Аварийный режим функционирования характеризуется отказом одной или нескольких подсистем, вызванных выходом из строя аппаратного и/или программного обеспечения, а также в случае временной неработоспособности каналов связи между серверами. В аварийном режиме осуществляется поиск неисправностей и проведение работ по их устранению. Перевод в аварийный режим должен осуществляться при возникновении сбоев, аварий и прочих незапланированных воздействий, сразу после наступления одной или нескольких аварийных ситуаций, с последующим возвратом в штатный режим функционирования сразу после окончания восстановительных работ. ПО Модуля СЦ должно обладать надежностью, обеспечивающей работу пользователей в произвольном режиме и оперативное восстановление работоспособности при сбоях. В целях обеспечения надежного функционирования ПО должно предусматривать: – сохранение целостности данных при нештатном завершении работы компонентов Модуля СЦ; – сохранение работоспособности программного обеспечения при некорректных действиях пользователя; – резервное копирование базы данных Модуля СЦ. – время восстановления работоспособности Модуля СЦ после отказа не более 4 часов. – отказоустойчивость на уровне 99% при единовременной количестве не менее 200 пользовательских сессий в Модуле СЦ. Указанные характеристики приведены без учета характеристик надежности инфраструктуры и времени передачи информации по каналам связи. При возникновении сбоев в аппаратном обеспечении, включая аварийное отключение электропитания, Модуль СЦ должен автоматически восстанавливать свою работоспособность (не требовать перенастройки) после устранения сбоев и корректного перезапуска аппаратного обеспечения 5. СОСТАВ И СОДЕРЖАНИЕ РАБОТ ПО РАЗВИТИЮ И ТЕХНИЧЕСКОЙ ПОДДЕРЖКЕ МОДУЛЯ СЦ (КАЛЕНДАРНЫЙ ПЛАН) Сдача-приемка результатов выполненных работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная техническая документация, а также результаты работ предоставляются Заказчику в порядке, предусмотренном Контрактом и ТЗ, до размещения Подрядчиком в ЕИС документа о приемке. Документ о приемке размещается в ЕИС по каждому этапу в соответствии с условиями Контракта. Этапы выполнения работ по развитию Модуля СЦ приведены в Таблице 11. Таблица 11. Этапы выполнения работ по развитию Модуля СЦ. № этапа Наименование этапа Результат (отчетная документация) Срок исполнения этапа Значение характеристики не может изменяться участником закупки 1 Техническое проектирование Сопроводительным письмом предоставляются Заказчику: · Технический проект, включая следующие документы: – Ведомость технического проекта; – Ведомость машинных носителей информации – Пояснительная записка; – Описание информационного обеспечения системы; – Описание автоматизируемых функций; – Схема функциональной структуры; – Описание организации информационной базы; – Описание программного обеспечения; · Макеты экранных форм компонента «Интерактивная карта»; · Руководство по безопасной разработке программного обеспечения; · Документ о приемке Начало: с даты заключения контракта Окончание: не позднее 31.07.2026 2 Услуги по технической поддержке Модуля СЦ (с даты заключения контракта по 10.09.2026) По окончании оказания Услуг сопроводительным письмом предоставляются Заказчику: – Отчет об оказанных Услугах по технической поддержке; – Актуальные на дату окончания оказания Услуг по данному этапу исходные коды прикладного ПО на электронном носителе (в случае внесения изменений); – Инструкция по сборке и развертыванию (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство пользователя (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство администратора (в случае внесения изменений); – Документ о приемке Начало: с даты заключения контракта Окончание: не позднее 10.09.2026 3 Разработка программного обеспечения (1 очередь, пп. 4.2.1, 4.2.6 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ; – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 1 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 1 очереди; – Руководство по резервному копированию; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 16.09.2026 4 Разработка программного обеспечения (2 очередь, пп. 4.2.3, 4.2.4 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ. – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 2 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 2 очереди; – Руководство по резервному копированию; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 25.09.2026 5 Разработка программного обеспечения (3 очередь, пп. 4.2.2, 4.2.5 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ; – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 3 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 3 очереди; – Руководство по резервному копированию; – Описание ролевой модели; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 09.10.2026 6 Опытная эксплуатация (1 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акт о завершении опытной эксплуатации 1 очереди; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке 17.09.2026 Окончание: не позднее 26.10.2026 7 Опытная эксплуатация (2 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акт о завершении опытной эксплуатации 2 очереди; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке 26.09.2026 Окончание: не позднее 26.10.2026 8 Опытная эксплуатация (3 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Акт о завершении опытной эксплуатации 3 очереди; – Документ о приемке Начало: с 10.10.2026 Окончание: не позднее 26.10.2026 9 Приемочные испытания Сопроводительным письмом предоставляются Заказчику: – Программа и методика приёмочных испытаний; – Протокол приемочных испытаний; – Исходные коды и дистрибутивы на электронном носителе (при условии внесения изменений, с учетом доработок по результатам опытной эксплуатации и проведенных испытаний); – Комплект рабочей документации на Модуль СЦ (при условии внесения изменений, с учетом доработок по результатам опытной эксплуатации и проведенных испытаний); – Акт приемки Системы в эксплуатацию; – Акт приемки-передачи исключительных прав на объект; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке; – Документы в соответствии с разделом 4.5.9 ТЗ; – Обеспечение гарантийных обязательств Начало: с 27.10.2026 Окончание: не позднее 10.11.2026 10 Услуги по технической поддержке Модуля СЦ (с 11.09.2026 по 15.12.2026) По окончании оказания Услуг сопроводительным письмом предоставляются Заказчику: – Отчет об оказанных Услугах по технической поддержке; – Актуальные на дату окончания оказания Услуг по данному этапу исходные коды прикладного ПО на электронном носителе (в случае внесения изменений); – Инструкция по сборке и развертыванию (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство пользователя (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство администратора (в случае внесения изменений); – Документ о приемке Начало: с 11.09.2026 Окончание: не позднее 15.12.2026 Работы по развитию Системы (за исключением этапов проведения опытной эксплуатации и услуг по технической поддержке) могут быть выполнены досрочно. При досрочном выполнении работ (этапов работ) Подрядчик в письменной форме уведомляет Заказчика о готовности представить для приемки результаты проведения работ в соответствии с требованиями Контракта. Подрядчик также вправе досрочно приступать к работам в рамках очередного этапа при наличии технической, организационной готовности - при условии получения соответствующего согласования Заказчиком. Сдача-приемка результатов выполненных работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная, техническая документация, а также результаты Работ по каждому этапу предоставляется Заказчику в порядке, предусмотренном Контрактом и настоящим Техническим заданием, до размещения Подрядчиком в Единой информационной системе в сфере закупок документа о приемке. Документ о приемке размещается в ЕИС по каждому этапу в соответствии с условиями Контракта. Согласование документов осуществляется в электронном виде посредством переписки с адресов электронной почты Заказчика и Подрядчика, указанных в контракте. 6. ПОРЯДОК РАЗРАБОТКИ МОДУЛЯ СЦ Проектирование Модуля СЦ должно включать разработку следующих документов: – Ведомость технического проекта; – Ведомость машинных носителей информации – Пояснительная записка; – Описание информационного обеспечения системы; – Описание автоматизируемых функций; – Схема функциональной структуры; – Описание организации информационной базы; – Руководство по безопасной разработке программного обеспечения; – Описание программного обеспечения; – Макеты экранных форм компонента «Интерактивная карта». Структура документов должна соответствовать ГОСТ Р 59795-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов». Разработка Модуля СЦ должна включать в себя: – разработку программного обеспечения в части новых функций Модуля СЦ; – сборка исходного кода, развертывание и настройку доработанного программного обеспечения Модуля СЦ на вычислительных мощностях Заказчика (тестовый контур); – Комплект рабочей документации на Модуль СЦ; – разработку документа «Программа и методика предварительных испытаний»; – разработку документа «Программа и методика приемочных испытаний»; – разработку документа «Программа опытной эксплуатации». Структура документов должна соответствовать ГОСТ Р 59795-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов». В ходе выполнения работ формируется правоустанавливающая, отчетная, рабочая и техническая документация в соответствии с Контрактом и Календарным планом, приведенном в разделе 5. Значение характеристики не может изменяться участником закупки 6.1. Сведения о гарантийном обслуживании Модуля СЦ Под гарантией понимается устранение Подрядчиком своими силами и за свой счет допущенных по его вине недостатков, выявленных после приемки выполненных Работ, как в работе самой Модуля СЦ, так и недостатков в отчетной документации. Если в период гарантийного срока обнаружатся недостатки, то Подрядчик обязан устранить их за свой счет, в сроки, установленные Заказчиком. Гарантийный срок в этом случае продлевается на период устранения недостатков. Срок гарантии: 1 год с даты приемки Заказчиком результатов исполнения Этапа № 9 контракта. Подрядчиком должны быть внесены соответствующие исправления в техническую и рабочую документацию (указанную в пунктах 5 и 6 настоящего ТЗ), связанные с устранением замечаний к работе Модуля СЦ или в случае выявления Заказчиком недостатков в такой документации в период гарантийного срока. Внесение изменений в документацию технического и рабочего проектирования осуществляется в соответствии с ГОСТ 2.503-2023 и ГОСТ Р 2.504-2021. 7. ПОРЯДОК КОНТРОЛЯ И ПРИЕМКИ РЕЗУЛЬТАТОВ ВЫПОЛНЕНИЯ РАБОТ ПО РАЗВИТИЮ МОДУЛЯ СЦ Испытания должны быть организованы и проведены в соответствии с ГОСТ Р 59792-2021 «Информационная технология. Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем». Должны быть проведены следующие виды испытаний: – предварительные испытания; – опытная эксплуатация; – приемочные испытания. Указанные виды испытаний проводятся в отношении не функциональных требований и функциональных возможностей, разрабатываемых в соответствии с настоящим ТЗ. Отдельные виды испытаний проводятся поэтапно в сроки, установленные Календарным планом. Предварительные испытания, опытная эксплуатация, приемочные испытания проводятся комиссией, создаваемой организационно-распорядительным документом Заказчика, который должен определять состав комиссии, порядок ее работы. Методы предварительных испытаний и порядок их проведения должны быть определены в документе «Программа и методика предварительных испытаний», который должен быть утвержден Заказчиком до начала предварительных испытаний. По результатам предварительных испытаний оформляется Протокол предварительных испытания и Акт о приемке в опытную эксплуатацию. Порядок проведения и методы испытаний во время опытной эксплуатации должны быть определены в документе «Программа опытной эксплуатации», который должен быть утвержден Заказчиком до начала опытной эксплуатации. Ход и результаты опытной эксплуатации отражаются в документе «Журнал опытной эксплуатации», и учитываются в ходе приемочных испытаний. По результатам опытной эксплуатации подписывается Акт о завершении опытной эксплуатации Значение характеристики не может изменяться участником закупки До момента подключения внешних ИС, Подрядчиком могут быть использованы эмуляторы ИС для прохождения предварительных испытаний, опытной эксплуатации и приемочных испытаний. В рамках опытной эксплуатации должны быть проведены мероприятия по нагрузочному тестированию Модуля СЦ. Документ «Программа и методика приемочных испытаний» должен быть разработан с учетом недостатков, выявленных в ходе опытной эксплуатации, утвержден Заказчиком до начала приемочных испытаний, при этом проверки Модуля СЦ в части не устраненных недостатков, выявленных в процессе опытной эксплуатации, должны быть вынесены в отдельный раздел «Программы и методики приемочных испытаний». В процессе приемочных испытаний должно быть проверено устранение недостатков, полученных в ходе опытной эксплуатации. После завершения устранения всех замечаний, препятствующих приемке Системы в эксплуатацию, перечисленных в Протоколе приемочных испытаний, Подрядчик должен письменно уведомить Заказчика о том, что все замечания устранены, после чего приемочные испытания по решению Заказчика могут быть проведены повторно. Процедура приемочных испытаний проводится до подписания Протокола приемочных испытаний, не содержащего замечаний, препятствующих приемке Системы в эксплуатацию. Приемочные испытания Системы считаются завершенными успешно, если Протокол приемочных испытаний не содержит замечаний, препятствующих приемке Системы в эксплуатацию 8. ТРЕБОВАНИЯ К СОСТАВУ И СОДЕРЖАНИЮ РАБОТ ПО ПОДГОТОВКЕ МОДУЛЯ СЦ К ВВОДУ В ЭКСПЛУАТАЦИЮ По результатам проведения приемочных испытаний оформляется Протокол приемочных испытаний и Акт приемки в эксплуатацию. В случае, если взаимодействие с внешними системами не может быть проверено на средах постоянной эксплуатации взаимодействующих систем (по причине неготовности со стороны внешней системы или иным причинам), функции взаимодействия, разработанные в соответствии с требованиями ТЗ, должны быть проверены на тестовых данных с использованием программ-имитаторов взаимодействия. По результатам выполнения этапа приемочных испытаний должны быть подготовлены материалы для регистрации доработанной версии Модуля СЦ (объекта учета) в НФАП в соответствии с требованиями постановления Правительства Российской Федерации от 30 января 2013?г. №?62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин» (с изменениями и дополнениями) в части обязательности размещения результатов работ в национальном фонде алгоритмов и программ для электронных вычислительных машин. Сдача-приемка результатов выполнения Работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная, техническая документация, а также программное обеспечение предоставляется Заказчику в порядке, предусмотренном Контрактом и ТЗ до размещения Подрядчиком в Единой информационной системе в сфере закупок документа о приемке. Результаты проведения опытной эксплуатации, предварительных и приемочных испытаний должны быть зафиксированы в соответствующих протоколах и актах. Выявленные отклонения от настоящего ТЗ, оформляются как недостатки Модуля СЦ Значение характеристики не может изменяться участником закупки Протоколы предварительных и приемочных испытаний должны содержать вывод о соответствии Модуля СЦ предъявляемым требованиям, а также сроки устранения замечаний и реализации рекомендаций, сформулированных комиссией в ходе предварительных и приемочных испытаний. Условием для передачи Модуля СЦ в промышленную эксплуатацию является устранение всех замечаний. Документация на Модуль СЦ и ее части (техническая и рабочая) должна содержать исчерпывающее описание принятых проектных решений в объеме, достаточном для ее дальнейшего развития и эксплуатации. Техническая и рабочая документация должна содержать описание разработанных результатов работ, в том числе программ для ЭВМ, прикладных программных интерфейсов, алгоритмов и протоколов информационного взаимодействия, технических требований, спецификаций и форматов обмена данными для взаимодействия с другими информационными системами, в объеме, достаточном для их установки, настройки, эксплуатации и развития в дальнейшем без привлечения Подрядчика. Исходные коды передаются в виде и составе, позволяющем провести: – сборку (компиляцию) Модуля СЦ в контролируемой Заказчиком среде; – установку полученной Модуля СЦ на специально подготовленную контролируемую Заказчиком инфраструктуру; – проверку функциональных возможностей Модуля СЦ; – оформление Модуля СЦ в качестве объекта национального фонда алгоритмов и программ для электронных вычислительных машин 8.1. Требования, предъявляемые в соответствии с Приказом Минцифры России от 17.12.2020 № 715 «Об утверждении типовых условий контрактов на выполнение работ по созданию и (или) развитию (модернизации) государственных (муниципальных) и (или) иных информационных систем» Передача исходных кодов, разработанных в ходе выполнения работ, программ для электронных вычислительных машин (далее – программа для ЭВМ) должна сопровождаться передачей всех необходимых для сборки и запуска программы для ЭВМ библиотек зависимостей, программных сценариев (скриптов) для проведения установки (развертывания) программы для ЭВМ. Подрядчик в процессе сдачи-приемки работ по Контракту должен провести демонстрацию процесса и установки (развертывания) разработанных программ для ЭВМ. Документация на Модуль СЦ должна содержать описание принятых проектных решений в объеме, достаточном для ее дальнейшего развития и эксплуатации 9. ТРЕБОВАНИЯ К ДОКУМЕНТИРОВАНИЮ 9.1. Общие требования Документация на Модуль СЦ должна быть разработана в составе, указанном в разделах 5-8 данного ТЗ, и должна удовлетворять требованиям комплекса стандартов и руководящих документов на автоматизированные системы: – ГОСТ Р 2.105-2019 в части оформления текстовых документов; – ГОСТ 34.201-2020 в части наименования и обозначения документов. Документация на Модуль СЦ должны оформляться на листах формата А4. Допускается для размещения рисунков и таблиц использование листов формата А3 с подшивкой по короткой стороне листа. Документы объемом более 25 (двадцати пяти) листов должны содержать информационную часть, состоящую из аннотации и содержания. Исходные коды должны быть представлены в 1 (одном) экземпляре на электронном носителе, отчетные материалы должны быть представлены в 2 (двух) экземплярах на бумажном носителе (по одному экземпляру для Заказчика и Подрядчика) и в 1 (одном) экземпляре на электронном носителе в формате документов DOCX и PDF. При разработке документов на Модуль СЦ допускается отклонение от требований комплекса стандартов, описанных выше. Документам на Модуль СЦ должны в обязательном порядке присваиваться уникальные децимальные номера в соответствии с порядком, установленном в ГОСТ 34.201-2020. Документ «Программа и методика предварительных испытаний» должен включать приложения с формой протокола предварительных испытаний и формой акта приемки в опытную эксплуатацию. Документ «Программа опытной эксплуатации» должен включать приложение с формой журнала опытной эксплуатации. Документ «Программа и методика приемочных испытаний» должен включать приложения с формой протокола приемочных испытаний и формой акта приемки в эксплуатацию Значение характеристики не может изменяться участником закупки 10. ИСТОЧНИКИ РАЗРАБОТКИ 10.1. Список литературы Специальная литература для разработки ТЗ не использовалась. 10.2. Нормативно-методические документы Список используемых нормативно-методических документов представлен в разделе 1.6 технического задания. ? Приложение А Эскизы визуального оформления компонента «Интерактивная карта» Значение характеристики не может изменяться участником закупки Приложение Б Параметры оказания услуг Б.2. Приоритеты и регламентные сроки решения обращений (заявок) В зависимости от уровня сбоя в работе Системы обращению (заявке) присваивается один из следующих приоритетов, а также в зависимости от приоритета обращения (заявки) устанавливаются следующие контрольные сроки решения в соответствии с таблицей ниже (Таблица Б.2.1). Таблица Б.2.1 – Приоритеты и регламентные сроки решения обращений (заявок) № п/п Приоритет Максимальное время реагирования Время решения (срок выполнения) Описание приоритета По информационно-консультационной поддержке сотрудников Заказчика и пользователей Системы 1 - не более 1 часа не более 10 часов - По решению инцидентов, связанных с работой ППО: 1 Критический не более 30 минут не более 4 часов - полная недоступность ППО; - недоступность ключевых функций - ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО; - невозможность информационного обмена с ППО для ИС более 4 часов 2 Высокий не более 1 часа не более 8 часов - ошибки/сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; - снижение быстродействия СПО (время отклика ППО на операции превышает 30 секунд); - недоступность управления правами и ролями пользователей 3 Средний не более 4 часов не более 24 часов - невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым -недоступность функции формирования отчетов 4 Низкий не более 8 часов не более 40 часов - отклонение в работе ППО, не влияющее на корректную работу функций; - другие сбои и ошибки, затрагивающие основные функции ППО Значение характеристики не может изменяться участником закупки По адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) 1 Критический не более 40 минут не более 8 часов - изменения, необходимые при проведении аварийно-восстановительных работ для возобновления работоспособности Системы; - изменения, связанные с критичными ошибками, блокирующими возможность оказания государственных услуг и/или чтение и внесение данных в Систему 2 Высокий не более 1 часа не более 40 часов - изменения, относящиеся к обеспечению работоспособности основной функциональности Системы, устраняют выявленные дефекты в работе Системы, оказывающие существенное влияние на работу пользователей в Системе; - изменения, затрагивающие три и более подсистемы/модуля Системы для адаптации 3 Средний не более 4 часов не более 72 часов - изменения, связанные с развитием/улучшением/оптимизацией Системы и выводом новой функциональности в штатном режиме для одного-двух модулей/подсистем; - изменения, связанные с развитием интеграционных механизмов Системы, например обновление существующих и/или реализация новых видов сведений СМЭВ, обновление существующих и/или реализация новых API, адаптация и/или изменение механизмов импорта и экспорта данных Системы и т.д. 4 Низкий не более 8 часов не более 160 часов - изменения, связанные с ошибками/корректировкой/изменением в отображении информации в пользовательском графическом интерфейсе Системы (графика, текст, органы управления, элементы интерфейса) По устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности 1 Критический не более 30 минут не более 24 часов - критические уязвимости, влияющие на возможную полную недоступность ППО, ключевых функций Системы, ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО без возможности восстановления работоспособности Системы. - Критический уровень CVSS > 8.0 2 Высокий не более 1 часа не более 84 часов - критические уязвимости, влияющие на ошибки и сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО. - Высокий уровень CVSS 5.0 - 8.0 3 Средний не более 4 часов не более 120 часов - уязвимости, влияющие на невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым - Средний уровень CVSS 2.0 - 4.9 4 Низкий не более 8 часов не более 160 часов - уязвимости, влияющие на отклонение в работе ППО, не влияющее на корректную работу функций; - другие сбои и ошибки, затрагивающие основные функции ППО - Низкий уровень CVSS < 2.0 Взаимодействие Заказчика и Подрядчика в части регистрации и контроля времени реагирования и решения обращения (заявки) осуществляется через СРО. Заказчик предоставляет Подрядчику доступ к СРО после заключения Контракта. Поступившие от разных пользователей заявки по поводу однотипных инцидентов или имеющие общую причину должны объединяться в одну заявку. Срок выполнения включает время диагностики инцидента, в ходе которого определяется причина инцидента (проблемы) и способ его устранения. Подрядчик должен обеспечить функционирование Модуля СЦ в соответствии с требованиями и параметрами, указанными в настоящем ТЗ и Регламенте оказании услуг. Основные параметры быстродействия типовых операций в Модуле СЦ указаны в таблице ниже (таблица Б.2.2). Таблица Б.2.2 - Параметры быстродействия Модуля СЦ № п/п Наименование параметра Значение (секунд) 1 Среднее время получения сообщения из очереди сообщений 10 2 Среднее время получения ответа от Системы 5 3 Среднее время открытия карточки реестра 5 Б.1. Базовые параметры оказания Услуг Базовые параметры оказания Услуг приведены ниже: – режимы оказания Услуг (таблица Б.1.1); – сроки предоставления отчетности (таблица Б.1.2). Таблица Б.1.1 - Режимы оказания Услуг № п/п Параметр Значение 1 Режим работы Системы Круглосуточно (24х7) 2 Режим доступности информационно-консультационной поддержки пользователей Системы 2.1 Прием и регистрация обращений (заявок) в СРО Регистрация обращений (заявок) производится круглосуточно в режиме 24х7, без праздников и выходных дней. Обработка заявок первой линией поддержки осуществляется в рабочие дни с 9 до 18 часов 2.2 Консультирование сотрудников Заказчика и пользователей Системы в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 3 Режим доступности по решению инцидентов, связанных с работой ППО: 3.1 - приоритет «Критический» Круглосуточно (24х7) 3.2 - приоритет «Высокий» Круглосуточно (24х7) 3.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 3.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4 Режим доступности услуг по адаптации, конфигурации и коррекционному сопровождению Системы 4.1 - приоритет «Критический» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.2 - приоритет «Высокий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 5 Режим доступности по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности 5.1 - приоритет «Критический» Круглосуточно (24х7) 5.2 - приоритет «Высокий» Круглосуточно (24х7) 5.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 5.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) Таблица Б.1.2. Сроки предоставления отчетности, с момента получения запроса № п/п Параметр Значение 1 Предоставление отчета об оказанных услугах за произвольный период 10 рабочих дней 2 Предоставление подробной информации по инциденту с приоритетом «Критический» 16 рабочих часов 3 Предоставление актуализированной документации 10 рабочих дней Приложение В Регламент оказания услуг Термины и сокращения В настоящем регламенте используются следующие термины и сокращения на русском и английском языках: Термины/сокращения Полное наименование/описание БЗ (База знаний) База данных Системы регистрации обращений (заявок), созданная для сбора, хранения и поиска способов решения известных проблем в рамках Системы Жизненный цикл обращения (заявки) Совокупность статусов, по которым проходит обращение (заявка), и правила перехода обращения (заявки) из одного статуса в другой Заказчик ФГБУ «СИЦ Минтранса России» – Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» ЗНИ Запрос на изменение – тип заявки, предполагающий внесение изменений в прикладное программное обеспечение Системы ЗНО Запрос на обслуживание – тип заявки, предполагающий работы по предоставлению консультации, предоставление доступа к Системе или стандартизированные типовые изменения конфигураций Системы Инцидент Тип заявки, классифицируемый как нештатное событие в работе компонентов функциональных задач Системы, которое привело или может привести к нарушению или снижению качества функционирования Системы ИС Информационная система Исполнитель Организация, которая определяется по результатам конкурсных процедур Классификация Анализ и заполнение классификационных полей справочными значениями, определяющими последовательность действий и этапов жизненного цикла заявки, а также порядок рассмотрения заявок Консультация Разъяснения по алгоритму работы, требуемых настроек прикладного программного обеспечения и технологии обработки данных при работе с Системой, предоставление информации Маршрутизация Определение процесса движения обращения (заявки) в Системе управления заявками между уровнями технической поддержки и организационными структурами на уровнях поддержки путем назначения обращения (заявки) в соответствии с его классификацией и выставленным приоритетом Значение характеристики не может изменяться участником закупки Обращение (заявка) Устное или письменное обращение пользователя АСУ ТК с вопросом, касающимся работоспособности АСУ ТК, по одному из определённых каналов связи: электронная почта, Система регистрации обращений (заявок) Пользователь Инициатор обращения (заявки) или пользователь Системы ППО Прикладное программное обеспечение Предмет обращения Справочник, классифицирующий типовые запросы в Системе регистрации обращений (заявок), характерные для Системы, выбранное значение определяет маршрутизацию обращения (заявки) (группу ответственных сотрудников) Приоритизация Значение, определяющее время, очередность решения обращений (заявок), ресурсы, привлекаемые для решения обращений (заявок), . Приоритет устанавливается в соответствии с масштабом выявленной проблемы, которая привела или может привести к нарушению или снижению качества функционирования Системы Релиз Выпуск версии прикладного программного обеспечения Системы, от разработки до тестирования и планового обновления Системы на продуктивной среде для установки изменений, связанных с развитием/улучшением/оптимизацией Системы Система, АСУ ТК, Информационно-аналитическая система регулирования на транспорте Информационно-аналитическая система, предназначенная для автоматизации и информационно-аналитического обеспечения процессов управления развитием транспортного комплекса Российской Федерации, обеспечения публичности деятельности органов государственного управления транспортным комплексом, а также обеспечения процессов оказания государственных услуг в электронном виде в сфере транспорта СМЭВ Система межведомственного электронного взаимодействия СПО Системное программное обеспечение СРО Система регистрации обращений (заявок) Статус обращения (заявки) Текущее состояние обращения (заявки) в жизненном цикле процесса оказания технической поддержки Системы СУБД Система управления базами данных Уровень технической поддержки Организационно-структурная часть технической поддержки, имеющая определённые организационно-нормативными документами зоны ответственности, обязанности, а также временные нормативы, в течение которых эти обязательства должны выполняться либо эскалироваться на следующий уровень технической поддержки Услуги Услуги по технической поддержке Информационно-аналитической системы регулирования на транспорте АСУ ТК ФИО Фамилия, имя, отчество Эскалация Процедура повышения внимания к обращению (заявке) путем повышения его приоритета и/или передачи на следующий уровень технической поддержки, а также привлечение ролей, которые могут принимать решения без передачи на следующий уровень технической поддержки API Англ. Application Programming Interface — программный интерфейс приложения, интерфейс прикладного программирования — описание способов (набор классов, процедур, функций, структур или констант), которыми одна компьютерная программа может взаимодействовать с другой программой CVSS Англ. Common Vulnerability Scoring System - открытый стандарт, используемый для расчета количественных оценок уязвимости в безопасности компьютерной системы, обычно с целью понять приоритет ее исправления. В современном инструментарии информационной безопасности используется версия 3.0 и выше с дополнительными метриками к базовым оценкам ID Англ. Identifier – идентификатор, уникальный признак объекта, позволяющий отличать его от других объектов, то есть, идентифицировать SLA Англ. Service Level Agreement - утвержденные условия по обработке обращения (заявки) с установленными метриками времени, которые определяют пороговые значения для эскалации в зависимости от статуса обращения (заявки) (например, время реакции – время от регистрации до осуществления первичной обработки, время решения – время от регистрации обращения (заявки) до его решения и т.д.) SQL Англ. Structured Query Language — «язык структурированных запросов», — декларативный язык программирования, применяемый для создания, модификации и управления данными в реляционной базе данных, управляемой соответствующей СУБД 1 Общие сведения 1.1 Полное наименование Услуг Оказание услуг по технической поддержке Модуля СЦ АСУ ТК в 2026 году. 1.2 Предмет Регламента оказания услуг Требования Технического задания 2 Общие положения 2.1 Цель и задачи оказания услуг Целью технической поддержки Системы является обеспечение ее стабильного и безопасного функционирования и эксплуатации, предупреждение, выявление и устранение сбоев в работе Системы и минимизация их неблагоприятного влияния. Для достижения поставленной цели требуется решение следующих задач: 1. Обеспечение информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы. 2. Поддержание параметров функционирования ППО Системы, удовлетворяющих требованиям производственных процессов, включая их непрерывность. 3. Обеспечение бесперебойного функционирования ППО и своевременное устранение сбоев и аварийных ситуаций в Системе. 4. Своевременное устранение уязвимостей при выявлении таковых, в соответствии с требованиями к обеспечению информационной безопасности. 5. Адаптация, конфигурирование, коррекция программного обеспечения в соответствии с изменениями нормативно-правовой базы и запросами уполномоченных сотрудников органов государственной власти, включая выполнение процедур тестирования и участие в обновлениях ППО на стендах Заказчика. 6. Обеспечение сохранения работоспособности ППО в изменяемой среде эксплуатации. 7. Ведение документации по настоящему контракту и инициирование актуализации документации на Систему по результатам обработки запросов Заказчика и внесения соответствующих изменений в ППО 2.2 Общее описание процесса оказания сопровождения (технической поддержки) Системы Процесс оказания технической поддержки Системы включает: 1. Поступление обращений (заявок) от пользователей и их регистрацию. 2. Сопровождение обращений (заявок) в соответствии с их классификацией и приоритизацией, в том числе, с их последующей эскалацией. 3. Определение ролей и регламент их взаимодействия при осуществлении деятельности по процессу. 4. Решение обращений (заявок) в установленные настоящим Регламентом сроки. 5. Взаимодействие между 1-м, 2-м и 3-м уровнями технической поддержки, в том числе, с формированием заданий для сопровождения Системы. 6. Контроль качества выполняемых Исполнителем работ, состоящий из проверки сценария, приводящего к ошибке, зафиксированной в Инциденте, и/или к ошибке воспроизведения, а также тестирование внесенных изменений в рамках ЗНИ. 7. Обеспечение мониторинга и проведение анализа процесса обработки поступающих в техническую поддержку обращений (заявок). Техническая поддержка реализуется путем проведения ответственными сотрудниками соответствующей информационно-консультационной деятельности в соответствии с определенными ролями, а также выполнения Исполнителем конкретных действий по своевременному выявлению причин сбоев и аварийных ситуаций и их устранению, а также по адаптации, конфигурированию, корректировке Системы, включая выполнение процедур тестирования и участия в обновлениях Системы. Все роли подразделяются на уровни поддержки, взаимодействующие между собой в соответствии с блок-схемой процесса технической поддержки. Общая схема процесса рассмотрения обращений (заявок) в соответствии с видами технической поддержки представлена на рисунке 1. . Рисунок 1 - Общая схема процесса рассмотрения обращений (заявок) в соответствии с видами технической поддержки 2.3 Каналы связи Должна быть предусмотрена омниканальность в части приема обращений (заявок). Получение обращений (заявок) технической поддержкой происходит по следующим каналам связи: – СРО; – электронная почта; – телефонная линия. Исполнитель обеспечивает прием обращений (заявок) от Заказчика и предоставляет информацию в рамках оказания услуг по техническому сопровождению Системы, руководствуясь матрицей взаимодействия, приведенной в Приложении 1 к настоящему Регламенту 3 Порядок оказания Услуг 3.1 Типы обращений (заявок) Обращения и заявки Заказчика классифицируются в соответствии с приоритетами и регламентными сроками, указанными в Приложении 2 к настоящему Регламенту. Регистрация обращений и заявок предусматривает создание новой записи в СРО с присвоением поступившему обращению или заявке (новой записи) уникального идентификатора. Запись в СРО должна содержать вопрос или проблему, которую требуется решить или оказать консультацию. Если обращение или заявка автоматически зарегистрированы в СРО при отправке представителем Заказчика, Исполнитель проверяет корректность указанного типа обращения (заявки) и может обратиться к Заказчику с просьбой корректировки, предоставив обоснования в соответствии с настоящей классификацией (Таблица 1) Таблица 1 - Типы обращений (заявок) Тип обращения (заявки) Описание Запрос на обслуживание Подготовка SQL запроса к СУБД для решения прикладной задачи и д р. – запрос на любое действие, не являющееся запросом информации и несовершенный на основе происшествия, прямо или косвенно влияющего на работу Системы Консультация (входит в тип обращения (заявки) «Запрос на обслуживание») «Где взять / куда обратиться...?», «Как сделать / выполнить…», «Как это работает…?» - запрос, имеющий своей целью получение информационной поддержки Инцидент Разбор ошибок/сбоев и подготовка материалов (корректировочных релизов, инструкций) для Заказчика для устранения ошибок/сбоев, которые приводят к частичному и полному нарушению работоспособности всех или отдельных функций ППО. Подготовка изменения и материалов, необходимых для проведения аварийно-восстановительных работ для возобновления работоспособности Системы. ЗНИ Подготовка изменений, связанных с изменением, улучшением/оптимизацией Системы и выводом новой модифицированной функциональности в штатном режиме. Подготовка изменений, связанных с модификацией существующих и/или реализация новых интеграционных механизмов для получения/обработки данных внешних систем. Подготовка изменений графического интерфейса по требованиям Заказчика 3.2 Участники технической поддержки, осуществляющие сопровождение обращений (заявок) Техническая поддержка Системы должна быть организована на трех уровнях: 1. Первый и второй уровни технической поддержки организуется Заказчиком. 2. Третий уровень технической поддержки организуется Исполнителем. Зона ответственности каждого уровня технической поддержки указана в Таблице 2. Таблица 2 - Зона ответственности каждого уровня технической поддержки Участники технической поддержки Описание Первый уровень технической поддержки (далее – 1-й уровень) Группа ответственных сотрудников 1-го уровня Заказчика, осуществляющая прием и первичную обработку обращений (заявок) (описание предмета обращения, первичная классификация и приоритизация, определение назначения, маршрутизация обращений (заявок) по назначению), руководствуется в своей работе настоящим Регламентом и БЗ, наполняемой 2-м уровнем поддержки, самостоятельно решает часть обращений (заявок), связанных с недостаточной квалификацией пользователей или настройками в рамках своей компетенции. В случае невозможности решения обращений (заявок) на 1-ом уровне ответственный сотрудник передает ее на 2-й уровень Второй уровень технической поддержки (далее – 2-й уровень) Группа ответственных сотрудников 2-го уровня Заказчика по установленным компетенциям (информационная безопасность, сопровождение и эксплуатация информационно-аналитических систем, развитие информационно-аналитических систем, техническая поддержка информационно-аналитических систем) отвечает за поддержание работоспособности Системы, обработку обращений (заявок) и их решение в регламентные сроки в соответствии с установленными приоритетами. Осуществляет информационно-консультационную поддержку пользователей Системы в рамках своей компетенции. Оказывает экспертную помощь ответственным сотрудникам 1-го уровня в части формирования БЗ, содержащей ответы на часто задаваемые вопросы пользователей, с целью передачи знаний, навыков и инструментария на 1-й уровень для ускорения решения обращений (заявок). В случае невозможности решения обращения (заявки) на 2-ом уровне ответственный сотрудник передает его на 3-й уровень. При выявлении необходимости изменений в ППО Системы инициирует формирование обращения (заявки) и направляет его на группу ответственных сотрудников 3-го уровня по соответствующему классификатору (ЗНО, ЗНИ, и т.д.) Третий уровень технической поддержки (далее – 3-й уровень) Группа ответственных сотрудников Исполнителя, отвечающая за устранение сбоев и аварий, проведение информационно-консультационной поддержки пользователей Системы, проведение адаптации и конфигурирования Системы в объемах действующих контрактов на оказание технической поддержки 3.3 Перечень и описание статусов обращений (заявок) В Таблице 3 приведен перечень статусов обращений (заявок), действующий в СРО, и их описание. Таблица 3 - Перечень статусов обращений (заявок) и их описание Статус Описание Зарегистрирован Обращение (заявка) принято и зарегистрировано Направлен в группу Присваивается при назначении ответственными сотрудниками 1-го уровня группе ответственных сотрудников 2-го уровня по тематике обращения (заявки) после заполнения всей необходимой информации и полей обращения (заявки), а также при его передаче между группами 2-го уровня Передан в группу Присваивается при передаче обращения (заявки) ответственными сотрудниками 2-го уровня на группу ответственных сотрудников 3-го уровня Назначен Присваивается при назначении обращения (заявки) на ответственного сотрудника для его решения в рамках компетенции В работе Присваивается при приеме обращения (заявки) в работу ответственным сотрудником для его решения Решен Присваивается ответственным сотрудником, выполнившим работы по обращению (заявке) Закрыт Присваивается автоматически при решении запроса по обращению (заявке), а также отсутствии дополнительных запросов пользователя в соответствии с действующим SLA, или при подтверждении решения обращения (заявки) со стороны пользователя Запрос доп. информации Присваивается при необходимости запроса дополнительной информации и/или уточнения предмета обращения по обращению (заявке) у пользователя Ответ предоставлен Присваивается после ответа пользователем на запрос дополнительной информации Отклонен Присваивается, если обращение (заявка) не актуальна (по информации от пользователя), отсутствует техническая возможность решения обращения (заявки), предмет обращения не входит в компетенции технической поддержки, или существует влияние доработки на другие компоненты, что нарушает общий порядок работы Системы Согласование Присваивается при необходимости согласования направления обращения (заявки) ответственным сотрудником Заказчика на 3-й уровень Анализ Присваивается при проведении анализа на предмет возможности внесения изменений, связанных с развитием/улучшением/оптимизацией Системы и выводом новой функциональности и оценке ресурсоемкости Тестирование Присваивается Исполнителем при завершении разработки и проведенном предварительном тестировании для последующего осуществления приемочного тестирования Специалистом 2-го уровня Релиз Присваивается ответственным сотрудником Заказчика при принятии решения о возможности вывода доработки в продуктивную среду Утверждение заказчиком Присваивается при согласовании группой профильных специалистов на 2-м уровне поддержки с пользователем технического задания для внесения изменений, связанных с развитием/улучшением/оптимизацией Системы и выводом новой функциональности Доработка Присваивается в случае несогласования Заказчиком работ, проведенных Исполнителем в рамках контрактных обязательств, по внесению изменений, связанных с развитием/улучшением/оптимизацией Системы и выводом новой функциональности в штатном режиме, и необходимости последующего направления Исполнителю для ее доработки Отложен Присваивается в случае невозможности выполнения запроса, изложенного в обращении (заявке), в связи с необходимостью запроса дополнительной информации у третьих сторон 3.4 Порядок регистрации и сопровождения Заявок Порядок регистрации и сопровождения обращений (заявок) в рамках оказываемых услуг по технической поддержке Системы зависит от типа обращения (заявки): 1. Услуга по решению инцидентов, связанных с работой ППО – тип обращения (заявки) «Инцидент». 2. Услуга по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности – тип обращения (заявки) «Инцидент». 3. Услуга информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы – тип обращения (заявки) «Запрос на обслуживание» (в том числе, консультационный запрос). 4. Услуга адаптационного, конфигурационного и коррекционного сопровождения Системы (в рамках действующих программных модулей и функциональностей) – тип обращения (заявки) «Запрос на изменение». В случае недоступности СРО взаимодействие и информирование Исполнителем о ходе оказания услуги по обращению (заявке), изменению статусов обращений (заявок) осуществляется по согласованию с Заказчиком в соответствии с матрицей взаимодействия, представленной в Приложении 1 к настоящему Регламенту. 3.4.1 Инцидент На рисунке 2 представлена функциональная схема регистрации и сопровождения обращений (заявок) типа «Инцидент». Рисунок 2 - Функциональная схема регистрации и сопровождения обращений (заявок) типа «Инцидент» 3.4.2 Запрос на обслуживание На рисунке 3 представлена функциональная схема регистрации и сопровождения обращения (заявки) типа «ЗНО». Рисунок 3 - Функциональная схема регистрации и сопровождения обращения (заявки) типа «ЗНО» 3.4.3 Запрос на изменение На рисунке 4 представлена функциональная схема регистрации и сопровождения обращений (заявок) типа «ЗНИ». Рисунок 4 - Функциональная схема регистрации и сопровождения обращений (заявок) типа «ЗНИ» 3.5 Порядок классификации и приоритизации обращений (заявок) Классификация является начальной стадией процесса оказания технической поддержки, необходимой для идентификации обращения (заявки) и определения соответствующих действий для его обработки. Для проведения первичной классификации необходимо получить от пользователя и зафиксировать в описании обращения (заявки) подробные сведения о сути запроса, в том числе, для Инцидентов зафиксировать сценарий воспроизведения обнаруженной ошибки. Для проведения вторичной классификации необходимо провести анализ и диагностику для определения корневой причины и затронутой Инцидентом функциональной области (инфраструктура, сеть, ППО). В процессе классификации осуществляется первичная диагностика и оценка проблемы, описанной пользователем Системы в обращении (заявке), в части функционирования и/или удобства использования Системы. Корректная классификация позволяет увеличить скорость обработки обращения (заявки) и решения описанной в обращении (заявке) проблемы при минимальном привлечении ресурсов, в частности, за счет использования известных решений для типовых обращений (заявок), которые должны описываться в БЗ СРО. Классификация позволяет произвести первоначальное назначение обращения (заявки) на ответственного сотрудника и выставить приоритет с учетом приоритизации. Приоритизация применяется для определения критичности описанной в обращении (заявке) проблемы для функционирования ППО Системы. Приоритет рассмотрения обращения (заявки) определяется в процессе ее классификации на основании ряда параметров, вводимых при заполнении обращения (заявки). Приоритизация используется для того, чтобы при одновременном наличии нескольких обращений (заявок) в первую очередь рассматривалась обращения (заявки) с наивысшим приоритетом и не позднее установленных для данного приоритета сроков Изменение приоритета уже зарегистрированного обращения (заявки) используется в случае появления новых обстоятельств, которые ведут к изменению влияния и/или срочности существующего обращения (заявки). При регистрации обращения (заявки) необходимо провести его приоритизацию. В процессе управления обращениями (заявками) каждому обращению (заявке) присваивается приоритет, принимающий одно из значений: Низкий, Средний, Высокий или Критический. В соответствии с приоритетом определяется время, очередность устранения, , ресурсы, привлекаемые для работ по обращению (заявке), а также может определяться порядок/процедура действий при работе с обращением (заявкой). Заказчиком в зависимости от уровня сбоя в работе Системы обращению (заявке) присваивается приоритет с указанием максимального времени реакции и решения в соответствии с требованиями, указанными в Приложении 2 к настоящему Регламенту 4 Формы обращений (заявок) на оказание услуг по технической поддержке Системы, заполняемые в СРО 4.1. Форма обращения (заявки) на оказание услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы При подаче обращения (заявки) типа «ЗНО» в СРО указывается (Таблица 5): Таблица 5 – Описание атрибутов формы обращения (заявки) на оказание услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 5) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 5) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 5) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 5) Категория обращения: информационно-консультационная поддержка Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 5) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 5) Текст запроса на оказание услуги по информационно-консультационной поддержке сотрудников Заказчика Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 5) На рисунке 5 приведена форма обращения (заявки) типа «ЗНО» в СРО. Рисунок 5 - Форма обращения (заявки) типа «ЗНО» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы, заполненную в свободной форме. 4.2. Форма обращения (заявки) на оказание услуги по решению инцидентов, связанных с работой ППО При подаче обращения (заявки) типа «Инцидент» в СРО указывается (Таблица 6): Таблица 6 – Описание атрибутов формы обращения (заявки) на оказание услуги по решению инцидентов, связанных с работой ППО Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 6) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 6) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 6,) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 6) Категория обращения (заявки): инцидент Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 6) Приоритет изменения Время - одно из значений: Низкий, Средний, Высокий или Критический. Определяет, очередность решения обращения (заявки), ресурсы, привлекаемые для решения обращения (заявки), порядок/процедура действий при решении обращения (заявки) – поле СРО «Приоритет» (см. рисунок 6,) Тип изменения Справочник, классифицирующий типовые запросы характерные для Системы – поле СРО «Предмет обращения» (см. рисунок 6) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 6) Полное описание инцидента, включая скриншоты и описание шагов, приведших к неисправности Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 6) Однократность/неоднократность Круг пользователей или компьютеров, затронутых данным инцидентом Действия, предпринятые для самостоятельного решения инцидента (при наличии) Версии используемого программного обеспечения на клиентской рабочей станции, где воспроизводится ошибка (операционная система, прикладное программное обеспечение) Дополнительная информация На рисунке 6 приведена форма обращения (заявки) типа «Инцидент» в СРО. Рисунок 6 - Форма обращения (заявки) типа «Инцидент» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуги по решению инцидентов, связанных с работой ППО, заполненную в свободной форме 4.3. Форма обращения (заявки) на оказание услуг по адаптационному конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) При подаче обращения (заявки) типа «ЗНИ» в СРО указывается (Таблица 7): Таблица 7 – Описание атрибутов формы обращения (заявки) на оказание услуг по адаптационному, конфигурационному и коррекционному сопровождению Системы Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 10) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 9) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 10) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 10) Категория обращения (заявки): запрос на изменение Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 7) Приоритет изменения Время, очередность решения обращения (заявки), ресурсы, привлекаемые для решения обращения (заявки), порядок/процедура действий при решении обращения (заявки) – поле СРО «Приоритет» (см. рисунок 7) Тип изменения Справочник, классифицирующий типовые запросы характерные для Системы – поле СРО «Предмет обращения» (см. рисунок 7) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 7) Текст запроса на оказание услуги по адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 7) На рисунке 7 приведена форма обращения (заявки) типа «ЗНИ» в СРО. Рисунок 7 - Форма обращения (заявки) типа «ЗНИ» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуг по адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей), заполненную в свободной форме 4.4. Форма обращения (заявки) на оказание услуги по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности При подаче обращения (заявки) типа «Инцидент» в СРО указывается (Таблица 8): Таблица 8 – Описание атрибутов формы обращения (заявки) на оказание услуг по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 8) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 8) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 8) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 8) Категория обращения (заявки): инцидент Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 8) Приоритет Время, очередность решения обращения (заявки), ресурсы, привлекаемые для решения обращения (заявки), порядок/процедура действий при решении обращения (заявки) – поле СРО «Приоритет» (см. рисунок 8) Тип изменения Справочник, классифицирующий типовые запросы характерные для Системы – поле СРО «Предмет обращения» (см. рисунок 8) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 8) Текст запроса на оказание услуги по обновлению или удалению уязвимых компонентов (библиотек) ППО в соответствии с требованиями к обеспечению информационной безопасности Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 8) На рисунке 8 приведена форма обращения (заявки) типа «Инцидент» в СРО. Рисунок 8 - Форма обращения (заявки) типа «Инцидент» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуги по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности, заполненную в свободной форме Приложение 1 к Регламенту Матрица ответственных за взаимодействия в рамках выполнения работ по техническому сопровождению Системы Таблица 1 – Ответственные за взаимодействия в рамках выполнения работ по техническому сопровождению Системы со стороны Исполнителя ФИО Должность Адрес электронной почты Телефон — — — Общий контакт Приложение 2 к Регламенту Приоритеты и регламентные сроки решения обращений (заявок) Приоритеты и регламентные сроки решения обращений (заявок) приведены в таблице 1. Таблица 1 – Приоритеты и регламентные сроки решения обращений (заявок) № п/п Приоритет Максимальное время реагирования Время решения (срок выполнения) Описание приоритета По информационно-консультационной поддержке сотрудников Заказчика и пользователей Системы 1 – не более 1 часа не более 10 часов – По решению инцидентов, связанных с работой ППО 1 Критический не более 30 минут не более 4 часов – полная недоступность ППО; – недоступность ключевых функций; – ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО; – невозможность информационного обмена с ППО для ИС более 4 часов 2 Высокий не более 1 часа не более 8 часов – ошибки/сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; – снижение быстродействия СПО (время отклика ППО на операции превышает 30 секунд); – невозможность управления правами и ролями пользователей 3 Средний не более 4 часов не более 24 часов – невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым недоступность функции формирования отчетов 4 Низкий не более 8 часов не более 40 часов – отклонение в работе ППО, не влияющее на корректную работу функций; – другие сбои и ошибки, затрагивающие основные функции ППО По адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) 1 Критический не более 40 минут не более 8 часов – изменения необходимые при проведении аварийно-восстановительных работ для возобновления работоспособности Системы; – изменения, связанные с критичными ошибками, блокирующими возможность оказания государственных услуг и/или чтение и внесение данных в Систему 2 Высокий не более 1 часа не более 40 часов – изменения относящиеся к обеспечению работоспособности основной функциональности Системы, устраняют выявленные дефекты в работе Системы, оказывающие существенное влияние на процесс оказания государственных услуг и работу пользователей в Системе; – изменения, затрагивающие три и более подсистемы/модуля Системы для адаптации 3 Средний не более 4 часов не более 72 часов – изменения, связанные с развитием/улучшением/оптимизацией Системы и выводом новой функциональности в штатном режиме для одного-двух модулей/подсистем; – изменения, связанные с развитием интеграционных механизмов Системы, например, обновление существующих и/или реализация новых видов сведений СМЭВ, обновление существующих и/или реализация новых API, адаптация и/или изменение механизмов импорта и экспорта данных Системы и т.д. 4 Низкий не более 8 часов не более 160 часов – изменения, связанные с ошибками/ корректировкой/изменение в отображении информации в пользовательском графическом интерфейсе Системы (графика, текст, органы управления, элементы интерфейса) По устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности 1 Критический не более 30 минут не более 24 часов – критические уязвимости, влияющие на возможную полную недоступность ППО, ключевых функций Системы, ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО без возможности восстановления работоспособности Системы; – Критический уровень CVSS > 8.0 2 Высокий не более 1 часа не более 84 часов – критические уязвимости, влияющие на ошибки и сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; – Высокий уровень CVSS 5.0 - 8.0 3 Средний не более 4 часов не более 120 часов – уязвимости, влияющие на невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым; – Средний уровень CVSS 2.0 - 4.9 4 Низкий не более 8 часов не более 160 часов – уязвимости, влияющие на отклонение в работе ППО, не влияющее на корректную работу функций; – другие сбои и ошибки, затрагивающие основные функции ППО; – Низкий уровень CVSS < 2.0 Приложение Г Форма Отчета об оказанных услугах Отчет об оказанных услугах за этап «наименование этапа» в период с «__» _________ по «__» _________. № п/п Наименование услуги Общее количество Номер ОРС Краткое Описание Время реагирования по ТЗ Время реагирования фактическое Время решения по ТЗ Время решения фактическое Результат соблюдения времени реагирования Результат соблюдения времени решения Примечание 1 Услуги по информационно-консультационной поддержке работников Заказчика 2 546782 Консультация по работе Модуля СЦ 1 2 10 часов 11 часов Нет Нет 567123 Консультация по схеме БД 1 1 10 часов 1 час Да Да 2 … … Заказчик Подрядчик /Должность/ /Должность/ ____________________ /Ф.И.О/ ___________________ /Ф.И.О/ М.П. М.П. «_____»_______________________202_г. «_____»_______________________202_г Приложение 1 к Отчету об оказанных услугах Журнал обращений (заявок) на оказание услуги по информационно-консультационной поддержке пользователей Системы (шаблон) Наименование Исполнителя в этапе «наименование этапа» в период с ________________ по _______________ оказал(о) Услугу по поддержке пользователей Системы в объеме, указанном в Таблице 1 Таблица 1 - Журнал обращений (заявок) пользователей Системы № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. ИТОГО зарегистрировано: Всего обращений (заявок): ________ ИТОГО решено: Всего обращений (заявок): ________ Приложение 2 к Отчету об оказанных услугах Журнал обращений (заявок) по решению инцидентов, связанных с работой ППО (шаблон) Наименование Исполнителя в этапе «наименование этапа» в период с ________________ по _______________ оказал(о) Услугу по решению инцидентов в объеме, указанном в Таблице 1. Таблица 1 - Журнал по решению инцидентов № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. ИТОГО зарегистрировано: Всего инцидентов: ________ ИТОГО решено: Всего инцидентов: ________ Приложение 3 к Отчету об оказанных услугах Журнал обращений (заявок) выполнения адаптационного, конфигурационного и коррекционного сопровождения Системы (шаблон) Журнал выполнения адаптации, конфигурации и коррекции Системы сформирован за этап «наименование этапа» в период с «__» _________ по «__» ____________ и представлен в таблице ниже (Таблица 1). Таблица 1 - Журнал выполнения адаптации, конфигурации и коррекции сопровождения Системы № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. Количество выполненных заявок за этап: ________ Приложение 4 к Отчету об оказанных услугах Журнал обращений (заявок) по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности (шаблон) Журнал обращений (заявок) по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности сформирован за этап «наименование этапа» в период с «__» _________ по «__» ____________ и представлен в таблице ниже (Таблица 1). Таблица 1 - Журнал выполнения заявок по устранению уязвимостей в ППО № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. Количество выполненных заявок за этап: ________ Приложение Д Форма Протокола проверки результатов организационно-штатных и подготовительных мероприятий (шаблон) Протокол проверки результатов организационно-штатных и подготовительных мероприятий Настоящий Протокол содержит результаты проверки организационно-штатных и подготовительных мероприятий, проведенных Исполнителем (Таблица Д.1). Таблица Д.1. Протокол проверки результатов № Мероприятия Подготовительного этапа Результат проверки 1. Определить и направить Заказчику документ «Ответственные за взаимодействия в рамках выполнения работ по техническому сопровождению Системы со стороны Исполнителя». Документ содержит контактную информацию (ФИО, должность, адрес электронной рабочей почты, номер телефона) не менее чем о 2 лицах, ответственных за оказание услуг со стороны Подрядчика Выполнено/Не выполнено 2. Обеспечить подключение специалистов Подрядчика к Системе Выполнено/Не выполнено 3. Обеспечить подключение специалистов Подрядчика к СРО Выполнено/Не выполнено Заказчик Подрядчик /Должность/ /Должность/ ____________________ /Ф.И.О/ ___________________ /Ф.И.О/ М.П. М.П. «_____»_______________________202_г. «_____»_______________________202_г - Наименование характеристики - Значение характеристики - Единица измерения характеристики - Инструкция по заполнению характеристик в заявке - ОПРЕДЕЛЕНИЯ, ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ - Автоматизированная система (АС) Система, состоящая из комплекса средств автоматизации, реализующего информационную технологию выполнения установленных функций, и персонала, обеспечивающего его функционирование (ГОСТ Р 59853-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения») АРМ Автоматизированное рабочее место АСУ ТК, Система Информационно-аналитическая система регулирования на транспорте АТС Автоматическая телефонная станция БД База данных ГИС Государственная информационная система ГОСТ Государственный стандарт ГЦОД СИЦ Минтранса России, ГЦОД Головной центр обработки данных ФГБУ «СИЦ Минтранса России» Дашборд Интерактивная аналитическая панель, графический интерфейс. ЕИС Единая информационная система в сфере закупок ЕСИА Единая система идентификации и аутентификации Заказчик Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» КИИ Критическая информационная инфраструктура Кластер Кла?стер (англ. cluster) – объединение нескольких однородных элементов, которое может рассматриваться как самостоятельная единица, обладающая определёнными свойствами Компонент Часть АС, выделенная по определенному признаку или совокупности признаков и рассматриваемая как единое целое (ГОСТ Р 59853-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения») Контракт Контракт на выполнение работ по развитию и оказанию услуг по технической поддержке Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК в 2026 году, заключаемый по результатам проведения конкурентной процедуры закупки в соответствии с требованиями Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» - - Значение характеристики не может изменяться участником закупки - Модуль iМинтранс Модуль сбора данных и представления показателей деятельности Министерства транспорта Российской Федерации iМинтранс АСУ ТК Модуль СЦ Модуль сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК НС Нештатная ситуация НСИ Нормативно-справочная информация ОТИ Объект транспортной инфраструктуры П-ГИС Геоинформационная подсистема П-ИВ Подсистема информационного взаимодействия П-НСИ Подсистема ведения нормативно-справочной информации и метаданных ПО Программное обеспечение Подрядчик, Исполнитель Организация, с которой будет заключен контракт на выполнение работ по развитию Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК П-СД Подсистема сбора данных Работы Работы по развитию Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК СЗИ Средство защиты информации СМЭВ Система межведомственного электронного взаимодействия СУБД Система управления базами данных ТЗ Техническое задание (настоящий документ) ТС Транспортное средство ТК Транспортный комплекс Учреждение Учреждения в области информационной безопасности - ФГБУ «СИЦ Минтранса России» Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации», Заказчик Федеральный закон № 44-ФЗ Федеральный закон от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» ФЗ Функциональная задача ФЗ «Реестр объектов» Функциональная задача «Формирование и ведение единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации» ФСБ России Федеральная служба безопасности Российской Федерации ФСТЭК России Федеральная служба по техническому и экспортному контролю ЧС Чрезвычайная ситуация ЭВМ Электронно-вычислительная машина API От англ. Application Programming Interface – интерфейс прикладного программирования – совокупность инструментов и функций в виде интерфейса для взаимодействия с программой CSS От англ. Cascading Style Sheets — каскадные таблицы стилей FPS От англ. frame per second - количество кадров в секунду HTML От англ. HyperText Markup Language - стандартный язык разметки документов, создающий основу и структуру всех веб-страниц JSON От англ. JavaScript Object Notation – текстовый формат обмена данными, основанный на JavaScript WebAssembly (Wasm) Открытый стандарт, представляющий собой низкоуровневый бинарный формат инструкций, который позволяет выполнять код, написанный на языках C++, Rust или Go, в браузерах с производительностью, близкой к нативной - 1. ОБЩИЕ СВЕДЕНИЯ - 1.1. Наименование Системы Полное наименование системы: Информационно-аналитическая система регулирования на транспорте. Условное обозначение системы: АСУ ТК. Полное наименование модуля: Модуль сбора, ведения и анализа информации о нештатных ситуациях на транспорте. Условное обозначение модуля: Модуль СЦ. Модуль СЦ создан в рамках контракта от 05.08.2024 № ОК/24_04 на выполнение работ по развитию АСУ ТК в части создания модуля «Сбора, ведения и анализа информации о нештатных ситуациях на транспорте». Развитие Модуля СЦ осуществлено в рамках контракта от 19.05.2025 № ОК/25_09 на выполнение работ по развитию Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК - - Значение характеристики не может изменяться участником закупки - 1.2. Шифр темы или номер контракта Присваивается Заказчиком по результатам организации закупочных процедур. 1.2.1. Предмет контракта Выполнение работ по развитию Модуля СЦ. Код по ОКПД2: 62.01.11.000 – услуги по проектированию и разработке информационных технологий для прикладных задач и тестированию программного обеспечения. Оказание услуг по технической поддержке Модуля СЦ. Код по ОКПД2: 62.02.30.000 – услуги по технической поддержке информационных технологий. Выполнение работ по развитию Модуля СЦ предусмотрено с учетом ключевых результатов (ОКР) Ведомственной программы цифровой трансформации Минтранса России на 2026-2028 (далее - ВПЦТ Минтранса России) в составе мероприятия № 103.002 «АСУ ТК» ИТ расхода 103.26.000005 «Развитие Информационно-аналитической системы регулирования на транспорте (АСУ ТК)»: · «Обеспечено информационное взаимодействие с Минобороны о происшествиях на транспортных объектах»; · «Обеспечена автоматизация формирования отчетов о нештатных ситуациях на транспорте, в том числе по данным внешних систем». Выполнение работ по технической поддержке АСУ ТК предусмотрено ВПЦТ Минтранса России в составе мероприятия № 103.002 «АСУ ТК» ИТ расхода 103.26.000021 «Эксплуатация Информационно-аналитической системы регулирования на транспорте (АСУ ТК)» - 1.3. Заказчик Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» (ФГБУ «СИЦ Минтранса России»). Адрес: 107078, Москва, Садовая-Спасская ул., д.18, стр. 1. Оператором Системы является Заказчик - Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» (ФГБУ «СИЦ Минтранса России) - 1.4. Подрядчик Определяется по результатам проведения конкурентной процедуры закупки в соответствии с требованиями Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (далее – Федеральный закон № 44-ФЗ) - 1.5. Основания для выполнения работ Работы осуществляются на основании следующих документов: – постановление Правительства Российской Федерации от 30.12.2003 № 794 «О единой государственной системе предупреждения и ликвидации чрезвычайных ситуаций»; – постановление Правительства Российской Федерации от 08.11.2013 № 1007 «О силах и средствах единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций»; – распоряжение Правительства Российской Федерации от 27.11.2021 № 3363-р «О Транспортной стратегии Российской Федерации до 2030 года с прогнозом на период до 2035 года»; – Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 26.08.2025 №ЕФ-3; – Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 27.11.2025 №ЕФ-23; - – Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 19.02.2026 №ЕФ-1; – План мероприятий по профилактике случаев непроизводственного травматизма граждан на железнодорожном транспорте, являющийся приложением к постановлению коллегии Министерства транспорта Российской Федерации от 11.03.2026 № 2 - 1.6. Перечень документов, требования которых должны быть учтены при выполнении работ – Федеральный закон Российской Федерации от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации»; – Федеральный закон Российской Федерации от 27.07.2006 № 152-ФЗ «О персональных данных»; – Федеральный закон Российской Федерации от 06.04.2011 № 63-ФЗ «Об электронной подписи»; – Федеральный закон Российской Федерации от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации»; – Указ Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации»; – Указ Президента Российской Федерации от 01.05.2022 № 250 «О дополнительных мерах по обеспечению информационной безопасности Российской Федерации»; – Указ Президента Российской Федерации от 31.03.2010 № 403 «О создании комплексной системы обеспечения безопасности населения на транспорте»; – постановление Правительства Российской Федерации от 30.07.2004 № 395 «Об утверждении Положения о Министерстве транспорта Российской Федерации»; – постановление Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации»; – постановление Правительства Российской Федерации от 16.11.2015 № 1236 «Об установлении запрета на допуск программного обеспечения, происходящего из иностранных государств, для целей осуществления закупок для обеспечения государственных и муниципальных нужд»; – постановление Правительства Российской Федерации от 23.12.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 Федерального закона «Об электронной подписи»; - – постановление Правительства Российской Федерации от 08.06.2011 № 451 «Об инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг и исполнения государственных и муниципальных функций в электронной форме»; – постановление Правительства Российской Федерации от 30.01.2013 № 62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин»; – приказ ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации»; – приказ ФСТЭК России от 11.04.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений»; – приказ ФСБ России от 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.7. Сроки начала и окончания работ Начало работ: с даты заключения Контракта. Окончание работ: не позднее 15.12.2026. Работы выполняются в соответствии с этапами. Сроки выполнения этапов работ по развитию и технической поддержке Модуля СЦ определяются Календарным планом. Календарный план, приведен в разделе 5 настоящего ТЗ - 1.8. Общие сведения об источниках и порядке финансирования работ Источником финансирования являются средства субсидии федерального бюджета Российской Федерации, предоставленной в соответствии с абзацем вторым пункта 1 статьи 78.1 Бюджетного кодекса Российской Федерации (код цели 08-01) - 1.9. Порядок оформления и предъявления результатов работ Подрядчик должен передать Заказчику результаты работ в порядке, определенном Контрактом в сроки, установленные п. 5 настоящего ТЗ, в соответствии с Календарным планом - 1.10. Место выполнения Работ Работы выполняются удаленно на комплексе технических средств Заказчика. Адрес размещения комплекса технических средств Заказчика: Московская обл., Богородский район, пос. Горбуша, Радиоцентр. Техническая возможность удаленного подключения обеспечивается Заказчиком (в части предоставления параметров доступа). Оплата телематических и иных услуг, технических и программных средств, необходимых Подрядчику для удаленного подключения и для выполнения требований по информационной безопасности, осуществляется Подрядчиком самостоятельно за свой счет - 2. ЦЕЛИ И НАЗНАЧЕНИЕ ВЫПОЛНЕНИЯ РАБОТ - 2.1. Назначение АСУ ТК АСУ ТК предназначена для автоматизации и информационно-аналитического обеспечения процессов управления развитием транспортного комплекса Российской Федерации, обеспечения публичности деятельности органов государственного управления транспортным комплексом. Основными целями АСУ ТК являются: – повышение эффективности процессов управления функционированием и развитием транспортного комплекса на основе создания единой информационной среды и комплекса информационно-аналитических услуг на уровне органов государственного управления ТК; – повышение уровня безопасности ТК на базе получения полной, достоверной и оперативной информации о происходящих изменениях, своевременного выявления негативных тенденций и для принятия соответствующих мер по их устранению и ликвидации последствий - - Значение характеристики не может изменяться участником закупки - Основными задачами АСУ ТК являются: – автоматизация процессов прогнозирования развития транспортного комплекса и поддержки принятия управленческих решений; – автоматизация процессов мониторинга безопасности и устойчивости транспортного комплекса, управления в чрезвычайных и нештатных ситуациях; – автоматизация процессов управления программами и проектами развития и модернизации транспортного комплекса; – автоматизация процессов мониторинга состояния транспортного комплекса, в том числе с использованием набора ключевых показателей эффективности деятельности транспортного комплекса; – информационно-технологическая поддержка взаимодействия субъектов транспортного комплекса Российской Федерации, органов государственного управления и контроля, международных организаций на основе создания единой технологической среды взаимодействия и управления движением данных (и связанных с ними документов) в транспортном комплексе; – использование в процессах управления транспортным комплексом РФ современных технологий электронного документооборота и электронного обмена данными; – организация межведомственного электронного взаимодействия подразделений Министерства транспорта Российской Федерации, подведомственных агентств и службы с другими организациями - 2.2. Назначение и цели развития и технической поддержки Модуля СЦ Назначение Модуля СЦ: – оперативный мониторинг нештатных и чрезвычайных ситуаций на транспорте ; – оповещение заинтересованных лиц и структур о нештатных и чрезвычайных ситуациях; – сбор, обработка и хранение данных о нештатных и чрезвычайных ситуациях. Целями развития Модуля СЦ являются: – расширение состава данных об оперативной обстановке на транспорте; – оптимизация процесса сбора данных об оперативной обстановке на транспорте; – повышение информированности пользователей за счет визуализация данных Модуля СЦ; – автоматизация процесса формирования отчетов о ЧС и нештатной ситуации на транспорте; – обеспечение информационного взаимодействия с заинтересованными организациями по вопросам ведения. - Целями оказания услуг по технической поддержке являются: – обеспечение информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы; – поддержание параметров функционирования ППО Системы, удовлетворяющих требованиям производственных процессов, включая их непрерывность; – обеспечение бесперебойного функционирования ППО и своевременное устранение сбоев и аварийных ситуаций в Системе; – своевременное устранение уязвимостей при выявлении таковых, в соответствии с требованиями к обеспечению информационной безопасности; – адаптация, конфигурирование, коррекция программного обеспечения в соответствии с изменениями нормативно-правовой базы и запросами уполномоченных сотрудников органов государственной власти, включая выполнение процедур тестирования и участие в обновлениях ППО на стендах Заказчика; – обеспечение сохранения работоспособности ППО в изменяемой среде эксплуатации; – ведение документации по настоящему ТЗ, инициирование и актуализация документации на Систему по результатам обработки запросов Заказчика и внесении соответствующих изменений в ППО. Модуль СЦ применяется в деятельности Министерства транспорта Российской Федерации, подведомственных агентств и службы и другими организациями в соответствии с соглашениями об информационном обмене - 3. ХАРАКТЕРИСТИКА ОБЪЕКТА АВТОМАТИЗАЦИИ - 3.1. Описание объекта автоматизации АСУ ТК Объектом автоматизации являются процессы основной и обеспечивающей деятельности, направленные на управление транспортным комплексом, в том числе, процессы информационного взаимодействия с другими организациями и субъектами транспортного комплекса. АСУ ТК относится к государственным информационным системам, а также к информационным системам персональных данных и значимым объектам критической информационной инфраструктуры Российской Федерации. АСУ ТК соответствует требованиям, предъявляемым к: – ГИС второго класса защищенности в соответствии с приказом ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах»; – ИС персональных данных при обеспечении третьего уровня защищенности персональных данных в соответствии с требованиями постановления Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»; – значимым объектам КИИ Российской Федерации второй категории значимости с постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении Правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений». Модуль СЦ является подсистемой АСУ ТК. Перечень платформенных решений и функциональных задач АСУ ТК представлен в Таблице 1 - - Значение характеристики не может изменяться участником закупки - Таблица 1 – Перечень платформенных решений и функциональных задач АСУ ТК № Наименование подсистемы/ функциональной задачи/ модуля Назначение 1 Подсистема сбора данных и централизованного хранилища данных Подсистема обеспечивает выполнение сбора данных в АСУ ТК, и в т. ч., в рамках функциональных задач «Формирование и ведение межрегионального транспортного баланса пассажирских перевозок в дальнем (межрегиональном) сообщении» и «Формирование и ведение транспортного паспорта региона» 2 Подсистема информационного взаимодействия Подсистема информационного предназначена для обеспечения информационного взаимодействия подсистем АСУ ТК, а также, взаимодействия АСУ ТК с АС федеральных органов исполнительной власти 3 Подсистема ведения нормативно-справочной информации и метаданных Подсистема предназначена для автоматизации функций формирования и актуализации справочников, классификаторов, реестров и регистров, необходимых для обеспечения информационной поддержки пользователей НСИ и интеграции подсистем АСУ ТК в части применения НСИ 4 Модуль СМЭВ Модуль взаимодействия со СМЭВ представляет собой набор сервисов взаимодействия: сервис синхронного взаимодействия и сервис отправки, осуществляющих дополнительную обработку сообщений, отправляемых в СМЭВ и принимаемых из СМЭВ 5 Геоинформационная подсистема Программное обеспечение геоинформационной подсистемы предназначено для обеспечения смежных подсистем АСУ ТК возможностью работы с картографической информацией, в том числе, отображения на электронных картах объектов транспортной инфраструктуры и получения информации о местоположении, характеристиках контролируемых транспортных объектов 6 Подсистема информационного портала АСУ ТК Подсистема информационного портала предназначена для отображения и входа в функциональные задачи АСУ ТК 7 Подсистема технического портала АСУ ТК Подсистема технического портала АСУ ТК предназначена для управления заявками пользователей и технологического документооборота заявок - 8 Подсистема проектного архива АСУ ТК Подсистема проектного архива АСУ ТК предназначена для автоматизации деловых процессов должностных лиц Министерства транспорта Российской Федерации, подведомственных агентств и службы, в том числе, и процессов информационного взаимодействия внутреннего и внешнего характера 9 ФЗ «Реестр объектов» Функциональная задача предназначена для формирования и ведения единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации 10 ФЗ «СТП» Функциональная задача предназначена для организации информационно-аналитической поддержки процессов территориального планирования Российской Федерации в области федерального транспорта 11 ФЗ «МРТБ ПП» Функциональная задача предназначена для формирования и ведения межрегионального транспортного баланса пассажирских перевозок в дальнем (межрегиональном) сообщении 12 ФЗ «МДД» Функциональная задача предназначена для осуществления мониторинга дорожного движения 13 ФЗ «ТПР» Функциональная задача предназначена для формирования и ведения транспортного паспорта региона 14 ФЗ «Данные по грузообороту» Функциональная задача предназначена для обеспечения подсистем и пользователей АСУ ТК данными по грузообороту между Российской Федерацией и зарубежными странами 15 ФЗ «МЖТ» Функциональная задача предназначена для осуществления мониторинга железнодорожного транспорта 16 ФЗ «МГМП» Функциональная задача предназначена для осуществления мониторинга грузопотоков в морских портах с целью формирования единой цифровой среды мониторинга и планирования перевозок в/из портов Дальнего Востока - 17 Модуль ГЭТ Модуль предназначен для получения, хранения данных инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по отдельно взятому предприятию-перевозчику. Формирования отчетов об инвентаризации с детальными данными по каждому разделу инвентаризации с маршрутизацией в муниципалитет / регион / Минтранс. Содержит агрегированные данные инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по всем перевозчикам, относящихся к данному муниципалитету. Формирует сводный отчет по муниципалитету по каждому разделу инвентаризации с маршрутизацией в регион / Минтранс. Формирует агрегированные данные инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по всем перевозчикам, относящиеся к данному региону и по всем муниципалитетам, относящимся к данному региону. Аналитические и статистические данные о состоянии ГЭТ региона. Содержит данные о видах транспорта, цифровых транспортных сервисах и платежных инструментах Региона. Формирует сводный отчет по каждому разделу инвентаризации с маршрутизацией в Минтранс. Формирует агрегированную статистику и аналитику по всем регионам страны в разрезе транспортных средств, маршрутов, пассажиропотоков, инфраструктуры ГЭТ. Данные о рейтинге регионов и перевозчиков на основании выбранных параметров, документооборот с участниками Системы: получение подписанных печатных форм, их утверждение, возврат на доработку. 18 Модуль iМинтранс Модуль создан для отчета по ключевым показателям транспортного комплекса России (Отраслевые и статистические показатели, исполнение бюджета, исполнение поручений, аналитика СМИ, происшествия по видам транспорта). 19 Модуль СЦ Модуль СЦ предназначен для оперативного мониторинга нештатных ситуаций транспортной отрасли, оповещения заинтересованных лиц и структур и предоставления данных о нештатных ситуациях - АСУ ТК осуществляет идентификацию и авторизацию посредством Единой системы идентификации и аутентификации (ЕСИА). Информационный обмен с внешними информационными системами осуществляется посредством СМЭВ 3 и СМЭВ 4. АСУ ТК развернута на вычислительных мощностях ГЦОД СИЦ Минтранса России - 3.2. Описание и текущее состояние объекта автоматизации Модуля СЦ Объектом автоматизации является процесс организации мониторинга информации о НС и ЧС на транспорте. Предметом деятельности Учреждения являются следующие функции: – информационное обеспечение в области транспортной безопасности, защиты населения и территорий от чрезвычайных ситуаций природного и техногенного характера в транспортном комплексе; – подготовка справочных материалов при угрозе возникновения и возникновении чрезвычайных ситуаций и иных происшествий в транспортном комплексе; – взаимодействие и обмен оперативной информацией с органами управления Единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций; – организация оперативного мониторинга обстановки на объектах транспорта при угрозе и возникновении чрезвычайных ситуаций и иных происшествий. Перечень компонентов Модуля СЦ и выполняемые ими функции представлены в Таблице 2 - Таблица 2. Перечень компонентов Модуля СЦ и их функции № п/п Компонент Выполняемые функции 1 Регистрация событий – ведение карточки события; – удаление комментария; – динамическое отображение существующих событий в заданном радиусе и за заданный период; – возможность автоматической проверки вводимых данных в части количества пострадавших; – отображение карточки ОТИ, ТС в соответствии с ФЗ Реестр объектов; – сохранение и отображение версии карточки события; – привязка события к координатам по картографической основе; – указание признака выполнения действия по отработке события; – перевод статуса события; – закрытие карточки события; – публикация информации о событии в канале мессенджера; – возможность перехода из карточки события на картографическую основу для просмотра местоположения события 2 Визуализация – отображение событий на картографической основе в виде пиктограмм; – масштабирование карты; – отображение краткой карточки события при выборе события на картографической основе; – отображение списка событий; – отображение карточки события; – отображение журнала действий пользователя; – отображение дополнительной информации (текстовая информация и приложенные файлы); – отображение справки о событиях и отчета о событиях; – отображение фильтров и количества отфильтрованных объектов; – отображение результатов поиска; – отображение статистики по событиям на экране; – возможность создания события с картографической основы; – отображения картографических слоев в зависимости от примененных фильтров; – возможность настройки шага картографической сети; – возможность настройки географической точки центра карты; – отображение количества непрочитанных сообщений; – возможность перехода к детальной карточке события из краткой карточки события при выборе события на картографической основе - 3 Информирование – ведение справочника способов оповещения (веб-интерфейс, мессенджер); – формирование сценария выполнения оповещения (настройка условий, способа, параметров оповещения); – выполнение оповещений пользователей 4 Отчетность – формирование отчета и справки о событиях; – фильтрация событий для выгрузки в справку о событиях или в отчет о событиях 5 Администрирование – ведение ролей пользователей; – ведение учетных данных пользователей; – ведение справочника организаций; – ведение справочника групп системы мгновенного обмена сообщениями; – выполнение исходящего звонка на контактный телефонный номер организации; – формирование матрицы эскалации событий Архитектура Модуля СЦ представлена на рисунке 1. Рисунок 1. Архитектура Модуля СЦ - 3.3. Состав используемого ПО Модуля СЦ Программная архитектура Модуля СЦ разработана как трехуровневая клиент-серверная архитектура. Архитектура включает в себя следующие уровни: • уровень представления – презентационный уровень, обеспечивающий взаимодействие с пользователя с клиентскими приложениями с использованием веб-браузера («тонкий» клиент); • уровень приложений – реализован в виде сервисов, обеспечивает обработку запросов, поступающих от клиентских приложений, формирование ответов на запрос в доступном пользователю виде (формирование пользовательских интерфейсов); • уровень хранения данных – реализуется как сервер БД и обеспечивает хранение и целостность хранимых данных, создание резервных копий, ведение журнала транзакций, восстановление данных после сбоев. Программная архитектура Модуля СЦ включает в себя сервисы и интерфейсы, указанные в Таблице 3. Таблица 3. Программная архитектура Модуля СЦ Программный сервис/интерфейс Технологии реализации Уровень представления Интерфейс пользователя и администратора (front-end) Javascript Уровень приложений Сервис (GateWay) Kotlin Сервис геокодирования (geocoding-service) Kotlin Сервис уведомлений (notifiсation-service) Kotlin Сервис работы с файлами (file-service) Kotlin Сервис отчетности (report-service) Kotlin Сервис управления событиями (event-service) Kotlin Сервис информирования через мессенджер (messenger-notifier) Python Сервис внешних интеграций (integration-service) Сбор информации из внешних систем и сервисов Брокер сообщений Kafka Уровень хранения данных Файловое хранилище MinIO S3 СУБД Postgres Pro Enterprise - 3.4. Информационное взаимодействие программных сервисов и интерфейсов Модуля СЦ Объект автоматизации функционирует в распределенной информационной среде. Обмен данными осуществляется по защищенным каналам связи (в том числе ведомственным сетям передачи данных). Источники информации включают: · внешние автоматизированные системы (органов государственной власти); · внутренние базы данных (реестры объектов транспортной инфраструктуры, паспорта регионов и пр.); · оперативная информация от персонала, поступающая через автоматизированные рабочие места (АРМ) и мобильные устройства. 3.4.1. Взаимодействие Модуля СЦ со смежными подсистемами АСУ ТК Модуль СЦ входит в состав АСУ ТК и взаимодействует со следующими ее функциональными задачами и подсистемами: · Функциональной задачей «Формирование и ведение единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации» (ФЗ «Реестр объектов»); · Геоинформационной подсистемой АСУ ТК (П-ГИС); · Подсистемой ведения нормативно-справочной информации и метаданных (П-НСИ); · Подсистемой сбора данных и централизованное хранилище данных (П-СД); · Подсистемой информационного взаимодействия (П-ИВ). 3.4.2. Взаимодействие с внешними информационными системами Список внешних информационных систем, с которыми осуществляется взаимодействие Модуля СЦ: · ЕСИА; · мессенджер; · Яндекс Геокодер; · Информационная система «Централизованная система сбора информации систем-112»; · ПВК «Поиск-Море», АИС РПТ; · облачная АТС - 3.5. Требования к эксплуатации Применяемое в Системе программное обеспечение, программно-аппаратные и аппаратные комплексы должны соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации» - 4. ТРЕБОВАНИЯ К МОДУЛЮ СЦ - 4.2.4.1. Требования к технической реализации компонента «Интерактивная карта» При реализации компонента «Интерактивная карта» должны учитываться требования, указанные ниже. 4.2.4.1.1. Требования к отображению элементов Повторяющихся элементы карты (ТС, ОТИ, события и пр.) должны отрисовываться с использованием аппаратного создания экземпляров объектов на пользовательском устройстве (WebGL/WebGPU)). Отрисовка каждого объекта отдельным запросом не допускается, должна обеспечиваться возможность одновременного отображения не менее 5 000 объектов без снижения производительности (30 кадров в секунду на тестовой конфигурации). 4.2.4.1.2. Уровни детализации объектов Для управления отображением сложных объектов должно быть создано не менее 3-х уровней детализации, отображаемых при изменении масштаба с возможностью автоматического переключения между уровнями. Все отображаемые объекты должны масштабироваться с учетом разрешения экрана пользователя с сохранением качества детализации. 4.2.4.1.3. Полигональная оптимизация и текстурирование При реализации компонента «Интерактивная карта» должна обеспечиваться технология рельефного тестурирования объектов. Не должны использоваться высокополигональные трехмерные модели. Все повторяющиеся элементы должны генерироваться единоразово и повторно использоваться при последующих отображениях. 4.2.4.1.4. Управление памятью Требуется реализовать потоковую загрузку на устройство пользователя элементов карты и текстур. Загрузка данных целиком при старте приложения не допускается. Необходимо реализовать механизм очистки памяти от элементов, которые находятся вне области видимости камеры в течение заданного времени. 4.2.4.1.5. Требования к взаимодействию пользователя с интерфейсом компонента «Интерактивная карта» Программная реализация механизмов управление камерой (масштабирование и навигация) должна быть выполнена с поддержкой технологии WebAssembly (WASM). Элементы управления должны являться неотъемлемой частью интерактивной карты. - - Значение характеристики не может изменяться участником закупки - 4.2.5. Развитие компонента администрирования (3 очередь) Должна быть выполнена доработка ролевой модели. Ролевая модель должна обеспечивать управление доступом к отдельным объектам Модуля СЦ и их элементам (атрибутам) с разграничением по видам транспорта, регионам и пр., в частности: – определение набора конкретных действий, доступных пользователям (выполняемых над объектом доступа, например, удаление записи, редактирование записи, формирование отчета и др.); – реализация возможности объединения пользователей в группы; – определение прав доступа для групп пользователей; – реализация интерфейса визуальной настройки прав доступа пользователей к объектам Модуля СЦ - Технические меры по обеспечению надежности должны предусматривать: – резервирование критически важных компонентов и данных Системы и отсутствие единой точки отказа; – использование программного резервирования (программной избыточности); – изменение конфигурации используемых средств и применение специализированного ПО, обеспечивающего высокую надёжность. Организационные меры по обеспечению надежности должны быть направлены на минимизацию ошибок пользователей (а также обслуживающего персонала при эксплуатации и проведении работ по обслуживанию), минимизацию времени ремонта или замены вышедших из строя компонентов за счёт: – обеспечения для обслуживающего персонала требуемого уровня квалификации; – регламентации и нормативного обеспечения выполнения работ обслуживающим персоналом; – своевременной диагностики неисправностей. Расчетное значение коэффициента доступности Модуля СЦ должно составлять не менее 0,95. - 4.5.3. Требования по диагностированию Модуля СЦ Диагностирование Модуля СЦ должно осуществляться путем анализа записей в системных журналах СУБД, операционных систем серверов, а также с помощью встроенных средств диагностирования общего программного обеспечения Модуля СЦ. Диагностированию подлежат: – сбои и нарушения функционирования технического обеспечения (серверов) Модуля СЦ; – сбои и нарушения функционирования системного программного обеспечения серверов, используемых для работы Модуля СЦ; – сбои и нарушения функционирования прикладного программного обеспечения серверов, используемых для работы Модуля СЦ; – случаи недоступности (отсутствия ответа) или некорректные ответы внешних систем; – сбои и нарушения функционирования СУБД; – сбои при выполнении регламентных операций резервного копирования. При возникновении аварийных ситуаций либо ошибок в программном обеспечении диагностические инструменты должны позволять сохранять набор информации, необходимой для идентификации и устранения проблемы. Модуль СЦ и ее компоненты должны обеспечивать возможность диагностики своей работоспособности с возможностью интеграции с модулем мониторинга АСУ ТК. Набор передаваемых журналов и метрик должен быть определен на этапе технического проектирования - 4.5.4. Требования к надежности Должно быть предусмотрено сохранение работоспособности Модуля СЦ при некорректных действиях пользователя и сохранение целостности данных при нештатном завершении работы Модуля СЦ (отказ рабочей станции, потеря сетевого доступа и т.п.). Модуль СЦ должен предоставлять механизмы обеспечения сохранности данных через применение процедур резервного копирования и восстановления, описанных в документации на Систему. Ключевые показатели надежности информационной системы — допустимое время на восстановление работоспособности Модуля СЦ (RTO - recovery time objective) и/или допустимый интервал времени потери изменений в данных при сбоях/отказах (RPO – recovery point objective) должны быть определены Подрядчиком и согласованы с Заказчиком на этапе технического проектирования - 4.2.6. Взаимосвязи с внешними автоматизированными системами (1 очередь) Способы взаимодействия с внешними информационными системами должны быть определены на этапе технического проектирования. Должны быть выполнены следующие доработки: – интеграции с информационными ресурсами в целях получения данных о движении подвижных ТС (воздушные суда, суда водного транспорта); – интеграция с информационным ресурсом в целях получения данных о событиях на железнодорожном транспорте. Реализация интеграций должна включать проектирование и реализацию интеграционных механизмов обмена данными с учетом доступных вариантов реализации, обеспечение защищенных способов взаимодействия, настройку отображения отдельных данных на карте (настройка слоев). Взаимодействия, имеющие каналы связи, выходящие за пределы контролируемой зоны взаимодействующих систем, считаются защищенными, если для их защиты используются программные и/или программно-аппаратные шифровальные (криптографические) средства, сертифицированные ФСБ России (далее – СКЗИ). Выбор СКЗИ, схемы подключения и требуемого класса криптостойкости должен производиться в соответствии с Техническими условиями на подключение к информационным ресурсам ФГБУ «СИЦ Минтранса России» и инструкциями по подключению пользователей к ресурсам инфраструктуры Головного центра обработки данных, утвержденных приказом директора ФБГУ «СИЦ Минтранса России» от 24.05.2024 № 21-ОД - 4.3. Требования к оказанию услуг по технической поддержке Модуля СЦ 4.3.1. Общие требования к оказанию Услуг Техническая поддержка Модуля СЦ должна осуществляться с учетом требований постановления Правительства Российской Федерации от 06.07.2015 N 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации». Подрядчик обязан выполнять требования законодательства в сфере защиты информации, требования по защите информации, информационной безопасности, указанные в локальных нормативных актах ФГБУ «СИЦ Минтранса России», регламентирующих условия информационного взаимодействия, защиты информации и подключения к информационным ресурсам ФГБУ «СИЦ Минтранса России», участвующих в информационном взаимодействии в рамках оказания услуг по технической поддержке АСУ ТК в 2026 году - 4.3.1.1. Требования к составу и содержанию услуг третьего уровня технической поддержки Оказание услуг по технической поддержке Системы осуществляется в рамках этапов в соответствии с календарным планом. Подрядчик в течение 5 рабочих дней с даты заключения Контракта должен предоставить со своей стороны, а Заказчик со своей стороны Матрицу ответственных за взаимодействия в соответствии с Приложением 1 к Регламенту оказания услуг по третьему уровню технической поддержки Модуля СЦ (далее – Регламент, Приложение В). Подрядчик в течение 10 рабочих дней с даты заключения Контракта должен провести мероприятия по организации третьего уровня технической поддержки в соответствии с Регламентом. Услуги по третьему уровню технической поддержки Модуля СЦ должны включать: – организацию Подрядчиком третьего уровня технической поддержки; – информационно-консультационную поддержку работников Заказчика; – решение инцидентов, связанных с работой ППО; – адаптационное, конфигурационное и коррекционное сопровождение Модуля СЦ (в рамках действующих программных модулей и функциональности); – устранение уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности - 4.5.5. Требования к информационной безопасности Работы по защите информации/информационной безопасности, не включенные в состав настоящего раздела, требуемые в соответствии с требованиями постановления Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации», а также нормативно правовых актов в области защиты персональных данных и обеспечения безопасности объектов критической информационной инфраструктуры, будут проведены в рамках исполнения отдельного контракта, заключенного по результатам отдельной закупочной процедуры (не является частью данного ТЗ), включающего: – определение актуальных угроз безопасности информации и актуализация модели угроз безопасности информации (при необходимости); – выполнение требований о согласовании технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России в установленном порядке; – выполнение требований по устранению Подрядчиком замечаний и недостатков, в случае их выявления при согласовании Заказчиком технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России; – выполнение требований к классу защищенности ГИС, уровню защищенности персональных данных и категории значимости объекта КИИ РФ, установленных для Головного центра обработки данных ФГБУ «СИЦ Минтранса России» (далее – ГЦОД); - – определение перечня объектов защиты информационной системы; – описание (актуализированных) требований к системе защиты информации, а также к мерам защиты информации информационной системы в зависимости от установленных классов защищенности, уровня защищенности персональных данных и категории значимости объектов КИИ РФ (приказы ФСТЭК России № 21, 117, 239); – выполнение требований к мерам по защите ГИС от атак, направленных на отказ в обслуживании, в соответствии с пунктами 30, 34, 59, 63 Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений, утвержденных приказом ФСТЭК России от 11.04.2025 № 117; – описание (актуализированных) требований по защите информации, подлежащих реализации в информационно телекоммуникационной инфраструктуре ГЦОД; – выполнение требований о применении сертифицированных средств защиты информации, включая их классы защиты и уровни доверия; – выполнение требований о запрете использования с 01.01.2025 органами (организациями) средств защиты информации странами происхождения, которых являются иностранные государства в соответствии с пунктом 6 Указа Президента Российской Федерации от 01.05.2022 № 250; – выполнение требований по обеспечению непрерывного взаимодействия с ГосСОПКА в установленном порядке; - 4.3.1.2. Требования к общему порядку оказания услуг Техническая поддержка Модуля СЦ должна быть организована на трех уровнях: – первый и второй уровни технической поддержки организуется Заказчиком; – третий уровень технической поддержки организуется Подрядчиком. Перечень действий на каждом уровне технической поддержки указан в Таблице 5: Таблица 5 – Перечень действий на каждом уровне технической поддержки Уровень технической поддержки Доступные действия Условия передачи задачи на следующий уровень Первый уровень технической поддержки (далее – 1-й уровень) – принимает обращения (заявки) пользователей Модуля СЦ и работников Заказчика; – регистрирует обращения в Модуле СЦ регистрации обращений; – присваивает уникальный идентификационный номер, классифицирует обращения; – самостоятельно решает обращения, которые связаны с недостаточной квалификацией пользователей или настройками в рамках своей компетенции; – взаимодействует с пользователями Модуля СЦ при решении проблемы Передает обращение на второй уровень поддержки в случае невозможности решения на своем уровне Второй уровень технической поддержки (далее – 2-й уровень) – принимает обращения от 1-го уровня; – уточняет классификацию обращения в результате дополнительного анализа; – самостоятельно решает обращения в рамках своей компетенции; – осуществляет техническую и консультационную поддержку Модуля СЦ; – взаимодействует с сотрудниками 1-го и 3-го уровня и пользователями Модуля СЦ; – формирует заявки для 3-го уровня и контролирует исполнение Передает обращение на третий уровень поддержки в случае невозможности решения на своем уровне Третий уровень технической поддержки (далее – 3-й уровень) – принимает обращения от 2-го уровня; – обеспечивает выполнение требований, предъявляемых Контрактом и настоящим Техническим заданием к Услугам, оказываемым Подрядчиком Все поступающие обращения должны быть исполнены Подрядчиком - Для обеспечения взаимодействия с Заказчиком Подрядчик со своей стороны определяет ответственных лиц, уполномоченных в структуре Подрядчика за своевременное и качественное оказание Услуг в рамках настоящего ТЗ, а также контактную информацию ответственных лиц (телефон, электронную почту). Подрядчик должен предоставить Заказчику единый адрес электронной почты для приема обращений (заявок) в течение 3 (трех) рабочих дней после заключения Контракта. Указанный в настоящем пункте адрес электронной почты (способ направления обращений (заявок) применяется в случае сбоя в работе СРО Заказчика. Со своей стороны, Заказчик предоставляет Подрядчику перечень и контактную информацию (телефон, электронную почту) уполномоченных лиц для осуществления взаимодействия с указанием зон ответственности. О любых изменениях в контактной информации ответственных лиц Стороны должны уведомить друг друга в течение 1 (одного) рабочего дня с момента возникновения таких изменений посредством уведомления на электронную почту ответственных лиц и/или в письменной форме. В результате оказания услуг по настоящему ТЗ не должны быть изменены исходные коды, дистрибутивы и иные компоненты Модуля СЦ вне согласованных с Заказчиком изменений. Любые изменения исходных кодов, дистрибутивов и иных компонентов Модуля СЦ должны производиться только после согласования с Заказчиком уполномоченными лицами по электронной почте или иным заранее согласованным способом. Не должна быть ухудшена надежность и производительность Модуля СЦ. Оказание услуг по Контракту не должно нарушать требования к информационной безопасности, описанной в документации на Модуль СЦ - – выполнение требований по обеспечению в автоматизированном режиме с Национальной системой противодействия DDoS-атакам (НСПА) Центра мониторинга и управления сетью связи общего пользования ФГУП «ГРЧЦ» в рамках реализации мер по защите ГИС от атак, направленных на отказ в обслуживании; – детализированные требования к составу и содержанию работ по аттестации, а также к их результатам в соответствии с пунктами 13, 15 и 16 требований приказа ФСТЭК России от 29.04.2021 № 77 «Об утверждении Порядка организации и проведения работ по аттестации объектов информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну» - 4.5.5.1. Требования к безопасности исходного кода Процесс разработки исходного кода должен соответствовать требованиям законодательства, нормативным правовым актам Российской Федерации, приказу ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по безопасности значимых объектов критической информационной инфраструктуры Российской Федерации», а также учитывать отраслевые практики безопасной разработки. Подрядчик должен предоставить Заказчику Руководство по безопасной разработке программного обеспечения (далее – Руководство), применяемое при разработке исходного кода Модуля СЦ. Руководство должно содержать: · описание процесса безопасной разработки и ролевой модели, отражающей зоны ответственности сотрудников Подрядчика; · описание процессов моделирования, оценки и формирования мер предотвращения угроз, применяемых Подрядчиком; · описание методик, применяемых Подрядчиком при разработке исходного кода (правила написания кода); · описание методик, периодичности проведения и инструментария статического, динамического, композитного и фаззинг тестирования исходного кода, включающего критерии отбора релизных версий ПО, применяемые Подрядчиком в процессе разработки; · описание механизмов безопасности в процессе сборки и доставки (безопасность образов, безопасность секретов, безопасность окружения и сборочной среды), применяемые Подрядчиком; · утвержденные шаблоны отчетной документации (в том числе акты), в соответствии с которыми Заказчик принимает результаты проверок (артефакты сборочного процесса), проведенных Подрядчиком; · описание процедур отслеживания и исправления обнаруженных ошибок и уязвимостей программного обеспечения; · описание способов и сроков доведения Подрядчиком до Заказчика информации об уязвимостях программного обеспечения, о компенсирующих мерах по защите информации или ограничениях по применению программного обеспечения, способов получения пользователями программного обеспечения его обновлений, проверки их целостности и подлинности - Подрядчик должен обеспечить реализацию и проведение внутренних проверок мер по разработке безопасного ПО, приведенных в Руководстве. Подрядчик должен провести анализ угроз безопасности информации программного обеспечения в соответствии с ГОСТ 58412-2019 «Защита информации. Разработка безопасного программного обеспечения. Угрозы безопасности информации при разработке программного обеспечения». Подрядчик должен провести испытания по выявлению уязвимостей в программном обеспечении Системы: · проведение статического анализа исходного кода программы; · проведение динамического анализа исходного кода программы; · проведение композитного анализа исходного кода и образов программы; · проведение фаззинг-тестирования программы, направленного на выявление в ней уязвимостей. Испытания по выявлению уязвимостей в программном обеспечении Системы должны быть проведены в рамках: · предварительных испытаний; · опытной эксплуатации; · приемочных испытаний - Оказание услуг в рамках данного технического задания осуществляется Подрядчиком по обращению (заявке) Заказчика, направляемой посредством СРО Заказчика. Регистрация обращений, поступивших непосредственно в Модуль СЦ регистрации обращений Заказчика, производится сотрудниками Заказчика, которые обеспечивают первый уровень технической поддержки Модуля СЦ. В случае назначения приоритета «Критический» или «Высокий», информация о назначении также дублируется оповещением ответственных представителей Подрядчика посредством звонка на предоставленные номера телефонов. Обращение (заявка) должна содержать следующую информацию: – контакты пользователя/организации; – приоритет обращения, соответствующий Приложению 2 к Регламенту; – время обнаружения; – наименование компонента АСУ ТК - Модуль СЦ; Информация может быть расширена по согласованию с Заказчиком. Обращения (заявки) сотрудников Заказчика должны приниматься Подрядчиком через веб-интерфейс СРО. В процессе обработки обращений (заявок) Подрядчик должен обеспечить выполнение следующих процедур: – прием обращений(заявок) от сотрудников Заказчика; – оказание информационно-консультационной поддержки в соответствии с требованиями настоящего Технического задания; – информирование сотрудников Заказчика о статусе обработки и результатах обработки обращений(заявок). Подрядчик осуществляет обязательную регистрацию и учет всех обращений и заявок, поступивших к Подрядчику от представителей Заказчика в рамках оказания настоящих услуг - Примечание: в случае приостановки работы по обращению или заявке (обращение или заявка находится в статусе «Приостановлено»), указываются причины, по которым работы по обращению или заявке приостановлены с указанием перечня действий/информации, запрошенных у инициатора обращения, а также даты, формы и адресата такого запроса. В случае отклонения обращения или заявки (заполняется в случае, если обращению или заявке присваивается статус «Отклонено»), указываются подробно причины такого отклонения, а также фиксируется дата и время перехода в статус «Отклонено». В случае, если обращение или заявка отклонены (отменены) самим Инициатором, то указывается дата и способ, которым от инициатора получено соответствующее уведомление. В случае невыполнения Подрядчиком регламентного времени реагирования или решения обращения (заявки) Заказчик вправе отозвать обращение и направить его Подрядчику повторно. При этом каждое отозванное обращение учитывается в Отчёте об оказанных услугах, как обращение с превышением времени реагирования или решения, но оплате не подлежит. В случае, если обращение (заявка) связано с некачественным выполнением Подрядчиком другой задачи, такое обращение решается в регламентное время, установленное Техническим заданием, при этом оплате такие обращения не подлежат, о чем указывается в Отчете об оказанных услугах в графе «Примечание» - По результатам анализа угроз безопасности информации программного обеспечения и испытаний по выявлению уязвимостей в программном обеспечении Системы должна быть предоставлена отчетная документация по формам, утвержденным в Руководстве, и артефакты сборочной среды, подтверждающие проведение испытаний по выявлению уязвимостей в программном обеспечении Систем. Уязвимости подлежат устранению в сроки, обозначенные Заказчиком. В случае обнаружения уязвимого компонента Подрядчик должен заменить/обновить библиотеки. В случае, если уязвимость не подлежит исправлению на программном уровне, Подрядчик должен разработать меры предотвращения угроз безопасности, в том числе правила безопасности для наложенных средств защиты, рекомендации по безопасной настройке конфигурации для устранения потенциальных уязвимостей и снижения рисков информационной безопасности. Уязвимости, найденные ФСБ России, ФСТЭК России, Минцифры России, Роскомнадзором в ходе исполнения Контракта, а также в течение гарантийного периода, должны быть устранены Подрядчиком за свой счет в сроки, согласованные с Заказчиком - 4.5.6. Требования к эргономике и технической эстетике Взаимодействие пользователей с Модулем СЦ должно осуществляться посредством визуального графического интерфейса. Ввод-вывод данных, прием управляющих команд и отображение результатов их исполнения должны выполняться в интерактивном режиме. Интерфейс должен быть рассчитан на преимущественное использование манипулятора типа «мышь», то есть управление Модулем СЦ должно осуществляться с помощью набора экранных меню, кнопок, значков и т. п. элементов. Клавиатурный режим ввода должен использоваться главным образом при заполнении и/или редактировании текстовых и числовых полей экранных форм. Все надписи экранных форм, а также сообщения, выдаваемые пользователю (кроме системных сообщений), должны быть на русском языке. Модуль СЦ должен обеспечивать проверку вводимых пользователем данных и предупреждать о некорректно введённых значениях - Экранные формы должны проектироваться с учетом требований унификации: – все экранные формы пользовательского интерфейса должны быть выполнены в едином графическом дизайне, с одинаковым расположением основных элементов управления и навигации; – для обозначения сходных операций должны использоваться сходные графические элементы, кнопки и другие управляющие (навигационные) элементы. Термины, используемые для обозначения типовых операций, а также последовательности действий пользователя при их выполнении должны быть унифицированы; – внешнее поведение сходных элементов интерфейса (реакция на наведение указателя «мыши», переключение фокуса, нажатие кнопки) должно реализовываться одинаково. Структура размещения информации и представление этой структуры в Модуле СЦ должны соответствовать следующим требованиям: – пункты меню в пользовательском веб-интерфейсе должны быть сгруппированы в соответствии с тематикой информации, функциональными задачами и технологией работы; – каждому пункту меню должна соответствовать только одна выполняемая функция; – при совершении пользователями ошибочных действий должны выдаваться сообщения об ошибках. Эскизы визуального оформления компонента «Интерактивная карта» представлены в Приложении А. - 4.3.1.3. Требования к регламенту оказания услуг Подрядчик должен руководствоваться Регламентом оказания услуг по технической поддержке Модуля СЦ. Регламент оказания услуг содержит следующую информацию: – порядок оказания услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Модуля СЦ; – порядок оказания услуги по решению инцидентов, связанных с работой ППО; – порядок оказания услуги адаптационного, конфигурационного и коррекционного сопровождения Модуля СЦ (в рамках действующих программных модулей и функциональностей); – порядок оказания услуги по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности. – Регламент содержит следующие формы заявок на оказание услуг: – форма заявки на оказание услуги по информационно-консультационной поддержке сотрудников Заказчика; – форма заявки на оказание услуги по решению инцидентов, связанных с работой ППО; – форма заявки на оказание услуг адаптационного, конфигурационного и коррекционного сопровождения Модуля СЦ (в рамках действующих программных модулей и функциональностей) (приоритет заявки определяется Заказчиком); – форма заявки на оказание услуги по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности - 4.3.2. Требования к режиму обеспечения функционирования Модуля СЦ Режим оказания услуг определен в Приложении Б к настоящему ТЗ. По согласованию с Заказчиком, в целях недопущения остановки функционирования Модуля СЦ в период интенсивной работы пользователей в Модуле СЦ, отдельные услуги могут оказываться по специальному графику (в нерабочее время Подрядчика) в соответствии с заявками Заказчика - 4.3.3. Требования к качеству оказываемых услуг Качество оказываемых услуг поддерживается Подрядчиком в соответствии с определяемыми данным ТЗ условиями и правилами и контролируется Заказчиком на постоянной основе, в том числе по соблюдению сроков исполнения и подтверждениям исполнения от инициаторов обращений и другим параметрам. По результатам выполнения работ по устранению инцидента должна быть устранена корневая причина инцидента с окончательным решением, устраняющим причину возникновения проблемы и исключающим вероятность повторного возникновения проблемы (инцидента). Время устранения корневых причин проблемы (инцидента) не должно составлять более 40 рабочих часов - 4.5.7. Требования по сохранности информации при авариях В случае возникновения аварии или сбоя в процессе выполнения пользовательских задач должно быть обеспечено восстановление баз данных до состояния на момент последней завершенной Модулем СЦ транзакции, и структуры файлового хранилища. Все аварийные ситуации должны обрабатываться программно с выдачей соответствующих сообщений, с корректной обработкой ситуации (завершение транзакций, закрытие файлов и т.п.), без потери обрабатываемой информации. В Модуле СЦ должны быть предусмотрены меры, обеспечивающие целостность данных в случае отказа программного обеспечения или аппаратных средств, исключая случаи физического уничтожения носителя или нарушения функциональности носителя, операционной системы или СУБД по вине их производителя либо обслуживающего персонала. Используемые аппаратные и системные платформы должны обеспечивать сохранность и целостность информации в Модуле СЦ при полном или частичном отключении электропитания, аварии сетей телекоммуникации, полном или частичном отказе технических средств Модуля СЦ. Технические решения должны обеспечивать сохранность информации в случае возникновения следующих событий (аварий, отказов и т.п.): – отказ аппаратного обеспечения на сервере; – отключение питания на сервере; – отказ аппаратного обеспечения на рабочей станции; – отключение питания на рабочей станции администратора; – отказ линий связи, в том числе при осуществлении обмена данными - 4.5.8. Требования к защите от влияния внешних воздействий Требования к защите от влияния внешних воздействий не предъявляются - 4.5.9. Требования к патентной чистоте и патентоспособности 4.5.9.1. Исключительные права на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, базы данных, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, принадлежат Российской Федерации в лице Заказчика. Право собственности на результаты работ, отчетные документы и материалы, полученные в ходе выполнения работ по Контракту, принадлежат Российской Федерации в лице Заказчика и считаются переданными с момента подписания Сторонами Акта сдачи-приемки выполненных работ. Разработанное программное обеспечение поставляется вместе с исходными кодами. 4.5.9.2. Все проектные и технические решения должны отвечать требованиям четвертой части Гражданского кодекса Российской Федерации. Результаты Работ должны быть свободными от возможности предъявления любых прав и притязаний третьих лиц, основанных на промышленной, интеллектуальной или другой собственности. 4.5.9.3 Результаты выполненных Работ не должны повлечь необходимость осуществления Заказчиком закупок программного обеспечения (как исключительных, так и неисключительных прав) для обеспечения функциональности Системы в соответствии с Техническим заданием. При выполнении работ Подрядчик должен использовать только объекты интеллектуальной собственности, права на которые приобретены (получены) и используются без нарушений прав на интеллектуальную собственность третьих лиц или предоставлены Заказчиком - 4.3.4. Требования к документированию результатов оказываемых услуг Для обеспечения контроля оказываемых услуг по поддержке Модуля СЦ со стороны Заказчика, по окончании каждого отчетного периода по контракту в соответствии с календарным планом, Подрядчик обязан предоставить Заказчику Отчет об оказанных услугах. Отчет должен содержать детальную информацию об оказанных услугах с указанием даты выполненных мероприятий и приложением обосновывающих документов (заявок, запросов, требований) или ссылкой на такие документы, если они содержатся в Модуле СЦ. Информация о выполненных мероприятиях по заявкам должна быть сформирована на основании соответствующих записей СРО по каждому этапу исполнения Контракта. В случае оказания услуги адаптационного, конфигурационного и коррекционного сопровождения Модуля СЦ, должны быть предоставлены документы, подтверждающие выполнение требований п. 29.3 приказа ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации». Фактическое время реагирования и время решения по всем обращениям, поступившим в СРО, формируется в СРО по итогам отчетного периода в разделе «Отчеты». Фактическое время реагирования и время решения по обращениям учитывает суммарное время, затраченное на реагирование и, соответственно, на работу по обращению с момента назначения обращения специалисту Подрядчика или группе исполнителей, ответственным за оказание услуг технической поддержки 3 уровня от начала до завершения работ Подрядчиком. При этом принимается суммарное время нахождения заявки в соответствующих статусах заявки СРО на стороне Подрядчика - 4.3.5. Требования к классификации обращений и заявок Обращения и заявки Заказчика классифицируются в соответствии с приоритетами и регламентными сроками, указанными в Приложении 2 к Регламенту. Регистрация обращений и заявок предусматривает создание новой записи в СРО с присвоением поступившему обращению или заявке (новой записи) уникального идентификатора. Запись в СРО должна содержать вопрос или проблему, которую требуется решить или оказать консультацию. Состав обязательной информации, которую должно содержать обращение или заявка, зафиксирован в Регламенте оказания Услуг. Если обращение или заявка автоматически зарегистрированы в СРО при отправке представителем Заказчика, Подрядчик проверяет корректность классификации обращения или заявки и может обратиться к Заказчику с просьбой корректировки, предоставив обоснования в соответствии с настоящей классификацией (Таблица 6) - 4.5.9.4. Подрядчик подтверждает, что обладает всеми правами на передачу Заказчику исключительных прав в соответствии с требованиями настоящего раздела Технического задания. В случае, если к Заказчику по вине Подрядчика будут предъявлены претензии в этой части, иски третьих лиц, связанные с нарушением их прав, Подрядчик принимает на себя такие претензии и иски и возмещает Заказчику все расходы и весь ущерб, понесенный в связи с ними. 4.5.9.5. Подрядчик обязан согласовать с Заказчиком необходимость использования при выполнении работ охраняемых результатов интеллектуальной деятельности, права на которые принадлежат Подрядчику или третьим лицам. 4.5.9.6. В случае, если при выполнении Работ используется готовое программное обеспечение (платформа, подсистема, СУБД и т.д.), которое становится частью (компонентом) Системы, Заказчику передаются полные исключительные права, или неисключительные права (путем заключения лицензионного/сублицензионного договора/соглашения) на такое программное обеспечение со следующими возможностями: – права передаются бессрочно (на весь срок действия исключительных прав); – территория действия Российская Федерация; – должно быть обеспечено право Российской Федерации (в лице Заказчика) передавать, дорабатывать, распространять, развивать результаты работ, созданные в процессе исполнения Контракта, а также перерабатывать такое программное обеспечение. Лицензионное (сублицензионное) соглашение (договор), Акт передачи прав, подписанные Подрядчиком, согласие правообладателя, оформленное в соответствии с положениями Гражданского кодекса Российской Федерации (в случае, если Подрядчик не является правообладателем такого программного обеспечения), инструкция по инсталляции, руководство администратора, руководство пользователя передаются Заказчику в сроки, установленные Техническим заданием для соответствующего функционала Системы - Лицензионное (сублицензионное) соглашение (договор) не может возлагать на Заказчика какие-либо обязанности (в т.ч. в части конфиденциальности, предоставления отчетности), не предусмотренные Контрактом. 4.5.9.7. Передача Заказчику исключительных прав, или простых (неисключительных) прав не может повлечь увеличение стоимости Контракта и/или изменение иных существенных условий Контракта. 4.5.9.8. Функциональность Модуля СЦ передается в объеме и в сроки, установленные Техническим заданием. 4.5.9.9. Нарушение условий настоящего раздела Технического задания, в т.ч. отсутствие соответствующего лицензионного (сублицензионного) соглашения (или договора), либо предоставление лицензионного (сублицензионного) соглашения (или договора), не соответствующего требованиям действующего законодательства Российской Федерации или требованиям Контракта, является нарушением существенных условий Контракта. 4.5.9.10. В случае, если в соответствии с пунктом 4.5.9.6 Заказчику передается исключительное право, такая передача осуществляется в порядке, установленном Гражданским кодексом Российской Федерации. 4.5.9.11. В случае, если при выполнении Работ положения пунктов 4.5.9.5-4.5.9.6 не применялись, Подрядчик в составе отчетной документации предоставляет об этом декларацию в свободной форме. Декларация должна содержать сведения о полном соответствии результата Работ требованиям Контракта, а также о неприменении при выполнении работ готового программного обеспечения (платформ, подсистем, СУБД и т.д.), которое стало частью (компонентом) Системы - Таблица 6. Категории обращений и заявок Категория Примеры Запрос на обслуживание Подготовка SQL запроса к СУБД для решения прикладной задачи и д.р. – запрос на любое действие, не являющееся запросом информации и несовершенный на основе происшествия, прямо или косвенно влияющего на работу Модуля СЦ Консультация «Где взять / куда обратиться...?», «Как сделать / выполнить…», «Как это работает…?» - запрос, имеющий своей целью получение информационной поддержки Инцидент Разбор ошибок/сбоев и подготовка материалов (корректировочных релизов, инструкций) для Заказчика для устранения ошибок/сбоев, которые приводят к частичному и полному нарушению работоспособности всех или отдельных функций ППО. Подготовка изменения и материалов, необходимых для проведения аварийно-восстановительных работ для возобновления работоспособности Модуля СЦ ЗНИ Подготовка изменений, связанных с изменением, улучшением/оптимизацией Модуля СЦ и выводом новой модифицированной функциональности в штатном режиме. Подготовка изменений, связанных с модификацией существующих и/или реализация новых интеграционных механизмов для получения/обработки данных внешних систем. Подготовка изменений графического интерфейса по требованиям Заказчика. Перечень статусов обращений (заявок) приведен в пункте 3.3. Регламента оказания Услуг. Назначение обращению (заявке) статуса «Закрыто» осуществляется Заказчиком только после получения от инициатора обращения (заявки) подтверждения о его исполнении или нахождения обращения (заявки) в статусе «Выполнено» и отсутствия повторных вопросов/запросов по данному обращению (заявки) в течение 5 рабочих дней. Категории и статусы обращений (заявок) могут быть скорректированы в процессе оказания услуг исключительно по согласованию с Заказчиком - 4.3.6. Требования к услугам технической поддержки 4.3.6.1. Требования к организации третьего уровня технической поддержки Основными задачами организации третьего уровня технической поддержки в рамках оказания услуг по технической поддержке Модуля СЦ являются организация эксплуатационной службы Подрядчика, проверка готовности технических и программных средств для обеспечения непрерывного функционирования ППО Модуля СЦ. Подрядчиком должны быть проведены организационно-штатные и подготовительные мероприятия (в т. ч. технические) в рамках организации технической поддержки Модуля СЦ. Подрядчик в течение 5 (пяти) рабочих дней с даты заключения Контракта должен: – определить и направить Заказчику документ «Перечень уполномоченных специалистов», содержащий контактную информацию (ФИО, должность, адрес рабочей электронной почты) лиц, ответственных за оказание услуг со стороны Подрядчика; – обеспечить подключение специалистов Подрядчика к Системе регистрации обращений (заявок) (СРО предоставляется Заказчиком) для оказания услуг; – согласовать с Заказчиком способ доступа Подрядчика к Модулю СЦ. Результат выполнения мероприятий фиксируется в Протоколе проверки результатов организационно-штатных и подготовительных мероприятий (см. Приложение Д к настоящему ТЗ) - 4.5.9.12. Передача Заказчику комплекта документов, материалов и сведений, предусмотренных нормативными правовыми актами Российской Федерации в сфере информационных технологий, защиты информации, правовой защиты интересов государства в области интеллектуальной собственности, включая документы, подтверждающие отказ авторов (разработчиков) от исключительных прав на передаваемые объекты интеллектуальной собственности в пользу Подрядчика, с проектами заявок на государственную регистрацию в установленном порядке прав Заказчика на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, базы данных, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, осуществляется Подрядчиком в составе отчетной документации, предусмотренной условиями Контракта. 4.5.9.13. По результатам выполнения работ по развитию системы должны быть подготовлены материалы для регистрации доработанной версии Системы (объекта учета) в НФАП в соответствии с требованиями постановления Правительства Российской Федерации от 30 января 2013?г. №?62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин» (с изменениями и дополнениями) в части обязательности размещения результатов работ в национальном фонде алгоритмов и программ для электронных вычислительных машин - 4.5.10. Требования по стандартизации и унификации К Модулю СЦ предъявляются следующие требования в части стандартизации и унификации: – работы по развитию Модуля СЦ должны производиться в соответствии с действующими стандартами и нормами Российской Федерации; – при создании и модернизации элементов Модуля СЦ следует руководствоваться действующими в Российской Федерации национальными стандартами и другими нормативно-техническими документами; – используемые оборудование и материалы, подлежащие обязательной сертификации, должны иметь соответствующие сертификаты; – ПО Модуля СЦ должно проектироваться и разрабатываться с учётом обеспечения требований унификации; – применяемые при создании Модуля СЦ технические (форматы данных, протоколы передачи и прочие) и организационные (регламенты, требования, инструкции) решения должны быть доступны и документированы в виде, достаточном для независимой (без обращения к Подрядчику) реализации третьими сторонами; – термины, обозначения и наименования, используемые в ПО, должны быть стандартизованы и унифицированы, выполнены на русском языке; – взаимодействие элементов и их внешнее поведение должно быть реализовано одинаково и производиться по единым правилам - 4.3.6.2. Требования к услугам информационно-консультационной поддержки работников Заказчика и пользователей Модуля СЦ Услуги информационно-консультационной поддержки сотрудников Заказчика включают: – обработку обращений и заявок, поступивших от сотрудников Заказчика; – консультирование сотрудников Заказчика и пользователей Модуля СЦ; – актуализацию документации, и других материалов по работе с Модулем СЦ при необходимости. – консультирование и разработку рекомендаций по настройке Модуля СЦ (без изменения программного кода), включая изменение настроек функционирования; – консультации по вопросам использования, настройки и возможностям Модуля СЦ; – консультации по проведению превентивных мер для недопущения аварийных ситуаций в Модуле СЦ; – консультации по предварительной диагностике и локализации возникшей неисправности Модуля СЦ; – консультации по вопросам обеспечения информационной безопасности Модуля СЦ и настройки функций, обеспечивающих корректную работу программного обеспечения для совершения юридически значимых действий в Модуле СЦ; – другие вопросы, связанные с работой Модуля СЦ. 4.3.6.2.1. Требования к порядку оказания услуг информационно-консультационной поддержки работников Заказчика и пользователей Модуля СЦ Подрядчик выполняет консультирование сотрудников Заказчика и пользователей Модуля СЦ. Консультация может быть предоставлена по согласованным с представителем Заказчика каналам коммуникации с регистрацией результата консультации в СРО Подрядчиком. Детальный порядок оказания консультационных услуг определен в Регламенте оказания Услуг - 4.3.6.3. Требования к услугам по решению инцидентов, связанных с работой ППО Подрядчик устраняет неисправности Модуля СЦ, связанные с работой ППО, выявленные в рамках оказания услуг согласно настоящему Техническому заданию, при этом в зону ответственности Подрядчика не входит устранение неисправностей, выявленных на стороне Заказчика и на стороне третьих лиц (провайдера связи, поставщика электропитания и т.д.). Первичная диагностика выявленной неисправности проводится на 1 и 2 уровнях технической поддержки и не входит в зону ответственности Подрядчика. Если при проведении первичной диагностики и попытке устранить неисправности на 1 и 2 уровнях технической поддержки, данную неисправность устранить не удалось и в процессе диагностики было выявлено, что проблема связана с работоспособностью ППО, обращение (заявка) назначается сотруднику Подрядчика, ответственному за оказание услуг технической поддержки 3 уровня. Инцидентами вне зоны ответственности Подрядчика являются: – работоспособность функциональности, выходящая за рамки текущей реализации функций в Модуле СЦ и/или являющаяся расширением требований Заказчика к функциям Модуля СЦ; – проведение профилактических и плановых работ, согласованных с Заказчиком; – нарушение работоспособности функций Модуля СЦ, вызванное проведением работ на стороне Заказчика - 4.5.11. Требования к показателям назначения 4.5.11.1. Требования к показателям назначения мероприятий по развитию Модуля СЦ В рамках выполнения работ по развитию Модуля СЦ, предусмотренных ТЗ, показатель назначения «Количество пользователей» должен соответствовать значениям, приведенным в данном разделе. Пояснения по показателям, связанным с количеством пользователей, приведены в Таблице 8. Таблица 8. Определения показателей, связанных с количеством пользователей в Модуле СЦ № Показатель Определение Расчетное количество пользователей Количество пользователей, работу которых должен обеспечить Модуль СЦ к моменту сдачи работ по Контракту с учетом достижения всех показателей назначения Расчетное количество одновременно работающих пользователей Количество одновременно работающих пользователей, работу которых должен обеспечивать Модуль СЦ к моменту сдачи работ по Контракту с учетом достижения всех показателей назначения Значения показателей количества пользователей, достижение которых необходимо обеспечить, представлено в Таблице 9 - Таблица 9. Значения показателей количества пользователей № Показатель Значение 1. Расчетное количество пользователей 1 000 2. Расчетное среднее количество одновременно работающих пользователей 200 Развитие Модуля СЦ должно быть направлено на достижение следующего эффекта (показателя), подставленного в мероприятии 103.002 «Информационно-аналитическая система регулирования на транспорте (АСУ ТК)» ВПЦТ Минтранса России: Выполнение работ по развитию Модуля СЦ предусмотрено мероприятием по развитию АСУ ТК, приведенном в ВПЦТ Минтранса России на 2026-2028 гг: № 103.002 «АСУ ТК» в составе ИТ расхода 103.26.000005 «Развитие предусматривает реализацию ОКР и эффектов, приведенных в Таблице 10. Таблица 10. ОКР и эффекты, приведенные в ВПЦТ Минтранса России на 2026 г. № ОКР Дата ОКР Эффекты 1 Обеспечено информационное взаимодействие с Минобороны России о происшествиях на транспортных объектах 25.12.2026 Сокращено время сбора и передачи сведений для Минобороны России о ЧС и НС на транспорте с 120 до 10 минут 2 Обеспечена автоматизация формирования отчетов о нештатных ситуациях на транспорте, в том числе по данным внешних систем 25.12.2026 Сокращено время на подготовку отчетов о нештатных ситуациях на транспорте с 20 до 5 минут Реализация остальных ОКР не является предметом данного ТЗ и проводится в рамках отдельного технического задания. - 4.5.11.2. Требования к показателям назначения мероприятий по эксплуатации Модуля СЦ. Работы по эксплуатации Модуля СЦ не должны обеспечивать режимы функционирования Модуля СЦ, приведенные в разделе 4.5.2 данного ТЗ - Работы по устранению неисправности приостанавливаются (по согласованию с Заказчиком) в следующих случаях: – если Подрядчиком в результате диагностики выявлено, что неисправность находится в зоне ответственности Заказчика. Подрядчик информирует Заказчика о выявленной неисправности в зоне его ответственности по согласованным каналам связи; – требуется действие со стороны Заказчика – до момента выполнения данного действия Заказчика. Заказчик информируется о необходимых действиях по согласованным каналам связи; – отсутствие возможности связаться со специалистами Заказчика, участие которых необходимо для устранения неисправности; – требуется доставить оборудование на объект – до момента доставки и установки оборудования. В случаях, представленных выше, время приостановки работ не входит в учет продолжительности устранения неисправности. Учет времени устранения неисправности Подрядчиком считается с момента назначения Инцидента специалисту Подрядчика, ответственному за оказание услуг технической поддержки 3 уровня. Подтверждение необходимости приостановления работ находится в зоне ответственности Подрядчика. Приостановление сроков выполнения задач в соответствии с настоящим пунктом подтверждается Заказчиком по мотивированному обращению Подрядчика в СРО, основанному на данных диагностики или на иных фактических обстоятельствах - В случае непринятия Подрядчиком необходимых мер по информированию Заказчика (отсутствие надлежащего обращения от Подрядчика или отсутствие уведомления о необходимости осуществления каких-либо действий Заказчиком) не может являться основанием для приостановления работ по устранению неисправности. В отдельных случаях Подрядчику может потребоваться выполнение технологических работ для устранения причин неисправности или недопущения повторения их в будущем. Для обеспечения устранения неисправности Модуля СЦ Заказчиком проводится классификация в соответствии с приоритетами по степени срочности их устранения. Продолжительность устранения неисправности, а также периодичность информирования Подрядчиком Заказчика о ходе устранения неисправности, определены в Регламенте оказания услуг. При подаче обращения (заявки) наивысшего приоритета через СРО Заказчик должен дополнительно проинформировать службу поддержки Подрядчика о созданном обращении (заявки) по телефону уполномоченного сотрудника Подрядчика. При этом временем подачи обращения (заявки) считается время подачи обращения (заявки) через СРО - 4.3.6.3.1. Требования к порядку оказания услуги по решению инцидентов, связанных с работой ППО При поступлении от Заказчика обращения (заявки), являющегося неисправностью в работе Модуля СЦ (инцидентом), Исполнитель реагирует на инцидент в СРО в срок не более 30 минут с момента поступления. В случае необходимости, для решения инцидента ответственный специалист должен связаться с инициатором обращения (заявки) для уточнения условий воспроизведения проблемы или для получения дополнительных сведений. После получения необходимых сведений от инициатора обращения (заявки) ответственный специалист производит диагностику с целью выявления причины инцидента и возможных путей устранения. В случае, если инцидент невозможно решить без получения дополнительных сведений от инициатора, и не удается связаться с инициатором в течение пяти рабочих дней, обращение (заявка) отклоняется в связи с недостатком данных для его решения, Заказчику направляется уведомление об отклонении обращения (заявки). Время, в течение которого невозможно связаться с инициатором, вычитается из общего времени обработки обращения (заявки). Все попытки связаться с инициатором должны фиксироваться с указанием даты и времени попытки, используемого способа связи (номер телефона, адрес электронной почты) и результата попытки (не удалось дозвониться, абонент недоступен, и т.д.) - Факт и время решения инцидента должны быть зафиксированы и отражены в СРО. В случае, если причиной сбоя в работе Модуля СЦ является выход из строя аппаратного обеспечения или неработоспособность смежной информационной системы, время работы над инцидентом приостанавливается до момента устранения неисправности. В ходе решения инцидентов могут быть выявлены дефекты ППО Модуля СЦ. В случае обнаружения дефектов ППО, Подрядчик информирует об этом Заказчика. Исполнитель может быть привлечен к проверке результата устранения дефекта по инициативе Заказчика. Приоритеты инцидентов приведены в Приложении Б к ТЗ. Детальный порядок оказания услуги по решению инцидентов, связанных с работой ППО Модуля СЦ определен в Регламенте оказания Услуг - 4.3.6.4. Требования к услугам адаптационного, конфигурационного и коррекционного сопровождения и доработки Модуля СЦ (в рамках действующих программных модулей и функциональностей) Услуги адаптационного, конфигурационного и коррекционного сопровождения и доработки Модуля СЦ включают: – управление изменениями и адаптация функций Модуля СЦ; – изменение настроек функционирования Модуля СЦ; – внесение изменений и/или модификаций Модуля СЦ (в рамках действующих программных модулей и функциональностей), направленных на улучшение их работоспособности и функциональных возможностей; – подготовка и передача Заказчику SQL запросов в СУБД для получения агрегированной информации из Модуля СЦ, которую невозможно получить с использованием графического пользовательского интерфейса; – адаптация модулей интеграций со смежными информационными системами - 4.3.6.4.1. Требования к проведению изменений Основанием для внесения изменений является запрос от Заказчика. Все активности по внесению изменений должны быть согласованы с Заказчиком, а действия Подрядчика при оказании данной услуги должны быть зафиксированы. В рамках данного Технического задания изменениями считаются локальные доработки функционала Модуля СЦ, которые не должны приводить к необходимости выполнения дополнительных аттестационных испытаний или переаттестации АСУ ТК в соответствии с п. 33 приказа от 29.04.2021 № 77 «Об утверждении Порядка организации и проведения работ по аттестации объектов информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну». При необходимости внесения изменений в Модуль СЦ, не связанных с критичным инцидентом, существенно нарушающим работоспособность Модуля СЦ, Заказчик направляет Подрядчику обращение (заявку), в котором излагает суть изменения, которое требуется внести в Модуль СЦ. Исполнитель, в течение 3 (трех) рабочих дней с момента поступления соответствующего обращения (заявки), оценивает техническую возможность реализации запрашиваемого изменения и варианты реализации. По итогу проведения оценки Подрядчик направляет Заказчику заключение о возможности реализации данного изменения с описанием возможных вариантов реализации и согласует с Заказчиком проведение данного изменения - При проведении работ по изменению и адаптации Подрядчик должен: – обеспечить выполнение требований безопасной разработки программного обеспечения; – обеспечить предварительное проектирование технических решений и согласование с Заказчиком проекта реализации изменения; – использовать семантическое версионирование (SemVer) в работе, передать Заказчику все артефакты разработки (исходный код и сторонние библиотеки, конфигурации, сборочные и собранные образы и др.); – подготовить полноценное описание функционала, включенного в релиз, с необходимыми схемами и пояснениями к обновлению на стендах Заказчика; – обеспечить тестирование разработанного функционала на стендах Заказчика силами Подрядчика; – решение о переносе измененного ППО на продуктивный стенд принимается Заказчиком по итогу результатов проведенного тестирования; – обеспечить техническое сопровождение процедуры тестирования ППО и переноса измененного ППО на продуктивный стенд Заказчика; – обеспечить экстренное внесение соответствующих изменений в случае выявления некорректной работы продуктивного стенда Заказчика после проведения обновления по итогам разработанного изменения в кратчайшие сроки; – актуализировать при необходимости комплект эксплуатационной документации: o руководство пользователя; o руководство администратора; o иные документы (при необходимости). Результат выполнения изменений должен быть отражен в Отчете по оказанию услуг. Типы и приоритеты изменений могут быть скорректированы в процессе оказания услуг исключительно по согласованию с Заказчиком - 4.3.6.4.2. Требования к изменению настроек функционирования Изменение настроек функционирования может проводиться в рамках допустимых пределов изменения функционирования, заложенных в архитектуру Модуля СЦ. Изменение настроек функционирования включает в себя изменение данных и справочников, изменение форм документов, формируемых Модулем СЦ, изменение и настройку форматов и версий передачи данных в смежные системы. Доработка программного кода Модуля СЦ может допускаться (в случае необходимости) при выполнении работ по адаптации функций Модуля СЦ в части изменения формата передачи данных в смежные информационные системы при условии соблюдения требований пункта 29.3 приказа ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации» - 4.3.6.5. Требования к услугам по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности По запросу Заказчика Подрядчик должен провести работу по приведению ППО в соответствие с требованиями по обеспечению информационной безопасности. Критичность уязвимости оценивается в соответствии в соответствии с Методическим документом ФСТЭК России «Методика оценки уровня критичности уязвимостей программных, программно-аппаратных средств» (утвержден ФСТЭК России 30.06.2025), а также с учетом ГОСТ 56545-2015 и международными стандартами (CVSS 3.0 и выше), и задает необходимый срок устранения. В процессе проведения Заказчиком обследования Модуля СЦ и выявления уязвимостей в ППО, связанных с исходным кодом Модуля СЦ и/или используемыми компонентами (библиотеками), Заказчик направляет Подрядчику обращение (заявку) на устранение, с указанием критичности и срочности принятия мер по устранению в СРО. - Подрядчик при оказании услуг по обновлению или устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности должен: – провести анализ уязвимостей и связанных с ними исходным кодом и/или используемыми компонентами (библиотеками); – выработать варианты устранения указанных уязвимостей и согласовать с Заказчиком их реализацию; – своевременно внести изменения в исходный код Модуля СЦ и/или используемые компоненты (библиотеки) и подготовить соответствующее обновление; – провести обновление Модуля СЦ в тестовом контуре Заказчика и проинформировать Заказчика о готовности проведения тестирования; – протестировать успешность обновления или устранения уязвимостей в ППО и корректность функционирования Модуля СЦ на тестовом контуре, совместно с Заказчиком; – при невозможности незамедлительного устранения уязвимости приоритетов «Критический» и «Высокий» Подрядчик обязан предоставить исчерпывающий список причин и согласовать план достаточных компенсирующих мер с ответственными сотрудниками Заказчика. Результат внесения изменений отображается в соответствующей записи в СРО и в составе Отчета об оказанных услугах - 4.3.6.5.1. Требования к порядку оказания услуг по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности Подрядчик в соответствии с приоритетами обращений и контрольными сроками исполнения (см. Приложение Б к ТЗ) оценивает техническую возможность и сроки устранения уязвимостей, и реализацию обновления Модуля СЦ. По итогу проведения оценки Подрядчик направляет в заявке СРО Заказчику заключение о возможности устранения уязвимостей и/или обновления в ППО и согласует с Заказчиком проведение данных работ - При проведении работ по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности необходимо выполнить следующее: – Заказчику сформировать заявку на устранение (обновление) в СРО с полным списком обнаруженных уязвимостей и планируемыми работами; – согласовать в рабочем порядке время начала и завершения работ, перечень работ, выполняемых в рамках обновления или устранения уязвимостей в ППО с Заказчиком; – оповестить Заказчика о начале проведения работ на тестовом контуре; – провести работы по обновлению или устранению уязвимостей в ППО на тестовом контуре Модуля СЦ в установленные сроки; – протестировать выполнение работ в тестовом контуре и проинформировать Заказчика о готовности переноса ППО на продуктивный контур; – силами Заказчика обновить продуктивный контур Модуля СЦ, в соответствии с планом устранения и выполненными работами; – совместно с Заказчиком проверить корректность функционирования Модуля СЦ и устранения уязвимостей в продуктивном контуре Модуля СЦ по результатам обновления; – при необходимости актуализировать документацию (описание архитектуры, анкеты постановки на мониторинг и иные документы). Любые изменения в части обновления или устранения уязвимостей в ППО на промышленном контуре Модуля СЦ должны применяться только в случае успешного проведения аналогичных работ на тестовом контуре. Детальный порядок оказания услуги по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности определен в Регламенте оказания Услуг - 4.4. Требования к видам обеспечения 4.4.1. Требования к лингвистическому обеспечению Документация на Модуль СЦ должна разрабатываться на русском языке. Взаимодействие пользователей с Модулем СЦ посредством графического интерфейса должно происходить на русском языке за исключением сообщений, зависящих от настроек системного программного обеспечения, установленного на рабочих местах пользователей. При разработке программных решений Модуля СЦ должно быть предусмотрено использование языков программирования высокого уровня, приведенных в Таблице 7. Таблица 7. Языки и средства разработки, специального программного обеспечения Модуля СЦ Категория Наименование Назначение Языки программирования Kotlin Разработка серверной логики и сервисов (backend) JavaScript / TypeScript Разработка клиентской части (frontend) Python Разработка скриптов интеграции, обработки данных и автоматизации Фреймворки и библиотеки Vue.JS Разработка пользовательских интерфейсов (веб-интерфейсы компонентов визуализации и отчетности) React Разработка пользовательских интерфейсов (при необходимости создания сложных интерактивных компонентов) Решения по лингвистическому обеспечению, включая перечень используемых языков программирования, должны быть согласованы с Заказчиком на этапе технического проектирования - 4.4.2. Требования к математическому обеспечению Требования к математическому обеспечению не предъявляются. 4.4.3. Требования к метрологическому обеспечению Требования к метрологическому обеспечению не предъявляются. 4.4.4. Требования к организационному обеспечению Требования к организационному обеспечению не предъявляются. 4.4.5. Требования к методическому обеспечению Задачи методического обеспечения Модуля СЦ должны быть обеспечены за счет использования технологических и методических документов касающихся вопросов функционирования транспортного комплекса и разработки и эксплуатации ПО. 4.4.6. Требования к информационному обеспечению Состав, структура и способы организации информационного обеспечения в Модуле СЦ должны быть определены на этапе технического проектирования. Факты информационного обмена с внешними системами должны фиксироваться в соответствующем журнале - 4.1. Требования к структуре Модуля СЦ В процессе работ по развитию Системы должны сохраниться основные требования к построению архитектуры Системы в соответствии с принципами трехуровневой архитектуры: 1. уровень хранения данных или уровень базы данных (сервер СУБД); 2. уровень сервера приложений (сервер аналитической обработки); 3. презентационный уровень, обеспечивающий взаимодействие с клиентскими приложениями. В состав Системы должны входить следующие основные компоненты: 4. сервер баз данных; 5. сервер приложений; 6. веб-сервер. Сервер баз данных должен обеспечивать хранение и целостность хранимых данных, создание резервных копий, ведение журнала транзакций, восстановление данных после сбоев. Сервер приложений должен обеспечивать обработку запросов, поступающих от клиентских приложений (через веб-сервер), формирование ответов на запрос в доступном пользователю виде (формирование пользовательских интерфейсов). Веб-сервер должен обеспечивать взаимодействие с оператором и внешними системами по HTTP / HTTPS протоколу в режиме «запрос-ответ» (получения запросов от пользователя и передачи ответа в виде соответствующей информации, обработанной серверами приложений). Взаимодействие Системы с пользователем должно отвечать требованиям модели «тонкого клиента» (т.е. представлять на стороне клиента (пользователя) лишь графический пользовательский интерфейс). Все составляющие Системы должны использовать единую методологию и отвечать единым принципам взаимодействия, надежности и управления. Перечень компонентов Модуля СЦ представлен в Таблице 4. Таблица 4. Перечень компонентов Модуля СЦ, в отношении которых выполняются работы по развитию № п.п. Наименование компонента Модуля СЦ Раздел ТЗ 1 Компонент регистрации событий 4.2.1. 2 Компонент отчетности 4.2.2 3 Компонент визуализации 4.2.3 4 «Интерактивная карта» (компонент создается) 4.2.4 5 Компонент администрирования 4.2.5 - 4.2. Требования к дорабатываемым функциям модуля СЦ 4.2.1. Развитие компонента регистрации событий (1 очередь) Должны быть выполнены следующие доработки: – обеспечение логирования действий пользователя, связанных с карточкой события; – доработка объектной модели в части создания новых типов сущностей (карточек) с учетом реализуемых интеграций с информационными ресурсами (силы и средства предупреждения и ликвидации ЧС и нештатных ситуаций на транспорте, ТС, ограничения воздушного пространства, неблагоприятные и опасные природные явления); – реализация механизма установления связи между сущностями в Модуле СЦ автоматизированным и ручным способами (события, природные явления, силы и средства предупреждения и ликвидации ЧС и нештатных ситуаций на транспорте, ограничения воздушного пространства, ОТИ, ТС и др.); – отображение в карточке установленных связей между сущностями. - 4.4.7. Требования к программному обеспечению Общесистемное ПО, используемое в составе Модуля СЦ, должно быть зарегистрировано в Едином реестре российских программ для электронных вычислительных машин и баз данных и соответствовать рекомендованным показателям эффективности и соответствующим им значениям индикаторов эффективности перехода подведомственных организаций на использование российского ПО, заданных Приказом Минцифры России от 18.01.2023 № 21 «Об утверждении методических рекомендаций по переходу на использование российского программного обеспечения, в том числе на значимых объектах критической информационной инфраструктуры Российской Федерации, и о реализации мер, направленных на ускоренный переход органов государственной власти и организаций на использование российского программного обеспечения в Российской Федерации». Применяемое в системе программное обеспечение должно соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации, постановления Правительства Российской Федерации от 23 декабря 2024 г. № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц» - Прикладное программное обеспечение должно отвечать следующим требованиям: – совместимость программных продуктов в части используемых технических средств, системного программного обеспечения и общесистемной инфраструктуры в пределах требований к техническому обеспечению, а также их информационная совместимость в пределах требований к информационному обмену; – обеспечение трехуровневой архитектуры с разделением на уровень хранения данных (сервер БД), уровень бизнес-логики (сервер приложений) и уровень представления ( - 4.4.7.1. Требования к инструментам разработки и процессу контроля версий программного обеспечения 4.4.7.1.1. Система контроля версий Для управления исходным кодом должна использоваться система контроля версий кода, развернутая в инфраструктуре Заказчика. 4.4.7.1.2. Правила именования веток Имя ветки должно соответствовать следующему формату: / / Категории веток: ? feature/ — разработка новой функциональности, а также рефакторинг или удаление существующей; ? fix/ — исправление ошибок; ? hotfix/ — срочные исправления, применяемые в обход стандартного процесса разработки; ? test/ — для проведения экспериментов, не влияющих на основную разработку. Идентификатор задачи: после категории указывается ссылка на задачу (issue) в системе контроля версий кода. Описание: добавляется краткое описание решаемой задачи в формате kebab-case (слова разделяются дефисами, например, add-user-auth). Примеры именования веток: ? feature/#123/add-payment-integration; ? fix/#45/correct-calculation-logic; ? hotfix/#67/urgent-database-connection-patch. 4.4.7.1.3. Правила именования коммитов Сообщение коммита должно соответствовать соглашению Conventional Commits и состоять из категории и описания: : ? fix — исправление ошибки. Примеры сообщений коммитов: ? feat: добавление формы регистрации пользователя; ? fix: исправление ошибки валидации email-адреса; ? refactor: оптимизация алгоритма сортировки данных; ? chore: обновление версий в файле dependencies. 4.4.7.1.4. Модель ветвления В процессе разработки используются следующие основные ветви: ? main / master — стабильная ветка, содержит только код, прошедший полное тестирование и развернутый в продуктивных контурах; ? dev — ветка для интеграции завершенных задач, предназначенная для сборки и тестирования в тестовых средах. Попадание кода в main осуществляется только через Merge Request (MR) из dev - 4.2.2. Развитие компонента отчетности (3 очередь) Должна быть обеспечена автоматизация процессов формирования отчетов о ЧС и нештатных ситуациях на транспорте, в т.ч. на основе данных из внешних систем. Включает следующие доработки: – разработка шаблонов отчетов в различных форматах (табличный, текстовый); – реализация выбора фотоматериалов для включения в справку; – форматирование содержимого справок с учетом правил русского языка в отношении окончаний слов (в зависимости от падежа, склонения, числа и рода); – автоматизированное формирование выводов к содержимому справки на основе настраиваемых критериев; – создание интерфейса выбора параметров (фильтрации) для формирования отчетов: o состав полей для включения в отчёт; o настройка диапазонов значений характеристик и дат; o порядок отображения полей; o настройка заголовка. – реализация способа подготовки отчётов в асинхронном режиме (очереди); – реализация интерфейса компонента формирования отчетности для отображения очереди формирования отчетов и статусов их подготовки; – экспорт отчётов в форматы xlsx, csv и справок в форматы pdf, docx. Необходимо разработать не менее 10 шаблонов отчетов и/или справок. Перечень, структура и содержание шаблонов должны быть согласованы с Заказчиком на этапе технического проектирования. - 4.2.3. Развитие компонента визуализации (2 очередь) В рамках развития компонента визуализации должны быть выполнены следующие доработки, обеспечивающие: – вывод перечней (списков) сил и средств предупреждения и ликвидации ЧС и нештатных ситуаций на транспорте с отображением мест их постоянного размещения (дислокации) на карте, включая: o отображение зон ответственности на карте; o возможность их фильтрации (по видам транспорта, регионам и пр.); o реализацию инструмента расчета расстояния (с использованием сети автомобильных и железных дорог) между местом события и местами дислокации сил и средств, а также вывода маршрутов на карте; – отображение зон (полигонов) с установленными ограничениями движения в воздушном пространстве на карте; – отображение термических точек; – реализация возможности отображения данных из паспорта региона, отображаемого в модуле iМинтранс (модуль АСУ ТК); – отображение краткой карточки сущностей и ОТИ (краткой информации и/или динамических характеристик объекта) при выборе объекта на карте с возможностью перехода в полную карточку сущности и ОТИ; – отображение данных от Росгидромета, предусматривающих: o отображение неблагоприятных и опасных природных явлений на карте (с заданным периодом обновления данных); o управление отображением явлений на карте, включая настройку состава отображаемых объектов, поиск, фильтрацию, с использованием соответствующей панели управления; o выведение краткой карточки явления при выборе объекта, с возможностью перехода в полную карточку объекта - – отображение на карте связанных сущностей и ОТИ; – реализация функции выбора темного и светлого стилей отображения элементов интерфейса, карточек сущностей, картографической основы и объектов, отображаемых на карте; – реализация механизма для выбора картографической основы в одном из распространенных форматов WMTS, TMS, MVT и др. Должна быть предусмотрена возможность настройки перечня картографических основ и параметров доступа к ним; – настройка базового набора дашбордов, содержащих преднастроенные виджеты о количестве событий в разрезе видов транспорта с возможностью перехода к исходным данным (карточкам событий, ОТИ и т.д.), с фильтрацией по параметрам. Параметры фильтрации должны быть определены на этапе технического проектирования. Должно быть обеспечено автоматическое и принудительное обновление данных, отображаемых на дашбордах - 4.4.7.1.5. Требования к используемым зависимостям (библиотекам) Все внешние зависимости проекта должны быть зафиксированы с указанием точных версий. Для контроля версий зависимостей в репозиторий обязательно должны быть включены следующие файлы: · Для JavaScript: package-lock.json или yarn.lock; · Для Python: requirements.txt (с зафиксированными версиями) или Pipfile.lock; · Для Go: go.mod и go.sum; Загрузка всех зависимостей должна производиться исключительно через внутренний прокси-репозиторий Заказчика, настроенный в соответствующем системе менеджере пакетов. Запрещается: · Использование плавающих версий (например, ^1.2.3, ~4.5.0, latest); · Использование библиотек, содержащих критические уязвимости, в том числе зарегистрированные в реестре CVE (Common Vulnerabilities and Exposures). 4.4.7.1.6. Требования к процессу непрерывной интеграции (CI) Сборка программного обеспечения, включая этапы компиляции, тестирования и анализа кода, должна выполняться исключительно в инфраструктуре непрерывной интеграции Заказчика. 4.4.7.1.7. Требования к хранению артефактов сборки Все артефакты сборки (результирующие пакеты, Docker-образы и т.д.) подлежат обязательному хранению в предназначенной для этого инфраструктуре Заказчика (артефакторий). Запрещается размещение финальных артефактов сборки на сторонних ресурсах - 4.4.8. Требования к техническому обеспечению Количество серверов, подключаемых и настраиваемых сервисов, их параметров, схемы соединений и настройки межсетевого взаимодействия должны быть согласованы с Заказчиком на этапе № 1 Техническое проектирование. Доступ к комплексу технических средств предоставляется Заказчиком по письменному запросу Подрядчика. Применяемые в Системе программно-аппаратные и аппаратные комплексы должны соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации», требованиям Постановления Правительства Российской Федерации от 23 декабря 2024 г. № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц». Модуль СЦ, работающий в составе АСУ ТК, развернут на вычислительных мощностях ГЦОД СИЦ Минтранса России - 4.5. Общие технические требования 4.5.1. Требования к численности и квалификации персонала и пользователей Модуля СЦ Программное обеспечение Модуля СЦ не должно требовать изменения штатной численности персонала Заказчика. Программное обеспечение Модуля СЦ не должно требовать наличия у пользователей дополнительной квалификации в сфере информационных технологий, кроме базовых знаний в обращении с персональным компьютером, базовых навыков работы в интернет-обозревателях и знаний о Модуле СЦ в объеме документов Руководство пользователя, Руководство администратора - 4.2.4. Создание компонента «Интерактивная карта» (2 очередь) В составе создаваемого компонента должны отображаться данные, доступные в компоненте визуализации. Требования к интерфейсу интерактивной карты: – интерактивная карта должна быть представлена в виде объемной карты с учетом макетов, представленных в Приложении А к ТЗ; – интерфейс должен корректно отображаться на экранах мониторов (разрешение Full HD 1920?1080), телевизоров (разрешение 4К 3840?2160), жидкокристаллических панелей для видеостены, используемой Заказчиком, с параметрами каждой панели: диагональ 55 дюймов, разрешение 1920x1080; – интерфейс должен корректно отображаться на планшетных устройствах с диагональю экрана 10-12 дюймов, конкретные требования должны быть уточнены на этапе технического проектирования; – должна быть обеспечена кластеризация и генерализация отображения объектов на карте при изменении масштаба; – должно быть обеспечено отображение основных характеристик объектов при выборе их на карте; – должно быть обеспечено управление отображением слоев на карте; – должна быть обеспечена настройка цветовой индикации отображаемых объектов транспортной инфраструктуры; – должно быть обеспечено отображение легенды карты, содержащей отображаемые объекты на карте; – должна быть обеспечена возможность одновременного отображения не менее 5 000 ОТИ и ТС на карте. - На интерактивной карте должны быть отображены подвижные объекты совместно с объектами транспортной инфраструктуры (ОТИ), включая следующие возможности: § отображение местоположения транспортных средств (воздушный, водный и автомобильный транспорт) на карте в режиме реального времени (с заданным периодом обновления данных); § отображение маршрутов движения всех ТС за выбранный период времени, в том числе с использованием эффектов анимации; § отображение маршрутов движения ТС, связанных с карточкой события: ТС, являющихся участниками события, и ТС, находящиеся в заданном радиусе от события; § управление отображением сущностей и ОТИ на карте, включая настройку состава отображаемых объектов, поиск, фильтрацию, с использованием соответствующей панели управления и наглядным представлением результатов; § автоматическое изменение вида отображения объектов (цветовая индикация) по заданным условиям (например, при достижении критических значений параметров, характеризующих функционирование объекта); Должна обеспечиваться производительность обновления изображения на экране в 30 кадров в секунду на тестовой конфигурации пользовательского устройства (модель Бештау AIO2402/B560, входящая в Реестр российской промышленной продукции под номером 10394100 или аналог) при одновременном отображении не менее 5 000 объектов и 200 уникальных моделей объектов. Макеты интерфейсов Модуля СЦ должны быть предварительно согласованы с Заказчиком и разработаны с учетом требований ГОСТ Р ИСО 9241-161-2016 «Элементы графического пользовательского интерфейса» - 4.5.2. Требования к режимам функционирования Модуля СЦ Модуль СЦ должен предусматривать наличие следующих режимов работы: – штатный; – регламентный (профилактический); – аварийный. Основным режимом функционирования является штатный. В штатном режиме все компоненты корректно и полностью выполняют свои функции. Перерывов в работе как Модуля СЦ в целом, так и одного, либо нескольких компонентов не предусмотрено. Режим регламентного (профилактического) обслуживания предназначен для проведения работ по обновлению и техническому обслуживанию компонентов Модуля СЦ, а также резервному копированию данных. При работе в данном режиме допускаются перерывы в работе Модуля СЦ с предварительным информированием пользователей. Состав процедур по регламентному обслуживанию Модуля СЦ и их периодичность определяются Подрядчиком в процессе выполнения работ по созданию Модуля СЦ. В режиме регламентного (профилактического) обслуживания Модуль СЦ может функционировать с частичным ограничением своих функциональных возможностей, либо без ограничения, но со снижением показателей надежности и производительности. Перевод в данный режим работы должен осуществляться сразу после начала выполнения любой операции, отнесенной к этому режиму, с последующим возвратом в штатный режим функционирования сразу после ее завершения. Перевод в указанный режим должен осуществляться при возникновении необходимости проведения работ по обновлению и техническому обслуживанию компонентов Модуля СЦ, а также резервному копированию данных с условием предварительного оповещения пользователей. Аварийный режим функционирования характеризуется отказом одной или нескольких подсистем, вызванных выходом из строя аппаратного и/или программного обеспечения, а также в случае временной неработоспособности каналов связи между серверами. - В аварийном режиме осуществляется поиск неисправностей и проведение работ по их устранению. Перевод в аварийный режим должен осуществляться при возникновении сбоев, аварий и прочих незапланированных воздействий, сразу после наступления одной или нескольких аварийных ситуаций, с последующим возвратом в штатный режим функционирования сразу после окончания восстановительных работ. ПО Модуля СЦ должно обладать надежностью, обеспечивающей работу пользователей в произвольном режиме и оперативное восстановление работоспособности при сбоях. В целях обеспечения надежного функционирования ПО должно предусматривать: – сохранение целостности данных при нештатном завершении работы компонентов Модуля СЦ; – сохранение работоспособности программного обеспечения при некорректных действиях пользователя; – резервное копирование базы данных Модуля СЦ. – время восстановления работоспособности Модуля СЦ после отказа не более 4 часов. – отказоустойчивость на уровне 99% при единовременной количестве не менее 200 пользовательских сессий в Модуле СЦ. Указанные характеристики приведены без учета характеристик надежности инфраструктуры и времени передачи информации по каналам связи. При возникновении сбоев в аппаратном обеспечении, включая аварийное отключение электропитания, Модуль СЦ должен автоматически восстанавливать свою работоспособность (не требовать перенастройки) после устранения сбоев и корректного перезапуска аппаратного обеспечения - 5. СОСТАВ И СОДЕРЖАНИЕ РАБОТ ПО РАЗВИТИЮ И ТЕХНИЧЕСКОЙ ПОДДЕРЖКЕ МОДУЛЯ СЦ (КАЛЕНДАРНЫЙ ПЛАН) - Сдача-приемка результатов выполненных работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная техническая документация, а также результаты работ предоставляются Заказчику в порядке, предусмотренном Контрактом и ТЗ, до размещения Подрядчиком в ЕИС документа о приемке. Документ о приемке размещается в ЕИС по каждому этапу в соответствии с условиями Контракта. Этапы выполнения работ по развитию Модуля СЦ приведены в Таблице 11. Таблица 11. Этапы выполнения работ по развитию Модуля СЦ. № этапа Наименование этапа Результат (отчетная документация) Срок исполнения этапа - - Значение характеристики не может изменяться участником закупки - 1 Техническое проектирование Сопроводительным письмом предоставляются Заказчику: · Технический проект, включая следующие документы: – Ведомость технического проекта; – Ведомость машинных носителей информации – Пояснительная записка; – Описание информационного обеспечения системы; – Описание автоматизируемых функций; – Схема функциональной структуры; – Описание организации информационной базы; – Описание программного обеспечения; · Макеты экранных форм компонента «Интерактивная карта»; · Руководство по безопасной разработке программного обеспечения; · Документ о приемке Начало: с даты заключения контракта Окончание: не позднее 31.07.2026 - 2 Услуги по технической поддержке Модуля СЦ (с даты заключения контракта по 10.09.2026) По окончании оказания Услуг сопроводительным письмом предоставляются Заказчику: – Отчет об оказанных Услугах по технической поддержке; – Актуальные на дату окончания оказания Услуг по данному этапу исходные коды прикладного ПО на электронном носителе (в случае внесения изменений); – Инструкция по сборке и развертыванию (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство пользователя (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство администратора (в случае внесения изменений); – Документ о приемке Начало: с даты заключения контракта Окончание: не позднее 10.09.2026 - 3 Разработка программного обеспечения (1 очередь, пп. 4.2.1, 4.2.6 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ; – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 1 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 1 очереди; – Руководство по резервному копированию; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 16.09.2026 - 4 Разработка программного обеспечения (2 очередь, пп. 4.2.3, 4.2.4 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ. – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 2 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 2 очереди; – Руководство по резервному копированию; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 25.09.2026 - 5 Разработка программного обеспечения (3 очередь, пп. 4.2.2, 4.2.5 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ; – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 3 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 3 очереди; – Руководство по резервному копированию; – Описание ролевой модели; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 09.10.2026 - 6 Опытная эксплуатация (1 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акт о завершении опытной эксплуатации 1 очереди; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке 17.09.2026 Окончание: не позднее 26.10.2026 - 7 Опытная эксплуатация (2 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акт о завершении опытной эксплуатации 2 очереди; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке 26.09.2026 Окончание: не позднее 26.10.2026 - 8 Опытная эксплуатация (3 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Акт о завершении опытной эксплуатации 3 очереди; – Документ о приемке Начало: с 10.10.2026 Окончание: не позднее 26.10.2026 - 9 Приемочные испытания Сопроводительным письмом предоставляются Заказчику: – Программа и методика приёмочных испытаний; – Протокол приемочных испытаний; – Исходные коды и дистрибутивы на электронном носителе (при условии внесения изменений, с учетом доработок по результатам опытной эксплуатации и проведенных испытаний); – Комплект рабочей документации на Модуль СЦ (при условии внесения изменений, с учетом доработок по результатам опытной эксплуатации и проведенных испытаний); – Акт приемки Системы в эксплуатацию; – Акт приемки-передачи исключительных прав на объект; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке; – Документы в соответствии с разделом 4.5.9 ТЗ; – Обеспечение гарантийных обязательств Начало: с 27.10.2026 Окончание: не позднее 10.11.2026 - 10 Услуги по технической поддержке Модуля СЦ (с 11.09.2026 по 15.12.2026) По окончании оказания Услуг сопроводительным письмом предоставляются Заказчику: – Отчет об оказанных Услугах по технической поддержке; – Актуальные на дату окончания оказания Услуг по данному этапу исходные коды прикладного ПО на электронном носителе (в случае внесения изменений); – Инструкция по сборке и развертыванию (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство пользователя (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство администратора (в случае внесения изменений); – Документ о приемке Начало: с 11.09.2026 Окончание: не позднее 15.12.2026 - Работы по развитию Системы (за исключением этапов проведения опытной эксплуатации и услуг по технической поддержке) могут быть выполнены досрочно. При досрочном выполнении работ (этапов работ) Подрядчик в письменной форме уведомляет Заказчика о готовности представить для приемки результаты проведения работ в соответствии с требованиями Контракта. Подрядчик также вправе досрочно приступать к работам в рамках очередного этапа при наличии технической, организационной готовности - при условии получения соответствующего согласования Заказчиком. Сдача-приемка результатов выполненных работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная, техническая документация, а также результаты Работ по каждому этапу предоставляется Заказчику в порядке, предусмотренном Контрактом и настоящим Техническим заданием, до размещения Подрядчиком в Единой информационной системе в сфере закупок документа о приемке. Документ о приемке размещается в ЕИС по каждому этапу в соответствии с условиями Контракта. Согласование документов осуществляется в электронном виде посредством переписки с адресов электронной почты Заказчика и Подрядчика, указанных в контракте. - 6. ПОРЯДОК РАЗРАБОТКИ МОДУЛЯ СЦ - Проектирование Модуля СЦ должно включать разработку следующих документов: – Ведомость технического проекта; – Ведомость машинных носителей информации – Пояснительная записка; – Описание информационного обеспечения системы; – Описание автоматизируемых функций; – Схема функциональной структуры; – Описание организации информационной базы; – Руководство по безопасной разработке программного обеспечения; – Описание программного обеспечения; – Макеты экранных форм компонента «Интерактивная карта». Структура документов должна соответствовать ГОСТ Р 59795-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов». Разработка Модуля СЦ должна включать в себя: – разработку программного обеспечения в части новых функций Модуля СЦ; – сборка исходного кода, развертывание и настройку доработанного программного обеспечения Модуля СЦ на вычислительных мощностях Заказчика (тестовый контур); – Комплект рабочей документации на Модуль СЦ; – разработку документа «Программа и методика предварительных испытаний»; – разработку документа «Программа и методика приемочных испытаний»; – разработку документа «Программа опытной эксплуатации». Структура документов должна соответствовать ГОСТ Р 59795-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов». В ходе выполнения работ формируется правоустанавливающая, отчетная, рабочая и техническая документация в соответствии с Контрактом и Календарным планом, приведенном в разделе 5. - - Значение характеристики не может изменяться участником закупки - 6.1. Сведения о гарантийном обслуживании Модуля СЦ Под гарантией понимается устранение Подрядчиком своими силами и за свой счет допущенных по его вине недостатков, выявленных после приемки выполненных Работ, как в работе самой Модуля СЦ, так и недостатков в отчетной документации. Если в период гарантийного срока обнаружатся недостатки, то Подрядчик обязан устранить их за свой счет, в сроки, установленные Заказчиком. Гарантийный срок в этом случае продлевается на период устранения недостатков. Срок гарантии: 1 год с даты приемки Заказчиком результатов исполнения Этапа № 9 контракта. Подрядчиком должны быть внесены соответствующие исправления в техническую и рабочую документацию (указанную в пунктах 5 и 6 настоящего ТЗ), связанные с устранением замечаний к работе Модуля СЦ или в случае выявления Заказчиком недостатков в такой документации в период гарантийного срока. Внесение изменений в документацию технического и рабочего проектирования осуществляется в соответствии с ГОСТ 2.503-2023 и ГОСТ Р 2.504-2021. - 7. ПОРЯДОК КОНТРОЛЯ И ПРИЕМКИ РЕЗУЛЬТАТОВ ВЫПОЛНЕНИЯ РАБОТ ПО РАЗВИТИЮ МОДУЛЯ СЦ - Испытания должны быть организованы и проведены в соответствии с ГОСТ Р 59792-2021 «Информационная технология. Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем». Должны быть проведены следующие виды испытаний: – предварительные испытания; – опытная эксплуатация; – приемочные испытания. Указанные виды испытаний проводятся в отношении не функциональных требований и функциональных возможностей, разрабатываемых в соответствии с настоящим ТЗ. Отдельные виды испытаний проводятся поэтапно в сроки, установленные Календарным планом. Предварительные испытания, опытная эксплуатация, приемочные испытания проводятся комиссией, создаваемой организационно-распорядительным документом Заказчика, который должен определять состав комиссии, порядок ее работы. Методы предварительных испытаний и порядок их проведения должны быть определены в документе «Программа и методика предварительных испытаний», который должен быть утвержден Заказчиком до начала предварительных испытаний. По результатам предварительных испытаний оформляется Протокол предварительных испытания и Акт о приемке в опытную эксплуатацию. Порядок проведения и методы испытаний во время опытной эксплуатации должны быть определены в документе «Программа опытной эксплуатации», который должен быть утвержден Заказчиком до начала опытной эксплуатации. Ход и результаты опытной эксплуатации отражаются в документе «Журнал опытной эксплуатации», и учитываются в ходе приемочных испытаний. По результатам опытной эксплуатации подписывается Акт о завершении опытной эксплуатации - - Значение характеристики не может изменяться участником закупки - До момента подключения внешних ИС, Подрядчиком могут быть использованы эмуляторы ИС для прохождения предварительных испытаний, опытной эксплуатации и приемочных испытаний. В рамках опытной эксплуатации должны быть проведены мероприятия по нагрузочному тестированию Модуля СЦ. Документ «Программа и методика приемочных испытаний» должен быть разработан с учетом недостатков, выявленных в ходе опытной эксплуатации, утвержден Заказчиком до начала приемочных испытаний, при этом проверки Модуля СЦ в части не устраненных недостатков, выявленных в процессе опытной эксплуатации, должны быть вынесены в отдельный раздел «Программы и методики приемочных испытаний». В процессе приемочных испытаний должно быть проверено устранение недостатков, полученных в ходе опытной эксплуатации. После завершения устранения всех замечаний, препятствующих приемке Системы в эксплуатацию, перечисленных в Протоколе приемочных испытаний, Подрядчик должен письменно уведомить Заказчика о том, что все замечания устранены, после чего приемочные испытания по решению Заказчика могут быть проведены повторно. Процедура приемочных испытаний проводится до подписания Протокола приемочных испытаний, не содержащего замечаний, препятствующих приемке Системы в эксплуатацию. Приемочные испытания Системы считаются завершенными успешно, если Протокол приемочных испытаний не содержит замечаний, препятствующих приемке Системы в эксплуатацию - 8. ТРЕБОВАНИЯ К СОСТАВУ И СОДЕРЖАНИЮ РАБОТ ПО ПОДГОТОВКЕ МОДУЛЯ СЦ К ВВОДУ В ЭКСПЛУАТАЦИЮ - По результатам проведения приемочных испытаний оформляется Протокол приемочных испытаний и Акт приемки в эксплуатацию. В случае, если взаимодействие с внешними системами не может быть проверено на средах постоянной эксплуатации взаимодействующих систем (по причине неготовности со стороны внешней системы или иным причинам), функции взаимодействия, разработанные в соответствии с требованиями ТЗ, должны быть проверены на тестовых данных с использованием программ-имитаторов взаимодействия. По результатам выполнения этапа приемочных испытаний должны быть подготовлены материалы для регистрации доработанной версии Модуля СЦ (объекта учета) в НФАП в соответствии с требованиями постановления Правительства Российской Федерации от 30 января 2013?г. №?62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин» (с изменениями и дополнениями) в части обязательности размещения результатов работ в национальном фонде алгоритмов и программ для электронных вычислительных машин. Сдача-приемка результатов выполнения Работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная, техническая документация, а также программное обеспечение предоставляется Заказчику в порядке, предусмотренном Контрактом и ТЗ до размещения Подрядчиком в Единой информационной системе в сфере закупок документа о приемке. Результаты проведения опытной эксплуатации, предварительных и приемочных испытаний должны быть зафиксированы в соответствующих протоколах и актах. Выявленные отклонения от настоящего ТЗ, оформляются как недостатки Модуля СЦ - - Значение характеристики не может изменяться участником закупки - Протоколы предварительных и приемочных испытаний должны содержать вывод о соответствии Модуля СЦ предъявляемым требованиям, а также сроки устранения замечаний и реализации рекомендаций, сформулированных комиссией в ходе предварительных и приемочных испытаний. Условием для передачи Модуля СЦ в промышленную эксплуатацию является устранение всех замечаний. Документация на Модуль СЦ и ее части (техническая и рабочая) должна содержать исчерпывающее описание принятых проектных решений в объеме, достаточном для ее дальнейшего развития и эксплуатации. Техническая и рабочая документация должна содержать описание разработанных результатов работ, в том числе программ для ЭВМ, прикладных программных интерфейсов, алгоритмов и протоколов информационного взаимодействия, технических требований, спецификаций и форматов обмена данными для взаимодействия с другими информационными системами, в объеме, достаточном для их установки, настройки, эксплуатации и развития в дальнейшем без привлечения Подрядчика. Исходные коды передаются в виде и составе, позволяющем провести: – сборку (компиляцию) Модуля СЦ в контролируемой Заказчиком среде; – установку полученной Модуля СЦ на специально подготовленную контролируемую Заказчиком инфраструктуру; – проверку функциональных возможностей Модуля СЦ; – оформление Модуля СЦ в качестве объекта национального фонда алгоритмов и программ для электронных вычислительных машин - 8.1. Требования, предъявляемые в соответствии с Приказом Минцифры России от 17.12.2020 № 715 «Об утверждении типовых условий контрактов на выполнение работ по созданию и (или) развитию (модернизации) государственных (муниципальных) и (или) иных информационных систем» Передача исходных кодов, разработанных в ходе выполнения работ, программ для электронных вычислительных машин (далее – программа для ЭВМ) должна сопровождаться передачей всех необходимых для сборки и запуска программы для ЭВМ библиотек зависимостей, программных сценариев (скриптов) для проведения установки (развертывания) программы для ЭВМ. Подрядчик в процессе сдачи-приемки работ по Контракту должен провести демонстрацию процесса и установки (развертывания) разработанных программ для ЭВМ. Документация на Модуль СЦ должна содержать описание принятых проектных решений в объеме, достаточном для ее дальнейшего развития и эксплуатации - 9. ТРЕБОВАНИЯ К ДОКУМЕНТИРОВАНИЮ - 9.1. Общие требования Документация на Модуль СЦ должна быть разработана в составе, указанном в разделах 5-8 данного ТЗ, и должна удовлетворять требованиям комплекса стандартов и руководящих документов на автоматизированные системы: – ГОСТ Р 2.105-2019 в части оформления текстовых документов; – ГОСТ 34.201-2020 в части наименования и обозначения документов. Документация на Модуль СЦ должны оформляться на листах формата А4. Допускается для размещения рисунков и таблиц использование листов формата А3 с подшивкой по короткой стороне листа. Документы объемом более 25 (двадцати пяти) листов должны содержать информационную часть, состоящую из аннотации и содержания. Исходные коды должны быть представлены в 1 (одном) экземпляре на электронном носителе, отчетные материалы должны быть представлены в 2 (двух) экземплярах на бумажном носителе (по одному экземпляру для Заказчика и Подрядчика) и в 1 (одном) экземпляре на электронном носителе в формате документов DOCX и PDF. При разработке документов на Модуль СЦ допускается отклонение от требований комплекса стандартов, описанных выше. Документам на Модуль СЦ должны в обязательном порядке присваиваться уникальные децимальные номера в соответствии с порядком, установленном в ГОСТ 34.201-2020. Документ «Программа и методика предварительных испытаний» должен включать приложения с формой протокола предварительных испытаний и формой акта приемки в опытную эксплуатацию. Документ «Программа опытной эксплуатации» должен включать приложение с формой журнала опытной эксплуатации. Документ «Программа и методика приемочных испытаний» должен включать приложения с формой протокола приемочных испытаний и формой акта приемки в эксплуатацию - - Значение характеристики не может изменяться участником закупки - 10. ИСТОЧНИКИ РАЗРАБОТКИ - 10.1. Список литературы Специальная литература для разработки ТЗ не использовалась. 10.2. Нормативно-методические документы Список используемых нормативно-методических документов представлен в разделе 1.6 технического задания. ? Приложение А Эскизы визуального оформления компонента «Интерактивная карта» - - Значение характеристики не может изменяться участником закупки - Приложение Б Параметры оказания услуг - Б.2. Приоритеты и регламентные сроки решения обращений (заявок) В зависимости от уровня сбоя в работе Системы обращению (заявке) присваивается один из следующих приоритетов, а также в зависимости от приоритета обращения (заявки) устанавливаются следующие контрольные сроки решения в соответствии с таблицей ниже (Таблица Б.2.1). Таблица Б.2.1 – Приоритеты и регламентные сроки решения обращений (заявок) № п/п Приоритет Максимальное время реагирования Время решения (срок выполнения) Описание приоритета По информационно-консультационной поддержке сотрудников Заказчика и пользователей Системы 1 - не более 1 часа не более 10 часов - По решению инцидентов, связанных с работой ППО: 1 Критический не более 30 минут не более 4 часов - полная недоступность ППО; - недоступность ключевых функций - ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО; - невозможность информационного обмена с ППО для ИС более 4 часов 2 Высокий не более 1 часа не более 8 часов - ошибки/сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; - снижение быстродействия СПО (время отклика ППО на операции превышает 30 секунд); - недоступность управления правами и ролями пользователей 3 Средний не более 4 часов не более 24 часов - невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым -недоступность функции формирования отчетов 4 Низкий не более 8 часов не более 40 часов - отклонение в работе ППО, не влияющее на корректную работу функций; - другие сбои и ошибки, затрагивающие основные функции ППО - - Значение характеристики не может изменяться участником закупки - По адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) 1 Критический не более 40 минут не более 8 часов - изменения, необходимые при проведении аварийно-восстановительных работ для возобновления работоспособности Системы; - изменения, связанные с критичными ошибками, блокирующими возможность оказания государственных услуг и/или чтение и внесение данных в Систему 2 Высокий не более 1 часа не более 40 часов - изменения, относящиеся к обеспечению работоспособности основной функциональности Системы, устраняют выявленные дефекты в работе Системы, оказывающие существенное влияние на работу пользователей в Системе; - изменения, затрагивающие три и более подсистемы/модуля Системы для адаптации 3 Средний не более 4 часов не более 72 часов - изменения, связанные с развитием/улучшением/оптимизацией Системы и выводом новой функциональности в штатном режиме для одного-двух модулей/подсистем; - изменения, связанные с развитием интеграционных механизмов Системы, например обновление существующих и/или реализация новых видов сведений СМЭВ, обновление существующих и/или реализация новых API, адаптация и/или изменение механизмов импорта и экспорта данных Системы и т.д. 4 Низкий не более 8 часов не более 160 часов - изменения, связанные с ошибками/корректировкой/изменением в отображении информации в пользовательском графическом интерфейсе Системы (графика, текст, органы управления, элементы интерфейса) - По устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности 1 Критический не более 30 минут не более 24 часов - критические уязвимости, влияющие на возможную полную недоступность ППО, ключевых функций Системы, ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО без возможности восстановления работоспособности Системы. - Критический уровень CVSS > 8.0 2 Высокий не более 1 часа не более 84 часов - критические уязвимости, влияющие на ошибки и сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО. - Высокий уровень CVSS 5.0 - 8.0 3 Средний не более 4 часов не более 120 часов - уязвимости, влияющие на невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым - Средний уровень CVSS 2.0 - 4.9 4 Низкий не более 8 часов не более 160 часов - уязвимости, влияющие на отклонение в работе ППО, не влияющее на корректную работу функций; - другие сбои и ошибки, затрагивающие основные функции ППО - Низкий уровень CVSS < 2.0 - Взаимодействие Заказчика и Подрядчика в части регистрации и контроля времени реагирования и решения обращения (заявки) осуществляется через СРО. Заказчик предоставляет Подрядчику доступ к СРО после заключения Контракта. Поступившие от разных пользователей заявки по поводу однотипных инцидентов или имеющие общую причину должны объединяться в одну заявку. Срок выполнения включает время диагностики инцидента, в ходе которого определяется причина инцидента (проблемы) и способ его устранения. Подрядчик должен обеспечить функционирование Модуля СЦ в соответствии с требованиями и параметрами, указанными в настоящем ТЗ и Регламенте оказании услуг. Основные параметры быстродействия типовых операций в Модуле СЦ указаны в таблице ниже (таблица Б.2.2). Таблица Б.2.2 - Параметры быстродействия Модуля СЦ № п/п Наименование параметра Значение (секунд) 1 Среднее время получения сообщения из очереди сообщений 10 2 Среднее время получения ответа от Системы 5 3 Среднее время открытия карточки реестра 5 - Б.1. Базовые параметры оказания Услуг Базовые параметры оказания Услуг приведены ниже: – режимы оказания Услуг (таблица Б.1.1); – сроки предоставления отчетности (таблица Б.1.2). Таблица Б.1.1 - Режимы оказания Услуг № п/п Параметр Значение - 1 Режим работы Системы Круглосуточно (24х7) 2 Режим доступности информационно-консультационной поддержки пользователей Системы 2.1 Прием и регистрация обращений (заявок) в СРО Регистрация обращений (заявок) производится круглосуточно в режиме 24х7, без праздников и выходных дней. Обработка заявок первой линией поддержки осуществляется в рабочие дни с 9 до 18 часов 2.2 Консультирование сотрудников Заказчика и пользователей Системы в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 3 Режим доступности по решению инцидентов, связанных с работой ППО: 3.1 - приоритет «Критический» Круглосуточно (24х7) 3.2 - приоритет «Высокий» Круглосуточно (24х7) 3.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 3.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4 Режим доступности услуг по адаптации, конфигурации и коррекционному сопровождению Системы 4.1 - приоритет «Критический» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.2 - приоритет «Высокий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 5 Режим доступности по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности 5.1 - приоритет «Критический» Круглосуточно (24х7) 5.2 - приоритет «Высокий» Круглосуточно (24х7) 5.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 5.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) - Таблица Б.1.2. Сроки предоставления отчетности, с момента получения запроса № п/п Параметр Значение 1 Предоставление отчета об оказанных услугах за произвольный период 10 рабочих дней 2 Предоставление подробной информации по инциденту с приоритетом «Критический» 16 рабочих часов 3 Предоставление актуализированной документации 10 рабочих дней - Приложение В Регламент оказания услуг - Термины и сокращения В настоящем регламенте используются следующие термины и сокращения на русском и английском языках: Термины/сокращения Полное наименование/описание БЗ (База знаний) База данных Системы регистрации обращений (заявок), созданная для сбора, хранения и поиска способов решения известных проблем в рамках Системы Жизненный цикл обращения (заявки) Совокупность статусов, по которым проходит обращение (заявка), и правила перехода обращения (заявки) из одного статуса в другой Заказчик ФГБУ «СИЦ Минтранса России» – Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» ЗНИ Запрос на изменение – тип заявки, предполагающий внесение изменений в прикладное программное обеспечение Системы ЗНО Запрос на обслуживание – тип заявки, предполагающий работы по предоставлению консультации, предоставление доступа к Системе или стандартизированные типовые изменения конфигураций Системы Инцидент Тип заявки, классифицируемый как нештатное событие в работе компонентов функциональных задач Системы, которое привело или может привести к нарушению или снижению качества функционирования Системы ИС Информационная система Исполнитель Организация, которая определяется по результатам конкурсных процедур Классификация Анализ и заполнение классификационных полей справочными значениями, определяющими последовательность действий и этапов жизненного цикла заявки, а также порядок рассмотрения заявок Консультация Разъяснения по алгоритму работы, требуемых настроек прикладного программного обеспечения и технологии обработки данных при работе с Системой, предоставление информации Маршрутизация Определение процесса движения обращения (заявки) в Системе управления заявками между уровнями технической поддержки и организационными структурами на уровнях поддержки путем назначения обращения (заявки) в соответствии с его классификацией и выставленным приоритетом - - Значение характеристики не может изменяться участником закупки - Обращение (заявка) Устное или письменное обращение пользователя АСУ ТК с вопросом, касающимся работоспособности АСУ ТК, по одному из определённых каналов связи: электронная почта, Система регистрации обращений (заявок) Пользователь Инициатор обращения (заявки) или пользователь Системы ППО Прикладное программное обеспечение Предмет обращения Справочник, классифицирующий типовые запросы в Системе регистрации обращений (заявок), характерные для Системы, выбранное значение определяет маршрутизацию обращения (заявки) (группу ответственных сотрудников) Приоритизация Значение, определяющее время, очередность решения обращений (заявок), ресурсы, привлекаемые для решения обращений (заявок), . Приоритет устанавливается в соответствии с масштабом выявленной проблемы, которая привела или может привести к нарушению или снижению качества функционирования Системы Релиз Выпуск версии прикладного программного обеспечения Системы, от разработки до тестирования и планового обновления Системы на продуктивной среде для установки изменений, связанных с развитием/улучшением/оптимизацией Системы Система, АСУ ТК, Информационно-аналитическая система регулирования на транспорте Информационно-аналитическая система, предназначенная для автоматизации и информационно-аналитического обеспечения процессов управления развитием транспортного комплекса Российской Федерации, обеспечения публичности деятельности органов государственного управления транспортным комплексом, а также обеспечения процессов оказания государственных услуг в электронном виде в сфере транспорта СМЭВ Система межведомственного электронного взаимодействия СПО Системное программное обеспечение СРО Система регистрации обращений (заявок) Статус обращения (заявки) Текущее состояние обращения (заявки) в жизненном цикле процесса оказания технической поддержки Системы СУБД Система управления базами данных - Уровень технической поддержки Организационно-структурная часть технической поддержки, имеющая определённые организационно-нормативными документами зоны ответственности, обязанности, а также временные нормативы, в течение которых эти обязательства должны выполняться либо эскалироваться на следующий уровень технической поддержки Услуги Услуги по технической поддержке Информационно-аналитической системы регулирования на транспорте АСУ ТК ФИО Фамилия, имя, отчество Эскалация Процедура повышения внимания к обращению (заявке) путем повышения его приоритета и/или передачи на следующий уровень технической поддержки, а также привлечение ролей, которые могут принимать решения без передачи на следующий уровень технической поддержки API Англ. Application Programming Interface — программный интерфейс приложения, интерфейс прикладного программирования — описание способов (набор классов, процедур, функций, структур или констант), которыми одна компьютерная программа может взаимодействовать с другой программой - CVSS Англ. Common Vulnerability Scoring System - открытый стандарт, используемый для расчета количественных оценок уязвимости в безопасности компьютерной системы, обычно с целью понять приоритет ее исправления. В современном инструментарии информационной безопасности используется версия 3.0 и выше с дополнительными метриками к базовым оценкам ID Англ. Identifier – идентификатор, уникальный признак объекта, позволяющий отличать его от других объектов, то есть, идентифицировать SLA Англ. Service Level Agreement - утвержденные условия по обработке обращения (заявки) с установленными метриками времени, которые определяют пороговые значения для эскалации в зависимости от статуса обращения (заявки) (например, время реакции – время от регистрации до осуществления первичной обработки, время решения – время от регистрации обращения (заявки) до его решения и т.д.) SQL Англ. Structured Query Language — «язык структурированных запросов», — декларативный язык программирования, применяемый для создания, модификации и управления данными в реляционной базе данных, управляемой соответствующей СУБД - 1 Общие сведения 1.1 Полное наименование Услуг Оказание услуг по технической поддержке Модуля СЦ АСУ ТК в 2026 году. 1.2 Предмет Регламента оказания услуг Требования Технического задания - 2 Общие положения 2.1 Цель и задачи оказания услуг Целью технической поддержки Системы является обеспечение ее стабильного и безопасного функционирования и эксплуатации, предупреждение, выявление и устранение сбоев в работе Системы и минимизация их неблагоприятного влияния. Для достижения поставленной цели требуется решение следующих задач: 1. Обеспечение информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы. 2. Поддержание параметров функционирования ППО Системы, удовлетворяющих требованиям производственных процессов, включая их непрерывность. 3. Обеспечение бесперебойного функционирования ППО и своевременное устранение сбоев и аварийных ситуаций в Системе. 4. Своевременное устранение уязвимостей при выявлении таковых, в соответствии с требованиями к обеспечению информационной безопасности. 5. Адаптация, конфигурирование, коррекция программного обеспечения в соответствии с изменениями нормативно-правовой базы и запросами уполномоченных сотрудников органов государственной власти, включая выполнение процедур тестирования и участие в обновлениях ППО на стендах Заказчика. 6. Обеспечение сохранения работоспособности ППО в изменяемой среде эксплуатации. 7. Ведение документации по настоящему контракту и инициирование актуализации документации на Систему по результатам обработки запросов Заказчика и внесения соответствующих изменений в ППО - 2.2 Общее описание процесса оказания сопровождения (технической поддержки) Системы Процесс оказания технической поддержки Системы включает: 1. Поступление обращений (заявок) от пользователей и их регистрацию. 2. Сопровождение обращений (заявок) в соответствии с их классификацией и приоритизацией, в том числе, с их последующей эскалацией. 3. Определение ролей и регламент их взаимодействия при осуществлении деятельности по процессу. 4. Решение обращений (заявок) в установленные настоящим Регламентом сроки. 5. Взаимодействие между 1-м, 2-м и 3-м уровнями технической поддержки, в том числе, с формированием заданий для сопровождения Системы. 6. Контроль качества выполняемых Исполнителем работ, состоящий из проверки сценария, приводящего к ошибке, зафиксированной в Инциденте, и/или к ошибке воспроизведения, а также тестирование внесенных изменений в рамках ЗНИ. 7. Обеспечение мониторинга и проведение анализа процесса обработки поступающих в техническую поддержку обращений (заявок). Техническая поддержка реализуется путем проведения ответственными сотрудниками соответствующей информационно-консультационной деятельности в соответствии с определенными ролями, а также выполнения Исполнителем конкретных действий по своевременному выявлению причин сбоев и аварийных ситуаций и их устранению, а также по адаптации, конфигурированию, корректировке Системы, включая выполнение процедур тестирования и участия в обновлениях Системы. Все роли подразделяются на уровни поддержки, взаимодействующие между собой в соответствии с блок-схемой процесса технической поддержки. Общая схема процесса рассмотрения обращений (заявок) в соответствии с видами технической поддержки представлена на рисунке 1. . Рисунок 1 - Общая схема процесса рассмотрения обращений (заявок) в соответствии с видами технической поддержки - 2.3 Каналы связи Должна быть предусмотрена омниканальность в части приема обращений (заявок). Получение обращений (заявок) технической поддержкой происходит по следующим каналам связи: – СРО; – электронная почта; – телефонная линия. Исполнитель обеспечивает прием обращений (заявок) от Заказчика и предоставляет информацию в рамках оказания услуг по техническому сопровождению Системы, руководствуясь матрицей взаимодействия, приведенной в Приложении 1 к настоящему Регламенту - 3 Порядок оказания Услуг 3.1 Типы обращений (заявок) Обращения и заявки Заказчика классифицируются в соответствии с приоритетами и регламентными сроками, указанными в Приложении 2 к настоящему Регламенту. Регистрация обращений и заявок предусматривает создание новой записи в СРО с присвоением поступившему обращению или заявке (новой записи) уникального идентификатора. Запись в СРО должна содержать вопрос или проблему, которую требуется решить или оказать консультацию. Если обращение или заявка автоматически зарегистрированы в СРО при отправке представителем Заказчика, Исполнитель проверяет корректность указанного типа обращения (заявки) и может обратиться к Заказчику с просьбой корректировки, предоставив обоснования в соответствии с настоящей классификацией (Таблица 1) - Таблица 1 - Типы обращений (заявок) Тип обращения (заявки) Описание Запрос на обслуживание Подготовка SQL запроса к СУБД для решения прикладной задачи и д р. – запрос на любое действие, не являющееся запросом информации и несовершенный на основе происшествия, прямо или косвенно влияющего на работу Системы Консультация (входит в тип обращения (заявки) «Запрос на обслуживание») «Где взять / куда обратиться...?», «Как сделать / выполнить…», «Как это работает…?» - запрос, имеющий своей целью получение информационной поддержки Инцидент Разбор ошибок/сбоев и подготовка материалов (корректировочных релизов, инструкций) для Заказчика для устранения ошибок/сбоев, которые приводят к частичному и полному нарушению работоспособности всех или отдельных функций ППО. Подготовка изменения и материалов, необходимых для проведения аварийно-восстановительных работ для возобновления работоспособности Системы. ЗНИ Подготовка изменений, связанных с изменением, улучшением/оптимизацией Системы и выводом новой модифицированной функциональности в штатном режиме. Подготовка изменений, связанных с модификацией существующих и/или реализация новых интеграционных механизмов для получения/обработки данных внешних систем. Подготовка изменений графического интерфейса по требованиям Заказчика - 3.2 Участники технической поддержки, осуществляющие сопровождение обращений (заявок) Техническая поддержка Системы должна быть организована на трех уровнях: 1. Первый и второй уровни технической поддержки организуется Заказчиком. 2. Третий уровень технической поддержки организуется Исполнителем. Зона ответственности каждого уровня технической поддержки указана в Таблице 2. Таблица 2 - Зона ответственности каждого уровня технической поддержки Участники технической поддержки Описание - Первый уровень технической поддержки (далее – 1-й уровень) Группа ответственных сотрудников 1-го уровня Заказчика, осуществляющая прием и первичную обработку обращений (заявок) (описание предмета обращения, первичная классификация и приоритизация, определение назначения, маршрутизация обращений (заявок) по назначению), руководствуется в своей работе настоящим Регламентом и БЗ, наполняемой 2-м уровнем поддержки, самостоятельно решает часть обращений (заявок), связанных с недостаточной квалификацией пользователей или настройками в рамках своей компетенции. В случае невозможности решения обращений (заявок) на 1-ом уровне ответственный сотрудник передает ее на 2-й уровень - Второй уровень технической поддержки (далее – 2-й уровень) Группа ответственных сотрудников 2-го уровня Заказчика по установленным компетенциям (информационная безопасность, сопровождение и эксплуатация информационно-аналитических систем, развитие информационно-аналитических систем, техническая поддержка информационно-аналитических систем) отвечает за поддержание работоспособности Системы, обработку обращений (заявок) и их решение в регламентные сроки в соответствии с установленными приоритетами. Осуществляет информационно-консультационную поддержку пользователей Системы в рамках своей компетенции. Оказывает экспертную помощь ответственным сотрудникам 1-го уровня в части формирования БЗ, содержащей ответы на часто задаваемые вопросы пользователей, с целью передачи знаний, навыков и инструментария на 1-й уровень для ускорения решения обращений (заявок). В случае невозможности решения обращения (заявки) на 2-ом уровне ответственный сотрудник передает его на 3-й уровень. При выявлении необходимости изменений в ППО Системы инициирует формирование обращения (заявки) и направляет его на группу ответственных сотрудников 3-го уровня по соответствующему классификатору (ЗНО, ЗНИ, и т.д.) - Третий уровень технической поддержки (далее – 3-й уровень) Группа ответственных сотрудников Исполнителя, отвечающая за устранение сбоев и аварий, проведение информационно-консультационной поддержки пользователей Системы, проведение адаптации и конфигурирования Системы в объемах действующих контрактов на оказание технической поддержки - 3.3 Перечень и описание статусов обращений (заявок) В Таблице 3 приведен перечень статусов обращений (заявок), действующий в СРО, и их описание. Таблица 3 - Перечень статусов обращений (заявок) и их описание Статус Описание Зарегистрирован Обращение (заявка) принято и зарегистрировано Направлен в группу Присваивается при назначении ответственными сотрудниками 1-го уровня группе ответственных сотрудников 2-го уровня по тематике обращения (заявки) после заполнения всей необходимой информации и полей обращения (заявки), а также при его передаче между группами 2-го уровня Передан в группу Присваивается при передаче обращения (заявки) ответственными сотрудниками 2-го уровня на группу ответственных сотрудников 3-го уровня Назначен Присваивается при назначении обращения (заявки) на ответственного сотрудника для его решения в рамках компетенции В работе Присваивается при приеме обращения (заявки) в работу ответственным сотрудником для его решения Решен Присваивается ответственным сотрудником, выполнившим работы по обращению (заявке) Закрыт Присваивается автоматически при решении запроса по обращению (заявке), а также отсутствии дополнительных запросов пользователя в соответствии с действующим SLA, или при подтверждении решения обращения (заявки) со стороны пользователя Запрос доп. информации Присваивается при необходимости запроса дополнительной информации и/или уточнения предмета обращения по обращению (заявке) у пользователя Ответ предоставлен Присваивается после ответа пользователем на запрос дополнительной информации Отклонен Присваивается, если обращение (заявка) не актуальна (по информации от пользователя), отсутствует техническая возможность решения обращения (заявки), предмет обращения не входит в компетенции технической поддержки, или существует влияние доработки на другие компоненты, что нарушает общий порядок работы Системы - Согласование Присваивается при необходимости согласования направления обращения (заявки) ответственным сотрудником Заказчика на 3-й уровень Анализ Присваивается при проведении анализа на предмет возможности внесения изменений, связанных с развитием/улучшением/оптимизацией Системы и выводом новой функциональности и оценке ресурсоемкости Тестирование Присваивается Исполнителем при завершении разработки и проведенном предварительном тестировании для последующего осуществления приемочного тестирования Специалистом 2-го уровня Релиз Присваивается ответственным сотрудником Заказчика при принятии решения о возможности вывода доработки в продуктивную среду Утверждение заказчиком Присваивается при согласовании группой профильных специалистов на 2-м уровне поддержки с пользователем технического задания для внесения изменений, связанных с развитием/улучшением/оптимизацией Системы и выводом новой функциональности Доработка Присваивается в случае несогласования Заказчиком работ, проведенных Исполнителем в рамках контрактных обязательств, по внесению изменений, связанных с развитием/улучшением/оптимизацией Системы и выводом новой функциональности в штатном режиме, и необходимости последующего направления Исполнителю для ее доработки Отложен Присваивается в случае невозможности выполнения запроса, изложенного в обращении (заявке), в связи с необходимостью запроса дополнительной информации у третьих сторон - 3.4 Порядок регистрации и сопровождения Заявок Порядок регистрации и сопровождения обращений (заявок) в рамках оказываемых услуг по технической поддержке Системы зависит от типа обращения (заявки): 1. Услуга по решению инцидентов, связанных с работой ППО – тип обращения (заявки) «Инцидент». 2. Услуга по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности – тип обращения (заявки) «Инцидент». 3. Услуга информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы – тип обращения (заявки) «Запрос на обслуживание» (в том числе, консультационный запрос). 4. Услуга адаптационного, конфигурационного и коррекционного сопровождения Системы (в рамках действующих программных модулей и функциональностей) – тип обращения (заявки) «Запрос на изменение». В случае недоступности СРО взаимодействие и информирование Исполнителем о ходе оказания услуги по обращению (заявке), изменению статусов обращений (заявок) осуществляется по согласованию с Заказчиком в соответствии с матрицей взаимодействия, представленной в Приложении 1 к настоящему Регламенту. - 3.4.1 Инцидент На рисунке 2 представлена функциональная схема регистрации и сопровождения обращений (заявок) типа «Инцидент». Рисунок 2 - Функциональная схема регистрации и сопровождения обращений (заявок) типа «Инцидент» 3.4.2 Запрос на обслуживание На рисунке 3 представлена функциональная схема регистрации и сопровождения обращения (заявки) типа «ЗНО». Рисунок 3 - Функциональная схема регистрации и сопровождения обращения (заявки) типа «ЗНО» 3.4.3 Запрос на изменение На рисунке 4 представлена функциональная схема регистрации и сопровождения обращений (заявок) типа «ЗНИ». Рисунок 4 - Функциональная схема регистрации и сопровождения обращений (заявок) типа «ЗНИ» - 3.5 Порядок классификации и приоритизации обращений (заявок) Классификация является начальной стадией процесса оказания технической поддержки, необходимой для идентификации обращения (заявки) и определения соответствующих действий для его обработки. Для проведения первичной классификации необходимо получить от пользователя и зафиксировать в описании обращения (заявки) подробные сведения о сути запроса, в том числе, для Инцидентов зафиксировать сценарий воспроизведения обнаруженной ошибки. Для проведения вторичной классификации необходимо провести анализ и диагностику для определения корневой причины и затронутой Инцидентом функциональной области (инфраструктура, сеть, ППО). В процессе классификации осуществляется первичная диагностика и оценка проблемы, описанной пользователем Системы в обращении (заявке), в части функционирования и/или удобства использования Системы. Корректная классификация позволяет увеличить скорость обработки обращения (заявки) и решения описанной в обращении (заявке) проблемы при минимальном привлечении ресурсов, в частности, за счет использования известных решений для типовых обращений (заявок), которые должны описываться в БЗ СРО. Классификация позволяет произвести первоначальное назначение обращения (заявки) на ответственного сотрудника и выставить приоритет с учетом приоритизации. Приоритизация применяется для определения критичности описанной в обращении (заявке) проблемы для функционирования ППО Системы. Приоритет рассмотрения обращения (заявки) определяется в процессе ее классификации на основании ряда параметров, вводимых при заполнении обращения (заявки). Приоритизация используется для того, чтобы при одновременном наличии нескольких обращений (заявок) в первую очередь рассматривалась обращения (заявки) с наивысшим приоритетом и не позднее установленных для данного приоритета сроков - Изменение приоритета уже зарегистрированного обращения (заявки) используется в случае появления новых обстоятельств, которые ведут к изменению влияния и/или срочности существующего обращения (заявки). При регистрации обращения (заявки) необходимо провести его приоритизацию. В процессе управления обращениями (заявками) каждому обращению (заявке) присваивается приоритет, принимающий одно из значений: Низкий, Средний, Высокий или Критический. В соответствии с приоритетом определяется время, очередность устранения, , ресурсы, привлекаемые для работ по обращению (заявке), а также может определяться порядок/процедура действий при работе с обращением (заявкой). Заказчиком в зависимости от уровня сбоя в работе Системы обращению (заявке) присваивается приоритет с указанием максимального времени реакции и решения в соответствии с требованиями, указанными в Приложении 2 к настоящему Регламенту - 4 Формы обращений (заявок) на оказание услуг по технической поддержке Системы, заполняемые в СРО 4.1. Форма обращения (заявки) на оказание услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы При подаче обращения (заявки) типа «ЗНО» в СРО указывается (Таблица 5): Таблица 5 – Описание атрибутов формы обращения (заявки) на оказание услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 5) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 5) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 5) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 5) Категория обращения: информационно-консультационная поддержка Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 5) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 5) Текст запроса на оказание услуги по информационно-консультационной поддержке сотрудников Заказчика Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 5) - На рисунке 5 приведена форма обращения (заявки) типа «ЗНО» в СРО. Рисунок 5 - Форма обращения (заявки) типа «ЗНО» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы, заполненную в свободной форме. - 4.2. Форма обращения (заявки) на оказание услуги по решению инцидентов, связанных с работой ППО При подаче обращения (заявки) типа «Инцидент» в СРО указывается (Таблица 6): Таблица 6 – Описание атрибутов формы обращения (заявки) на оказание услуги по решению инцидентов, связанных с работой ППО Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 6) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 6) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 6,) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 6) Категория обращения (заявки): инцидент Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 6) Приоритет изменения Время - одно из значений: Низкий, Средний, Высокий или Критический. Определяет, очередность решения обращения (заявки), ресурсы, привлекаемые для решения обращения (заявки), порядок/процедура действий при решении обращения (заявки) – поле СРО «Приоритет» (см. рисунок 6,) - Тип изменения Справочник, классифицирующий типовые запросы характерные для Системы – поле СРО «Предмет обращения» (см. рисунок 6) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 6) Полное описание инцидента, включая скриншоты и описание шагов, приведших к неисправности Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 6) Однократность/неоднократность Круг пользователей или компьютеров, затронутых данным инцидентом Действия, предпринятые для самостоятельного решения инцидента (при наличии) Версии используемого программного обеспечения на клиентской рабочей станции, где воспроизводится ошибка (операционная система, прикладное программное обеспечение) Дополнительная информация - На рисунке 6 приведена форма обращения (заявки) типа «Инцидент» в СРО. Рисунок 6 - Форма обращения (заявки) типа «Инцидент» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуги по решению инцидентов, связанных с работой ППО, заполненную в свободной форме - 4.3. Форма обращения (заявки) на оказание услуг по адаптационному конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) При подаче обращения (заявки) типа «ЗНИ» в СРО указывается (Таблица 7): Таблица 7 – Описание атрибутов формы обращения (заявки) на оказание услуг по адаптационному, конфигурационному и коррекционному сопровождению Системы Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 10) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 9) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 10) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 10) Категория обращения (заявки): запрос на изменение Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 7) Приоритет изменения Время, очередность решения обращения (заявки), ресурсы, привлекаемые для решения обращения (заявки), порядок/процедура действий при решении обращения (заявки) – поле СРО «Приоритет» (см. рисунок 7) Тип изменения Справочник, классифицирующий типовые запросы характерные для Системы – поле СРО «Предмет обращения» (см. рисунок 7) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 7) Текст запроса на оказание услуги по адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 7) - На рисунке 7 приведена форма обращения (заявки) типа «ЗНИ» в СРО. Рисунок 7 - Форма обращения (заявки) типа «ЗНИ» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуг по адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей), заполненную в свободной форме - 4.4. Форма обращения (заявки) на оказание услуги по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности При подаче обращения (заявки) типа «Инцидент» в СРО указывается (Таблица 8): Таблица 8 – Описание атрибутов формы обращения (заявки) на оказание услуг по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности - Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 8) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 8) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 8) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 8) Категория обращения (заявки): инцидент Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 8) Приоритет Время, очередность решения обращения (заявки), ресурсы, привлекаемые для решения обращения (заявки), порядок/процедура действий при решении обращения (заявки) – поле СРО «Приоритет» (см. рисунок 8) Тип изменения Справочник, классифицирующий типовые запросы характерные для Системы – поле СРО «Предмет обращения» (см. рисунок 8) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 8) Текст запроса на оказание услуги по обновлению или удалению уязвимых компонентов (библиотек) ППО в соответствии с требованиями к обеспечению информационной безопасности Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 8) - На рисунке 8 приведена форма обращения (заявки) типа «Инцидент» в СРО. Рисунок 8 - Форма обращения (заявки) типа «Инцидент» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуги по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности, заполненную в свободной форме - Приложение 1 к Регламенту Матрица ответственных за взаимодействия в рамках выполнения работ по техническому сопровождению Системы Таблица 1 – Ответственные за взаимодействия в рамках выполнения работ по техническому сопровождению Системы со стороны Исполнителя ФИО Должность Адрес электронной почты Телефон — — — Общий контакт - Приложение 2 к Регламенту Приоритеты и регламентные сроки решения обращений (заявок) Приоритеты и регламентные сроки решения обращений (заявок) приведены в таблице 1. Таблица 1 – Приоритеты и регламентные сроки решения обращений (заявок) № п/п Приоритет Максимальное время реагирования Время решения (срок выполнения) Описание приоритета - По информационно-консультационной поддержке сотрудников Заказчика и пользователей Системы 1 – не более 1 часа не более 10 часов – - По решению инцидентов, связанных с работой ППО 1 Критический не более 30 минут не более 4 часов – полная недоступность ППО; – недоступность ключевых функций; – ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО; – невозможность информационного обмена с ППО для ИС более 4 часов 2 Высокий не более 1 часа не более 8 часов – ошибки/сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; – снижение быстродействия СПО (время отклика ППО на операции превышает 30 секунд); – невозможность управления правами и ролями пользователей 3 Средний не более 4 часов не более 24 часов – невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым недоступность функции формирования отчетов 4 Низкий не более 8 часов не более 40 часов – отклонение в работе ППО, не влияющее на корректную работу функций; – другие сбои и ошибки, затрагивающие основные функции ППО - По адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) 1 Критический не более 40 минут не более 8 часов – изменения необходимые при проведении аварийно-восстановительных работ для возобновления работоспособности Системы; – изменения, связанные с критичными ошибками, блокирующими возможность оказания государственных услуг и/или чтение и внесение данных в Систему 2 Высокий не более 1 часа не более 40 часов – изменения относящиеся к обеспечению работоспособности основной функциональности Системы, устраняют выявленные дефекты в работе Системы, оказывающие существенное влияние на процесс оказания государственных услуг и работу пользователей в Системе; – изменения, затрагивающие три и более подсистемы/модуля Системы для адаптации 3 Средний не более 4 часов не более 72 часов – изменения, связанные с развитием/улучшением/оптимизацией Системы и выводом новой функциональности в штатном режиме для одного-двух модулей/подсистем; – изменения, связанные с развитием интеграционных механизмов Системы, например, обновление существующих и/или реализация новых видов сведений СМЭВ, обновление существующих и/или реализация новых API, адаптация и/или изменение механизмов импорта и экспорта данных Системы и т.д. 4 Низкий не более 8 часов не более 160 часов – изменения, связанные с ошибками/ корректировкой/изменение в отображении информации в пользовательском графическом интерфейсе Системы (графика, текст, органы управления, элементы интерфейса) - По устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности 1 Критический не более 30 минут не более 24 часов – критические уязвимости, влияющие на возможную полную недоступность ППО, ключевых функций Системы, ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО без возможности восстановления работоспособности Системы; – Критический уровень CVSS > 8.0 2 Высокий не более 1 часа не более 84 часов – критические уязвимости, влияющие на ошибки и сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; – Высокий уровень CVSS 5.0 - 8.0 3 Средний не более 4 часов не более 120 часов – уязвимости, влияющие на невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым; – Средний уровень CVSS 2.0 - 4.9 4 Низкий не более 8 часов не более 160 часов – уязвимости, влияющие на отклонение в работе ППО, не влияющее на корректную работу функций; – другие сбои и ошибки, затрагивающие основные функции ППО; – Низкий уровень CVSS < 2.0 - Приложение Г Форма Отчета об оказанных услугах Отчет об оказанных услугах за этап «наименование этапа» в период с «__» _________ по «__» _________. № п/п Наименование услуги Общее количество Номер ОРС Краткое Описание Время реагирования по ТЗ Время реагирования фактическое Время решения по ТЗ Время решения фактическое Результат соблюдения времени реагирования Результат соблюдения времени решения Примечание 1 Услуги по информационно-консультационной поддержке работников Заказчика 2 546782 Консультация по работе Модуля СЦ 1 2 10 часов 11 часов Нет Нет 567123 Консультация по схеме БД 1 1 10 часов 1 час Да Да 2 … … Заказчик Подрядчик /Должность/ /Должность/ ____________________ /Ф.И.О/ ___________________ /Ф.И.О/ М.П. М.П. «_____»_______________________202_г. «_____»_______________________202_г - Приложение 1 к Отчету об оказанных услугах Журнал обращений (заявок) на оказание услуги по информационно-консультационной поддержке пользователей Системы (шаблон) Наименование Исполнителя в этапе «наименование этапа» в период с ________________ по _______________ оказал(о) Услугу по поддержке пользователей Системы в объеме, указанном в Таблице 1 Таблица 1 - Журнал обращений (заявок) пользователей Системы № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. ИТОГО зарегистрировано: Всего обращений (заявок): ________ ИТОГО решено: Всего обращений (заявок): ________ - Приложение 2 к Отчету об оказанных услугах Журнал обращений (заявок) по решению инцидентов, связанных с работой ППО (шаблон) Наименование Исполнителя в этапе «наименование этапа» в период с ________________ по _______________ оказал(о) Услугу по решению инцидентов в объеме, указанном в Таблице 1. Таблица 1 - Журнал по решению инцидентов № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. ИТОГО зарегистрировано: Всего инцидентов: ________ ИТОГО решено: Всего инцидентов: ________ - Приложение 3 к Отчету об оказанных услугах Журнал обращений (заявок) выполнения адаптационного, конфигурационного и коррекционного сопровождения Системы (шаблон) Журнал выполнения адаптации, конфигурации и коррекции Системы сформирован за этап «наименование этапа» в период с «__» _________ по «__» ____________ и представлен в таблице ниже (Таблица 1). Таблица 1 - Журнал выполнения адаптации, конфигурации и коррекции сопровождения Системы № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. Количество выполненных заявок за этап: ________ - Приложение 4 к Отчету об оказанных услугах Журнал обращений (заявок) по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности (шаблон) Журнал обращений (заявок) по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности сформирован за этап «наименование этапа» в период с «__» _________ по «__» ____________ и представлен в таблице ниже (Таблица 1). Таблица 1 - Журнал выполнения заявок по устранению уязвимостей в ППО № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. Количество выполненных заявок за этап: ________ - Приложение Д Форма Протокола проверки результатов организационно-штатных и подготовительных мероприятий (шаблон) Протокол проверки результатов организационно-штатных и подготовительных мероприятий Настоящий Протокол содержит результаты проверки организационно-штатных и подготовительных мероприятий, проведенных Исполнителем (Таблица Д.1). Таблица Д.1. Протокол проверки результатов № Мероприятия Подготовительного этапа Результат проверки 1. Определить и направить Заказчику документ «Ответственные за взаимодействия в рамках выполнения работ по техническому сопровождению Системы со стороны Исполнителя». Документ содержит контактную информацию (ФИО, должность, адрес электронной рабочей почты, номер телефона) не менее чем о 2 лицах, ответственных за оказание услуг со стороны Подрядчика Выполнено/Не выполнено 2. Обеспечить подключение специалистов Подрядчика к Системе Выполнено/Не выполнено 3. Обеспечить подключение специалистов Подрядчика к СРО Выполнено/Не выполнено Заказчик Подрядчик /Должность/ /Должность/ ____________________ /Ф.И.О/ ___________________ /Ф.И.О/ М.П. М.П. «_____»_______________________202_г. «_____»_______________________202_г

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

ОПРЕДЕЛЕНИЯ, ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ - Автоматизированная система (АС) Система, состоящая из комплекса средств автоматизации, реализующего информационную технологию выполнения установленных функций, и персонала, обеспечивающего его функционирование (ГОСТ Р 59853-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения») АРМ Автоматизированное рабочее место АСУ ТК, Система Информационно-аналитическая система регулирования на транспорте АТС Автоматическая телефонная станция БД База данных ГИС Государственная информационная система ГОСТ Государственный стандарт ГЦОД СИЦ Минтранса России, ГЦОД Головной центр обработки данных ФГБУ «СИЦ Минтранса России» Дашборд Интерактивная аналитическая панель, графический интерфейс. ЕИС Единая информационная система в сфере закупок ЕСИА Единая система идентификации и аутентификации Заказчик Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» КИИ Критическая информационная инфраструктура Кластер Кла?стер (англ. cluster) – объединение нескольких однородных элементов, которое может рассматриваться как самостоятельная единица, обладающая определёнными свойствами Компонент Часть АС, выделенная по определенному признаку или совокупности признаков и рассматриваемая как единое целое (ГОСТ Р 59853-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения») Контракт Контракт на выполнение работ по развитию и оказанию услуг по технической поддержке Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК в 2026 году, заключаемый по результатам проведения конкурентной процедуры закупки в соответствии с требованиями Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» - - Значение характеристики не может изменяться участником закупки

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

ФГБУ «СИЦ Минтранса России» Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации», Заказчик Федеральный закон № 44-ФЗ Федеральный закон от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» ФЗ Функциональная задача ФЗ «Реестр объектов» Функциональная задача «Формирование и ведение единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации» ФСБ России Федеральная служба безопасности Российской Федерации ФСТЭК России Федеральная служба по техническому и экспортному контролю ЧС Чрезвычайная ситуация ЭВМ Электронно-вычислительная машина API От англ. Application Programming Interface – интерфейс прикладного программирования – совокупность инструментов и функций в виде интерфейса для взаимодействия с программой CSS От англ. Cascading Style Sheets — каскадные таблицы стилей FPS От англ. frame per second - количество кадров в секунду HTML От англ. HyperText Markup Language - стандартный язык разметки документов, создающий основу и структуру всех веб-страниц JSON От англ. JavaScript Object Notation – текстовый формат обмена данными, основанный на JavaScript WebAssembly (Wasm) Открытый стандарт, представляющий собой низкоуровневый бинарный формат инструкций, который позволяет выполнять код, написанный на языках C++, Rust или Go, в браузерах с производительностью, близкой к нативной

1. ОБЩИЕ СВЕДЕНИЯ - 1.1. Наименование Системы Полное наименование системы: Информационно-аналитическая система регулирования на транспорте. Условное обозначение системы: АСУ ТК. Полное наименование модуля: Модуль сбора, ведения и анализа информации о нештатных ситуациях на транспорте. Условное обозначение модуля: Модуль СЦ. Модуль СЦ создан в рамках контракта от 05.08.2024 № ОК/24_04 на выполнение работ по развитию АСУ ТК в части создания модуля «Сбора, ведения и анализа информации о нештатных ситуациях на транспорте». Развитие Модуля СЦ осуществлено в рамках контракта от 19.05.2025 № ОК/25_09 на выполнение работ по развитию Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК - - Значение характеристики не может изменяться участником закупки

1.2. Шифр темы или номер контракта Присваивается Заказчиком по результатам организации закупочных процедур. 1.2.1. Предмет контракта Выполнение работ по развитию Модуля СЦ. Код по ОКПД2: 62.01.11.000 – услуги по проектированию и разработке информационных технологий для прикладных задач и тестированию программного обеспечения. Оказание услуг по технической поддержке Модуля СЦ. Код по ОКПД2: 62.02.30.000 – услуги по технической поддержке информационных технологий. Выполнение работ по развитию Модуля СЦ предусмотрено с учетом ключевых результатов (ОКР) Ведомственной программы цифровой трансформации Минтранса России на 2026-2028 (далее - ВПЦТ Минтранса России) в составе мероприятия № 103.002 «АСУ ТК» ИТ расхода 103.26.000005 «Развитие Информационно-аналитической системы регулирования на транспорте (АСУ ТК)»: · «Обеспечено информационное взаимодействие с Минобороны о происшествиях на транспортных объектах»; · «Обеспечена автоматизация формирования отчетов о нештатных ситуациях на транспорте, в том числе по данным внешних систем». Выполнение работ по технической поддержке АСУ ТК предусмотрено ВПЦТ Минтранса России в составе мероприятия № 103.002 «АСУ ТК» ИТ расхода 103.26.000021 «Эксплуатация Информационно-аналитической системы регулирования на транспорте (АСУ ТК)»

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

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

1.5. Основания для выполнения работ Работы осуществляются на основании следующих документов: – постановление Правительства Российской Федерации от 30.12.2003 № 794 «О единой государственной системе предупреждения и ликвидации чрезвычайных ситуаций»; – постановление Правительства Российской Федерации от 08.11.2013 № 1007 «О силах и средствах единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций»; – распоряжение Правительства Российской Федерации от 27.11.2021 № 3363-р «О Транспортной стратегии Российской Федерации до 2030 года с прогнозом на период до 2035 года»; – Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 26.08.2025 №ЕФ-3; – Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 27.11.2025 №ЕФ-23;

– Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 19.02.2026 №ЕФ-1; – План мероприятий по профилактике случаев непроизводственного травматизма граждан на железнодорожном транспорте, являющийся приложением к постановлению коллегии Министерства транспорта Российской Федерации от 11.03.2026 № 2

1.6. Перечень документов, требования которых должны быть учтены при выполнении работ – Федеральный закон Российской Федерации от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации»; – Федеральный закон Российской Федерации от 27.07.2006 № 152-ФЗ «О персональных данных»; – Федеральный закон Российской Федерации от 06.04.2011 № 63-ФЗ «Об электронной подписи»; – Федеральный закон Российской Федерации от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации»; – Указ Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации»; – Указ Президента Российской Федерации от 01.05.2022 № 250 «О дополнительных мерах по обеспечению информационной безопасности Российской Федерации»; – Указ Президента Российской Федерации от 31.03.2010 № 403 «О создании комплексной системы обеспечения безопасности населения на транспорте»; – постановление Правительства Российской Федерации от 30.07.2004 № 395 «Об утверждении Положения о Министерстве транспорта Российской Федерации»; – постановление Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации»; – постановление Правительства Российской Федерации от 16.11.2015 № 1236 «Об установлении запрета на допуск программного обеспечения, происходящего из иностранных государств, для целей осуществления закупок для обеспечения государственных и муниципальных нужд»; – постановление Правительства Российской Федерации от 23.12.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 Федерального закона «Об электронной подписи»;

– постановление Правительства Российской Федерации от 08.06.2011 № 451 «Об инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг и исполнения государственных и муниципальных функций в электронной форме»; – постановление Правительства Российской Федерации от 30.01.2013 № 62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин»; – приказ ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации»; – приказ ФСТЭК России от 11.04.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений»; – приказ ФСБ России от 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.7. Сроки начала и окончания работ Начало работ: с даты заключения Контракта. Окончание работ: не позднее 15.12.2026. Работы выполняются в соответствии с этапами. Сроки выполнения этапов работ по развитию и технической поддержке Модуля СЦ определяются Календарным планом. Календарный план, приведен в разделе 5 настоящего ТЗ

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

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

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

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

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

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

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

3. ХАРАКТЕРИСТИКА ОБЪЕКТА АВТОМАТИЗАЦИИ - 3.1. Описание объекта автоматизации АСУ ТК Объектом автоматизации являются процессы основной и обеспечивающей деятельности, направленные на управление транспортным комплексом, в том числе, процессы информационного взаимодействия с другими организациями и субъектами транспортного комплекса. АСУ ТК относится к государственным информационным системам, а также к информационным системам персональных данных и значимым объектам критической информационной инфраструктуры Российской Федерации. АСУ ТК соответствует требованиям, предъявляемым к: – ГИС второго класса защищенности в соответствии с приказом ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах»; – ИС персональных данных при обеспечении третьего уровня защищенности персональных данных в соответствии с требованиями постановления Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»; – значимым объектам КИИ Российской Федерации второй категории значимости с постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении Правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений». Модуль СЦ является подсистемой АСУ ТК. Перечень платформенных решений и функциональных задач АСУ ТК представлен в Таблице 1 - - Значение характеристики не может изменяться участником закупки

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

8 Подсистема проектного архива АСУ ТК Подсистема проектного архива АСУ ТК предназначена для автоматизации деловых процессов должностных лиц Министерства транспорта Российской Федерации, подведомственных агентств и службы, в том числе, и процессов информационного взаимодействия внутреннего и внешнего характера 9 ФЗ «Реестр объектов» Функциональная задача предназначена для формирования и ведения единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации 10 ФЗ «СТП» Функциональная задача предназначена для организации информационно-аналитической поддержки процессов территориального планирования Российской Федерации в области федерального транспорта 11 ФЗ «МРТБ ПП» Функциональная задача предназначена для формирования и ведения межрегионального транспортного баланса пассажирских перевозок в дальнем (межрегиональном) сообщении 12 ФЗ «МДД» Функциональная задача предназначена для осуществления мониторинга дорожного движения 13 ФЗ «ТПР» Функциональная задача предназначена для формирования и ведения транспортного паспорта региона 14 ФЗ «Данные по грузообороту» Функциональная задача предназначена для обеспечения подсистем и пользователей АСУ ТК данными по грузообороту между Российской Федерацией и зарубежными странами 15 ФЗ «МЖТ» Функциональная задача предназначена для осуществления мониторинга железнодорожного транспорта 16 ФЗ «МГМП» Функциональная задача предназначена для осуществления мониторинга грузопотоков в морских портах с целью формирования единой цифровой среды мониторинга и планирования перевозок в/из портов Дальнего Востока

17 Модуль ГЭТ Модуль предназначен для получения, хранения данных инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по отдельно взятому предприятию-перевозчику. Формирования отчетов об инвентаризации с детальными данными по каждому разделу инвентаризации с маршрутизацией в муниципалитет / регион / Минтранс. Содержит агрегированные данные инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по всем перевозчикам, относящихся к данному муниципалитету. Формирует сводный отчет по муниципалитету по каждому разделу инвентаризации с маршрутизацией в регион / Минтранс. Формирует агрегированные данные инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по всем перевозчикам, относящиеся к данному региону и по всем муниципалитетам, относящимся к данному региону. Аналитические и статистические данные о состоянии ГЭТ региона. Содержит данные о видах транспорта, цифровых транспортных сервисах и платежных инструментах Региона. Формирует сводный отчет по каждому разделу инвентаризации с маршрутизацией в Минтранс. Формирует агрегированную статистику и аналитику по всем регионам страны в разрезе транспортных средств, маршрутов, пассажиропотоков, инфраструктуры ГЭТ. Данные о рейтинге регионов и перевозчиков на основании выбранных параметров, документооборот с участниками Системы: получение подписанных печатных форм, их утверждение, возврат на доработку. 18 Модуль iМинтранс Модуль создан для отчета по ключевым показателям транспортного комплекса России (Отраслевые и статистические показатели, исполнение бюджета, исполнение поручений, аналитика СМИ, происшествия по видам транспорта). 19 Модуль СЦ Модуль СЦ предназначен для оперативного мониторинга нештатных ситуаций транспортной отрасли, оповещения заинтересованных лиц и структур и предоставления данных о нештатных ситуациях

АСУ ТК осуществляет идентификацию и авторизацию посредством Единой системы идентификации и аутентификации (ЕСИА). Информационный обмен с внешними информационными системами осуществляется посредством СМЭВ 3 и СМЭВ 4. АСУ ТК развернута на вычислительных мощностях ГЦОД СИЦ Минтранса России

3.2. Описание и текущее состояние объекта автоматизации Модуля СЦ Объектом автоматизации является процесс организации мониторинга информации о НС и ЧС на транспорте. Предметом деятельности Учреждения являются следующие функции: – информационное обеспечение в области транспортной безопасности, защиты населения и территорий от чрезвычайных ситуаций природного и техногенного характера в транспортном комплексе; – подготовка справочных материалов при угрозе возникновения и возникновении чрезвычайных ситуаций и иных происшествий в транспортном комплексе; – взаимодействие и обмен оперативной информацией с органами управления Единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций; – организация оперативного мониторинга обстановки на объектах транспорта при угрозе и возникновении чрезвычайных ситуаций и иных происшествий. Перечень компонентов Модуля СЦ и выполняемые ими функции представлены в Таблице 2

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

3 Информирование – ведение справочника способов оповещения (веб-интерфейс, мессенджер); – формирование сценария выполнения оповещения (настройка условий, способа, параметров оповещения); – выполнение оповещений пользователей 4 Отчетность – формирование отчета и справки о событиях; – фильтрация событий для выгрузки в справку о событиях или в отчет о событиях 5 Администрирование – ведение ролей пользователей; – ведение учетных данных пользователей; – ведение справочника организаций; – ведение справочника групп системы мгновенного обмена сообщениями; – выполнение исходящего звонка на контактный телефонный номер организации; – формирование матрицы эскалации событий Архитектура Модуля СЦ представлена на рисунке 1. Рисунок 1. Архитектура Модуля СЦ

3.3. Состав используемого ПО Модуля СЦ Программная архитектура Модуля СЦ разработана как трехуровневая клиент-серверная архитектура. Архитектура включает в себя следующие уровни: • уровень представления – презентационный уровень, обеспечивающий взаимодействие с пользователя с клиентскими приложениями с использованием веб-браузера («тонкий» клиент); • уровень приложений – реализован в виде сервисов, обеспечивает обработку запросов, поступающих от клиентских приложений, формирование ответов на запрос в доступном пользователю виде (формирование пользовательских интерфейсов); • уровень хранения данных – реализуется как сервер БД и обеспечивает хранение и целостность хранимых данных, создание резервных копий, ведение журнала транзакций, восстановление данных после сбоев. Программная архитектура Модуля СЦ включает в себя сервисы и интерфейсы, указанные в Таблице 3. Таблица 3. Программная архитектура Модуля СЦ Программный сервис/интерфейс Технологии реализации Уровень представления Интерфейс пользователя и администратора (front-end) Javascript Уровень приложений Сервис (GateWay) Kotlin Сервис геокодирования (geocoding-service) Kotlin Сервис уведомлений (notifiсation-service) Kotlin Сервис работы с файлами (file-service) Kotlin Сервис отчетности (report-service) Kotlin Сервис управления событиями (event-service) Kotlin Сервис информирования через мессенджер (messenger-notifier) Python Сервис внешних интеграций (integration-service) Сбор информации из внешних систем и сервисов Брокер сообщений Kafka Уровень хранения данных Файловое хранилище MinIO S3 СУБД Postgres Pro Enterprise

3.4. Информационное взаимодействие программных сервисов и интерфейсов Модуля СЦ Объект автоматизации функционирует в распределенной информационной среде. Обмен данными осуществляется по защищенным каналам связи (в том числе ведомственным сетям передачи данных). Источники информации включают: · внешние автоматизированные системы (органов государственной власти); · внутренние базы данных (реестры объектов транспортной инфраструктуры, паспорта регионов и пр.); · оперативная информация от персонала, поступающая через автоматизированные рабочие места (АРМ) и мобильные устройства. 3.4.1. Взаимодействие Модуля СЦ со смежными подсистемами АСУ ТК Модуль СЦ входит в состав АСУ ТК и взаимодействует со следующими ее функциональными задачами и подсистемами: · Функциональной задачей «Формирование и ведение единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации» (ФЗ «Реестр объектов»); · Геоинформационной подсистемой АСУ ТК (П-ГИС); · Подсистемой ведения нормативно-справочной информации и метаданных (П-НСИ); · Подсистемой сбора данных и централизованное хранилище данных (П-СД); · Подсистемой информационного взаимодействия (П-ИВ). 3.4.2. Взаимодействие с внешними информационными системами Список внешних информационных систем, с которыми осуществляется взаимодействие Модуля СЦ: · ЕСИА; · мессенджер; · Яндекс Геокодер; · Информационная система «Централизованная система сбора информации систем-112»; · ПВК «Поиск-Море», АИС РПТ; · облачная АТС

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

4. ТРЕБОВАНИЯ К МОДУЛЮ СЦ - 4.2.4.1. Требования к технической реализации компонента «Интерактивная карта» При реализации компонента «Интерактивная карта» должны учитываться требования, указанные ниже. 4.2.4.1.1. Требования к отображению элементов Повторяющихся элементы карты (ТС, ОТИ, события и пр.) должны отрисовываться с использованием аппаратного создания экземпляров объектов на пользовательском устройстве (WebGL/WebGPU)). Отрисовка каждого объекта отдельным запросом не допускается, должна обеспечиваться возможность одновременного отображения не менее 5 000 объектов без снижения производительности (30 кадров в секунду на тестовой конфигурации). 4.2.4.1.2. Уровни детализации объектов Для управления отображением сложных объектов должно быть создано не менее 3-х уровней детализации, отображаемых при изменении масштаба с возможностью автоматического переключения между уровнями. Все отображаемые объекты должны масштабироваться с учетом разрешения экрана пользователя с сохранением качества детализации. 4.2.4.1.3. Полигональная оптимизация и текстурирование При реализации компонента «Интерактивная карта» должна обеспечиваться технология рельефного тестурирования объектов. Не должны использоваться высокополигональные трехмерные модели. Все повторяющиеся элементы должны генерироваться единоразово и повторно использоваться при последующих отображениях. 4.2.4.1.4. Управление памятью Требуется реализовать потоковую загрузку на устройство пользователя элементов карты и текстур. Загрузка данных целиком при старте приложения не допускается. Необходимо реализовать механизм очистки памяти от элементов, которые находятся вне области видимости камеры в течение заданного времени. 4.2.4.1.5. Требования к взаимодействию пользователя с интерфейсом компонента «Интерактивная карта» Программная реализация механизмов управление камерой (масштабирование и навигация) должна быть выполнена с поддержкой технологии WebAssembly (WASM). Элементы управления должны являться неотъемлемой частью интерактивной карты. - - Значение характеристики не может изменяться участником закупки

4.2.5. Развитие компонента администрирования (3 очередь) Должна быть выполнена доработка ролевой модели. Ролевая модель должна обеспечивать управление доступом к отдельным объектам Модуля СЦ и их элементам (атрибутам) с разграничением по видам транспорта, регионам и пр., в частности: – определение набора конкретных действий, доступных пользователям (выполняемых над объектом доступа, например, удаление записи, редактирование записи, формирование отчета и др.); – реализация возможности объединения пользователей в группы; – определение прав доступа для групп пользователей; – реализация интерфейса визуальной настройки прав доступа пользователей к объектам Модуля СЦ

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

4.5.3. Требования по диагностированию Модуля СЦ Диагностирование Модуля СЦ должно осуществляться путем анализа записей в системных журналах СУБД, операционных систем серверов, а также с помощью встроенных средств диагностирования общего программного обеспечения Модуля СЦ. Диагностированию подлежат: – сбои и нарушения функционирования технического обеспечения (серверов) Модуля СЦ; – сбои и нарушения функционирования системного программного обеспечения серверов, используемых для работы Модуля СЦ; – сбои и нарушения функционирования прикладного программного обеспечения серверов, используемых для работы Модуля СЦ; – случаи недоступности (отсутствия ответа) или некорректные ответы внешних систем; – сбои и нарушения функционирования СУБД; – сбои при выполнении регламентных операций резервного копирования. При возникновении аварийных ситуаций либо ошибок в программном обеспечении диагностические инструменты должны позволять сохранять набор информации, необходимой для идентификации и устранения проблемы. Модуль СЦ и ее компоненты должны обеспечивать возможность диагностики своей работоспособности с возможностью интеграции с модулем мониторинга АСУ ТК. Набор передаваемых журналов и метрик должен быть определен на этапе технического проектирования

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

4.2.6. Взаимосвязи с внешними автоматизированными системами (1 очередь) Способы взаимодействия с внешними информационными системами должны быть определены на этапе технического проектирования. Должны быть выполнены следующие доработки: – интеграции с информационными ресурсами в целях получения данных о движении подвижных ТС (воздушные суда, суда водного транспорта); – интеграция с информационным ресурсом в целях получения данных о событиях на железнодорожном транспорте. Реализация интеграций должна включать проектирование и реализацию интеграционных механизмов обмена данными с учетом доступных вариантов реализации, обеспечение защищенных способов взаимодействия, настройку отображения отдельных данных на карте (настройка слоев). Взаимодействия, имеющие каналы связи, выходящие за пределы контролируемой зоны взаимодействующих систем, считаются защищенными, если для их защиты используются программные и/или программно-аппаратные шифровальные (криптографические) средства, сертифицированные ФСБ России (далее – СКЗИ). Выбор СКЗИ, схемы подключения и требуемого класса криптостойкости должен производиться в соответствии с Техническими условиями на подключение к информационным ресурсам ФГБУ «СИЦ Минтранса России» и инструкциями по подключению пользователей к ресурсам инфраструктуры Головного центра обработки данных, утвержденных приказом директора ФБГУ «СИЦ Минтранса России» от 24.05.2024 № 21-ОД

4.3. Требования к оказанию услуг по технической поддержке Модуля СЦ 4.3.1. Общие требования к оказанию Услуг Техническая поддержка Модуля СЦ должна осуществляться с учетом требований постановления Правительства Российской Федерации от 06.07.2015 N 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации». Подрядчик обязан выполнять требования законодательства в сфере защиты информации, требования по защите информации, информационной безопасности, указанные в локальных нормативных актах ФГБУ «СИЦ Минтранса России», регламентирующих условия информационного взаимодействия, защиты информации и подключения к информационным ресурсам ФГБУ «СИЦ Минтранса России», участвующих в информационном взаимодействии в рамках оказания услуг по технической поддержке АСУ ТК в 2026 году

4.3.1.1. Требования к составу и содержанию услуг третьего уровня технической поддержки Оказание услуг по технической поддержке Системы осуществляется в рамках этапов в соответствии с календарным планом. Подрядчик в течение 5 рабочих дней с даты заключения Контракта должен предоставить со своей стороны, а Заказчик со своей стороны Матрицу ответственных за взаимодействия в соответствии с Приложением 1 к Регламенту оказания услуг по третьему уровню технической поддержки Модуля СЦ (далее – Регламент, Приложение В). Подрядчик в течение 10 рабочих дней с даты заключения Контракта должен провести мероприятия по организации третьего уровня технической поддержки в соответствии с Регламентом. Услуги по третьему уровню технической поддержки Модуля СЦ должны включать: – организацию Подрядчиком третьего уровня технической поддержки; – информационно-консультационную поддержку работников Заказчика; – решение инцидентов, связанных с работой ППО; – адаптационное, конфигурационное и коррекционное сопровождение Модуля СЦ (в рамках действующих программных модулей и функциональности); – устранение уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности

4.5.5. Требования к информационной безопасности Работы по защите информации/информационной безопасности, не включенные в состав настоящего раздела, требуемые в соответствии с требованиями постановления Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации», а также нормативно правовых актов в области защиты персональных данных и обеспечения безопасности объектов критической информационной инфраструктуры, будут проведены в рамках исполнения отдельного контракта, заключенного по результатам отдельной закупочной процедуры (не является частью данного ТЗ), включающего: – определение актуальных угроз безопасности информации и актуализация модели угроз безопасности информации (при необходимости); – выполнение требований о согласовании технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России в установленном порядке; – выполнение требований по устранению Подрядчиком замечаний и недостатков, в случае их выявления при согласовании Заказчиком технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России; – выполнение требований к классу защищенности ГИС, уровню защищенности персональных данных и категории значимости объекта КИИ РФ, установленных для Головного центра обработки данных ФГБУ «СИЦ Минтранса России» (далее – ГЦОД);

– определение перечня объектов защиты информационной системы; – описание (актуализированных) требований к системе защиты информации, а также к мерам защиты информации информационной системы в зависимости от установленных классов защищенности, уровня защищенности персональных данных и категории значимости объектов КИИ РФ (приказы ФСТЭК России № 21, 117, 239); – выполнение требований к мерам по защите ГИС от атак, направленных на отказ в обслуживании, в соответствии с пунктами 30, 34, 59, 63 Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений, утвержденных приказом ФСТЭК России от 11.04.2025 № 117; – описание (актуализированных) требований по защите информации, подлежащих реализации в информационно телекоммуникационной инфраструктуре ГЦОД; – выполнение требований о применении сертифицированных средств защиты информации, включая их классы защиты и уровни доверия; – выполнение требований о запрете использования с 01.01.2025 органами (организациями) средств защиты информации странами происхождения, которых являются иностранные государства в соответствии с пунктом 6 Указа Президента Российской Федерации от 01.05.2022 № 250; – выполнение требований по обеспечению непрерывного взаимодействия с ГосСОПКА в установленном порядке;

4.3.1.2. Требования к общему порядку оказания услуг Техническая поддержка Модуля СЦ должна быть организована на трех уровнях: – первый и второй уровни технической поддержки организуется Заказчиком; – третий уровень технической поддержки организуется Подрядчиком. Перечень действий на каждом уровне технической поддержки указан в Таблице 5: Таблица 5 – Перечень действий на каждом уровне технической поддержки Уровень технической поддержки Доступные действия Условия передачи задачи на следующий уровень Первый уровень технической поддержки (далее – 1-й уровень) – принимает обращения (заявки) пользователей Модуля СЦ и работников Заказчика; – регистрирует обращения в Модуле СЦ регистрации обращений; – присваивает уникальный идентификационный номер, классифицирует обращения; – самостоятельно решает обращения, которые связаны с недостаточной квалификацией пользователей или настройками в рамках своей компетенции; – взаимодействует с пользователями Модуля СЦ при решении проблемы Передает обращение на второй уровень поддержки в случае невозможности решения на своем уровне Второй уровень технической поддержки (далее – 2-й уровень) – принимает обращения от 1-го уровня; – уточняет классификацию обращения в результате дополнительного анализа; – самостоятельно решает обращения в рамках своей компетенции; – осуществляет техническую и консультационную поддержку Модуля СЦ; – взаимодействует с сотрудниками 1-го и 3-го уровня и пользователями Модуля СЦ; – формирует заявки для 3-го уровня и контролирует исполнение Передает обращение на третий уровень поддержки в случае невозможности решения на своем уровне Третий уровень технической поддержки (далее – 3-й уровень) – принимает обращения от 2-го уровня; – обеспечивает выполнение требований, предъявляемых Контрактом и настоящим Техническим заданием к Услугам, оказываемым Подрядчиком Все поступающие обращения должны быть исполнены Подрядчиком

Для обеспечения взаимодействия с Заказчиком Подрядчик со своей стороны определяет ответственных лиц, уполномоченных в структуре Подрядчика за своевременное и качественное оказание Услуг в рамках настоящего ТЗ, а также контактную информацию ответственных лиц (телефон, электронную почту). Подрядчик должен предоставить Заказчику единый адрес электронной почты для приема обращений (заявок) в течение 3 (трех) рабочих дней после заключения Контракта. Указанный в настоящем пункте адрес электронной почты (способ направления обращений (заявок) применяется в случае сбоя в работе СРО Заказчика. Со своей стороны, Заказчик предоставляет Подрядчику перечень и контактную информацию (телефон, электронную почту) уполномоченных лиц для осуществления взаимодействия с указанием зон ответственности. О любых изменениях в контактной информации ответственных лиц Стороны должны уведомить друг друга в течение 1 (одного) рабочего дня с момента возникновения таких изменений посредством уведомления на электронную почту ответственных лиц и/или в письменной форме. В результате оказания услуг по настоящему ТЗ не должны быть изменены исходные коды, дистрибутивы и иные компоненты Модуля СЦ вне согласованных с Заказчиком изменений. Любые изменения исходных кодов, дистрибутивов и иных компонентов Модуля СЦ должны производиться только после согласования с Заказчиком уполномоченными лицами по электронной почте или иным заранее согласованным способом. Не должна быть ухудшена надежность и производительность Модуля СЦ. Оказание услуг по Контракту не должно нарушать требования к информационной безопасности, описанной в документации на Модуль СЦ

– выполнение требований по обеспечению в автоматизированном режиме с Национальной системой противодействия DDoS-атакам (НСПА) Центра мониторинга и управления сетью связи общего пользования ФГУП «ГРЧЦ» в рамках реализации мер по защите ГИС от атак, направленных на отказ в обслуживании; – детализированные требования к составу и содержанию работ по аттестации, а также к их результатам в соответствии с пунктами 13, 15 и 16 требований приказа ФСТЭК России от 29.04.2021 № 77 «Об утверждении Порядка организации и проведения работ по аттестации объектов информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну»

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

Подрядчик должен обеспечить реализацию и проведение внутренних проверок мер по разработке безопасного ПО, приведенных в Руководстве. Подрядчик должен провести анализ угроз безопасности информации программного обеспечения в соответствии с ГОСТ 58412-2019 «Защита информации. Разработка безопасного программного обеспечения. Угрозы безопасности информации при разработке программного обеспечения». Подрядчик должен провести испытания по выявлению уязвимостей в программном обеспечении Системы: · проведение статического анализа исходного кода программы; · проведение динамического анализа исходного кода программы; · проведение композитного анализа исходного кода и образов программы; · проведение фаззинг-тестирования программы, направленного на выявление в ней уязвимостей. Испытания по выявлению уязвимостей в программном обеспечении Системы должны быть проведены в рамках: · предварительных испытаний; · опытной эксплуатации; · приемочных испытаний

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

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

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

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

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

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

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

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

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

4.5.8. Требования к защите от влияния внешних воздействий Требования к защите от влияния внешних воздействий не предъявляются

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

4.3.4. Требования к документированию результатов оказываемых услуг Для обеспечения контроля оказываемых услуг по поддержке Модуля СЦ со стороны Заказчика, по окончании каждого отчетного периода по контракту в соответствии с календарным планом, Подрядчик обязан предоставить Заказчику Отчет об оказанных услугах. Отчет должен содержать детальную информацию об оказанных услугах с указанием даты выполненных мероприятий и приложением обосновывающих документов (заявок, запросов, требований) или ссылкой на такие документы, если они содержатся в Модуле СЦ. Информация о выполненных мероприятиях по заявкам должна быть сформирована на основании соответствующих записей СРО по каждому этапу исполнения Контракта. В случае оказания услуги адаптационного, конфигурационного и коррекционного сопровождения Модуля СЦ, должны быть предоставлены документы, подтверждающие выполнение требований п. 29.3 приказа ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации». Фактическое время реагирования и время решения по всем обращениям, поступившим в СРО, формируется в СРО по итогам отчетного периода в разделе «Отчеты». Фактическое время реагирования и время решения по обращениям учитывает суммарное время, затраченное на реагирование и, соответственно, на работу по обращению с момента назначения обращения специалисту Подрядчика или группе исполнителей, ответственным за оказание услуг технической поддержки 3 уровня от начала до завершения работ Подрядчиком. При этом принимается суммарное время нахождения заявки в соответствующих статусах заявки СРО на стороне Подрядчика

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

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

Лицензионное (сублицензионное) соглашение (договор) не может возлагать на Заказчика какие-либо обязанности (в т.ч. в части конфиденциальности, предоставления отчетности), не предусмотренные Контрактом. 4.5.9.7. Передача Заказчику исключительных прав, или простых (неисключительных) прав не может повлечь увеличение стоимости Контракта и/или изменение иных существенных условий Контракта. 4.5.9.8. Функциональность Модуля СЦ передается в объеме и в сроки, установленные Техническим заданием. 4.5.9.9. Нарушение условий настоящего раздела Технического задания, в т.ч. отсутствие соответствующего лицензионного (сублицензионного) соглашения (или договора), либо предоставление лицензионного (сублицензионного) соглашения (или договора), не соответствующего требованиям действующего законодательства Российской Федерации или требованиям Контракта, является нарушением существенных условий Контракта. 4.5.9.10. В случае, если в соответствии с пунктом 4.5.9.6 Заказчику передается исключительное право, такая передача осуществляется в порядке, установленном Гражданским кодексом Российской Федерации. 4.5.9.11. В случае, если при выполнении Работ положения пунктов 4.5.9.5-4.5.9.6 не применялись, Подрядчик в составе отчетной документации предоставляет об этом декларацию в свободной форме. Декларация должна содержать сведения о полном соответствии результата Работ требованиям Контракта, а также о неприменении при выполнении работ готового программного обеспечения (платформ, подсистем, СУБД и т.д.), которое стало частью (компонентом) Системы

Таблица 6. Категории обращений и заявок Категория Примеры Запрос на обслуживание Подготовка SQL запроса к СУБД для решения прикладной задачи и д.р. – запрос на любое действие, не являющееся запросом информации и несовершенный на основе происшествия, прямо или косвенно влияющего на работу Модуля СЦ Консультация «Где взять / куда обратиться...?», «Как сделать / выполнить…», «Как это работает…?» - запрос, имеющий своей целью получение информационной поддержки Инцидент Разбор ошибок/сбоев и подготовка материалов (корректировочных релизов, инструкций) для Заказчика для устранения ошибок/сбоев, которые приводят к частичному и полному нарушению работоспособности всех или отдельных функций ППО. Подготовка изменения и материалов, необходимых для проведения аварийно-восстановительных работ для возобновления работоспособности Модуля СЦ ЗНИ Подготовка изменений, связанных с изменением, улучшением/оптимизацией Модуля СЦ и выводом новой модифицированной функциональности в штатном режиме. Подготовка изменений, связанных с модификацией существующих и/или реализация новых интеграционных механизмов для получения/обработки данных внешних систем. Подготовка изменений графического интерфейса по требованиям Заказчика. Перечень статусов обращений (заявок) приведен в пункте 3.3. Регламента оказания Услуг. Назначение обращению (заявке) статуса «Закрыто» осуществляется Заказчиком только после получения от инициатора обращения (заявки) подтверждения о его исполнении или нахождения обращения (заявки) в статусе «Выполнено» и отсутствия повторных вопросов/запросов по данному обращению (заявки) в течение 5 рабочих дней. Категории и статусы обращений (заявок) могут быть скорректированы в процессе оказания услуг исключительно по согласованию с Заказчиком

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

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

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

4.3.6.2. Требования к услугам информационно-консультационной поддержки работников Заказчика и пользователей Модуля СЦ Услуги информационно-консультационной поддержки сотрудников Заказчика включают: – обработку обращений и заявок, поступивших от сотрудников Заказчика; – консультирование сотрудников Заказчика и пользователей Модуля СЦ; – актуализацию документации, и других материалов по работе с Модулем СЦ при необходимости. – консультирование и разработку рекомендаций по настройке Модуля СЦ (без изменения программного кода), включая изменение настроек функционирования; – консультации по вопросам использования, настройки и возможностям Модуля СЦ; – консультации по проведению превентивных мер для недопущения аварийных ситуаций в Модуле СЦ; – консультации по предварительной диагностике и локализации возникшей неисправности Модуля СЦ; – консультации по вопросам обеспечения информационной безопасности Модуля СЦ и настройки функций, обеспечивающих корректную работу программного обеспечения для совершения юридически значимых действий в Модуле СЦ; – другие вопросы, связанные с работой Модуля СЦ. 4.3.6.2.1. Требования к порядку оказания услуг информационно-консультационной поддержки работников Заказчика и пользователей Модуля СЦ Подрядчик выполняет консультирование сотрудников Заказчика и пользователей Модуля СЦ. Консультация может быть предоставлена по согласованным с представителем Заказчика каналам коммуникации с регистрацией результата консультации в СРО Подрядчиком. Детальный порядок оказания консультационных услуг определен в Регламенте оказания Услуг

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

4.5.11. Требования к показателям назначения 4.5.11.1. Требования к показателям назначения мероприятий по развитию Модуля СЦ В рамках выполнения работ по развитию Модуля СЦ, предусмотренных ТЗ, показатель назначения «Количество пользователей» должен соответствовать значениям, приведенным в данном разделе. Пояснения по показателям, связанным с количеством пользователей, приведены в Таблице 8. Таблица 8. Определения показателей, связанных с количеством пользователей в Модуле СЦ № Показатель Определение Расчетное количество пользователей Количество пользователей, работу которых должен обеспечить Модуль СЦ к моменту сдачи работ по Контракту с учетом достижения всех показателей назначения Расчетное количество одновременно работающих пользователей Количество одновременно работающих пользователей, работу которых должен обеспечивать Модуль СЦ к моменту сдачи работ по Контракту с учетом достижения всех показателей назначения Значения показателей количества пользователей, достижение которых необходимо обеспечить, представлено в Таблице 9

Таблица 9. Значения показателей количества пользователей № Показатель Значение 1. Расчетное количество пользователей 1 000 2. Расчетное среднее количество одновременно работающих пользователей 200 Развитие Модуля СЦ должно быть направлено на достижение следующего эффекта (показателя), подставленного в мероприятии 103.002 «Информационно-аналитическая система регулирования на транспорте (АСУ ТК)» ВПЦТ Минтранса России: Выполнение работ по развитию Модуля СЦ предусмотрено мероприятием по развитию АСУ ТК, приведенном в ВПЦТ Минтранса России на 2026-2028 гг: № 103.002 «АСУ ТК» в составе ИТ расхода 103.26.000005 «Развитие предусматривает реализацию ОКР и эффектов, приведенных в Таблице 10. Таблица 10. ОКР и эффекты, приведенные в ВПЦТ Минтранса России на 2026 г. № ОКР Дата ОКР Эффекты 1 Обеспечено информационное взаимодействие с Минобороны России о происшествиях на транспортных объектах 25.12.2026 Сокращено время сбора и передачи сведений для Минобороны России о ЧС и НС на транспорте с 120 до 10 минут 2 Обеспечена автоматизация формирования отчетов о нештатных ситуациях на транспорте, в том числе по данным внешних систем 25.12.2026 Сокращено время на подготовку отчетов о нештатных ситуациях на транспорте с 20 до 5 минут Реализация остальных ОКР не является предметом данного ТЗ и проводится в рамках отдельного технического задания.

4.5.11.2. Требования к показателям назначения мероприятий по эксплуатации Модуля СЦ. Работы по эксплуатации Модуля СЦ не должны обеспечивать режимы функционирования Модуля СЦ, приведенные в разделе 4.5.2 данного ТЗ

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

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

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

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

4.3.6.4. Требования к услугам адаптационного, конфигурационного и коррекционного сопровождения и доработки Модуля СЦ (в рамках действующих программных модулей и функциональностей) Услуги адаптационного, конфигурационного и коррекционного сопровождения и доработки Модуля СЦ включают: – управление изменениями и адаптация функций Модуля СЦ; – изменение настроек функционирования Модуля СЦ; – внесение изменений и/или модификаций Модуля СЦ (в рамках действующих программных модулей и функциональностей), направленных на улучшение их работоспособности и функциональных возможностей; – подготовка и передача Заказчику SQL запросов в СУБД для получения агрегированной информации из Модуля СЦ, которую невозможно получить с использованием графического пользовательского интерфейса; – адаптация модулей интеграций со смежными информационными системами

4.3.6.4.1. Требования к проведению изменений Основанием для внесения изменений является запрос от Заказчика. Все активности по внесению изменений должны быть согласованы с Заказчиком, а действия Подрядчика при оказании данной услуги должны быть зафиксированы. В рамках данного Технического задания изменениями считаются локальные доработки функционала Модуля СЦ, которые не должны приводить к необходимости выполнения дополнительных аттестационных испытаний или переаттестации АСУ ТК в соответствии с п. 33 приказа от 29.04.2021 № 77 «Об утверждении Порядка организации и проведения работ по аттестации объектов информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну». При необходимости внесения изменений в Модуль СЦ, не связанных с критичным инцидентом, существенно нарушающим работоспособность Модуля СЦ, Заказчик направляет Подрядчику обращение (заявку), в котором излагает суть изменения, которое требуется внести в Модуль СЦ. Исполнитель, в течение 3 (трех) рабочих дней с момента поступления соответствующего обращения (заявки), оценивает техническую возможность реализации запрашиваемого изменения и варианты реализации. По итогу проведения оценки Подрядчик направляет Заказчику заключение о возможности реализации данного изменения с описанием возможных вариантов реализации и согласует с Заказчиком проведение данного изменения

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

4.3.6.4.2. Требования к изменению настроек функционирования Изменение настроек функционирования может проводиться в рамках допустимых пределов изменения функционирования, заложенных в архитектуру Модуля СЦ. Изменение настроек функционирования включает в себя изменение данных и справочников, изменение форм документов, формируемых Модулем СЦ, изменение и настройку форматов и версий передачи данных в смежные системы. Доработка программного кода Модуля СЦ может допускаться (в случае необходимости) при выполнении работ по адаптации функций Модуля СЦ в части изменения формата передачи данных в смежные информационные системы при условии соблюдения требований пункта 29.3 приказа ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации»

4.3.6.5. Требования к услугам по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности По запросу Заказчика Подрядчик должен провести работу по приведению ППО в соответствие с требованиями по обеспечению информационной безопасности. Критичность уязвимости оценивается в соответствии в соответствии с Методическим документом ФСТЭК России «Методика оценки уровня критичности уязвимостей программных, программно-аппаратных средств» (утвержден ФСТЭК России 30.06.2025), а также с учетом ГОСТ 56545-2015 и международными стандартами (CVSS 3.0 и выше), и задает необходимый срок устранения. В процессе проведения Заказчиком обследования Модуля СЦ и выявления уязвимостей в ППО, связанных с исходным кодом Модуля СЦ и/или используемыми компонентами (библиотеками), Заказчик направляет Подрядчику обращение (заявку) на устранение, с указанием критичности и срочности принятия мер по устранению в СРО.

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

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

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

4.4. Требования к видам обеспечения 4.4.1. Требования к лингвистическому обеспечению Документация на Модуль СЦ должна разрабатываться на русском языке. Взаимодействие пользователей с Модулем СЦ посредством графического интерфейса должно происходить на русском языке за исключением сообщений, зависящих от настроек системного программного обеспечения, установленного на рабочих местах пользователей. При разработке программных решений Модуля СЦ должно быть предусмотрено использование языков программирования высокого уровня, приведенных в Таблице 7. Таблица 7. Языки и средства разработки, специального программного обеспечения Модуля СЦ Категория Наименование Назначение Языки программирования Kotlin Разработка серверной логики и сервисов (backend) JavaScript / TypeScript Разработка клиентской части (frontend) Python Разработка скриптов интеграции, обработки данных и автоматизации Фреймворки и библиотеки Vue.JS Разработка пользовательских интерфейсов (веб-интерфейсы компонентов визуализации и отчетности) React Разработка пользовательских интерфейсов (при необходимости создания сложных интерактивных компонентов) Решения по лингвистическому обеспечению, включая перечень используемых языков программирования, должны быть согласованы с Заказчиком на этапе технического проектирования

4.4.2. Требования к математическому обеспечению Требования к математическому обеспечению не предъявляются. 4.4.3. Требования к метрологическому обеспечению Требования к метрологическому обеспечению не предъявляются. 4.4.4. Требования к организационному обеспечению Требования к организационному обеспечению не предъявляются. 4.4.5. Требования к методическому обеспечению Задачи методического обеспечения Модуля СЦ должны быть обеспечены за счет использования технологических и методических документов касающихся вопросов функционирования транспортного комплекса и разработки и эксплуатации ПО. 4.4.6. Требования к информационному обеспечению Состав, структура и способы организации информационного обеспечения в Модуле СЦ должны быть определены на этапе технического проектирования. Факты информационного обмена с внешними системами должны фиксироваться в соответствующем журнале

4.1. Требования к структуре Модуля СЦ В процессе работ по развитию Системы должны сохраниться основные требования к построению архитектуры Системы в соответствии с принципами трехуровневой архитектуры: 1. уровень хранения данных или уровень базы данных (сервер СУБД); 2. уровень сервера приложений (сервер аналитической обработки); 3. презентационный уровень, обеспечивающий взаимодействие с клиентскими приложениями. В состав Системы должны входить следующие основные компоненты: 4. сервер баз данных; 5. сервер приложений; 6. веб-сервер. Сервер баз данных должен обеспечивать хранение и целостность хранимых данных, создание резервных копий, ведение журнала транзакций, восстановление данных после сбоев. Сервер приложений должен обеспечивать обработку запросов, поступающих от клиентских приложений (через веб-сервер), формирование ответов на запрос в доступном пользователю виде (формирование пользовательских интерфейсов). Веб-сервер должен обеспечивать взаимодействие с оператором и внешними системами по HTTP / HTTPS протоколу в режиме «запрос-ответ» (получения запросов от пользователя и передачи ответа в виде соответствующей информации, обработанной серверами приложений). Взаимодействие Системы с пользователем должно отвечать требованиям модели «тонкого клиента» (т.е. представлять на стороне клиента (пользователя) лишь графический пользовательский интерфейс). Все составляющие Системы должны использовать единую методологию и отвечать единым принципам взаимодействия, надежности и управления. Перечень компонентов Модуля СЦ представлен в Таблице 4. Таблица 4. Перечень компонентов Модуля СЦ, в отношении которых выполняются работы по развитию № п.п. Наименование компонента Модуля СЦ Раздел ТЗ 1 Компонент регистрации событий 4.2.1. 2 Компонент отчетности 4.2.2 3 Компонент визуализации 4.2.3 4 «Интерактивная карта» (компонент создается) 4.2.4 5 Компонент администрирования 4.2.5

4.2. Требования к дорабатываемым функциям модуля СЦ 4.2.1. Развитие компонента регистрации событий (1 очередь) Должны быть выполнены следующие доработки: – обеспечение логирования действий пользователя, связанных с карточкой события; – доработка объектной модели в части создания новых типов сущностей (карточек) с учетом реализуемых интеграций с информационными ресурсами (силы и средства предупреждения и ликвидации ЧС и нештатных ситуаций на транспорте, ТС, ограничения воздушного пространства, неблагоприятные и опасные природные явления); – реализация механизма установления связи между сущностями в Модуле СЦ автоматизированным и ручным способами (события, природные явления, силы и средства предупреждения и ликвидации ЧС и нештатных ситуаций на транспорте, ограничения воздушного пространства, ОТИ, ТС и др.); – отображение в карточке установленных связей между сущностями.

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

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

4.4.7.1. Требования к инструментам разработки и процессу контроля версий программного обеспечения 4.4.7.1.1. Система контроля версий Для управления исходным кодом должна использоваться система контроля версий кода, развернутая в инфраструктуре Заказчика. 4.4.7.1.2. Правила именования веток Имя ветки должно соответствовать следующему формату: / / Категории веток: ? feature/ — разработка новой функциональности, а также рефакторинг или удаление существующей; ? fix/ — исправление ошибок; ? hotfix/ — срочные исправления, применяемые в обход стандартного процесса разработки; ? test/ — для проведения экспериментов, не влияющих на основную разработку. Идентификатор задачи: после категории указывается ссылка на задачу (issue) в системе контроля версий кода. Описание: добавляется краткое описание решаемой задачи в формате kebab-case (слова разделяются дефисами, например, add-user-auth). Примеры именования веток: ? feature/#123/add-payment-integration; ? fix/#45/correct-calculation-logic; ? hotfix/#67/urgent-database-connection-patch. 4.4.7.1.3. Правила именования коммитов Сообщение коммита должно соответствовать соглашению Conventional Commits и состоять из категории и описания: : ? fix — исправление ошибки. Примеры сообщений коммитов: ? feat: добавление формы регистрации пользователя; ? fix: исправление ошибки валидации email-адреса; ? refactor: оптимизация алгоритма сортировки данных; ? chore: обновление версий в файле dependencies. 4.4.7.1.4. Модель ветвления В процессе разработки используются следующие основные ветви: ? main / master — стабильная ветка, содержит только код, прошедший полное тестирование и развернутый в продуктивных контурах; ? dev — ветка для интеграции завершенных задач, предназначенная для сборки и тестирования в тестовых средах. Попадание кода в main осуществляется только через Merge Request (MR) из dev

4.2.2. Развитие компонента отчетности (3 очередь) Должна быть обеспечена автоматизация процессов формирования отчетов о ЧС и нештатных ситуациях на транспорте, в т.ч. на основе данных из внешних систем. Включает следующие доработки: – разработка шаблонов отчетов в различных форматах (табличный, текстовый); – реализация выбора фотоматериалов для включения в справку; – форматирование содержимого справок с учетом правил русского языка в отношении окончаний слов (в зависимости от падежа, склонения, числа и рода); – автоматизированное формирование выводов к содержимому справки на основе настраиваемых критериев; – создание интерфейса выбора параметров (фильтрации) для формирования отчетов: o состав полей для включения в отчёт; o настройка диапазонов значений характеристик и дат; o порядок отображения полей; o настройка заголовка. – реализация способа подготовки отчётов в асинхронном режиме (очереди); – реализация интерфейса компонента формирования отчетности для отображения очереди формирования отчетов и статусов их подготовки; – экспорт отчётов в форматы xlsx, csv и справок в форматы pdf, docx. Необходимо разработать не менее 10 шаблонов отчетов и/или справок. Перечень, структура и содержание шаблонов должны быть согласованы с Заказчиком на этапе технического проектирования.

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

– отображение на карте связанных сущностей и ОТИ; – реализация функции выбора темного и светлого стилей отображения элементов интерфейса, карточек сущностей, картографической основы и объектов, отображаемых на карте; – реализация механизма для выбора картографической основы в одном из распространенных форматов WMTS, TMS, MVT и др. Должна быть предусмотрена возможность настройки перечня картографических основ и параметров доступа к ним; – настройка базового набора дашбордов, содержащих преднастроенные виджеты о количестве событий в разрезе видов транспорта с возможностью перехода к исходным данным (карточкам событий, ОТИ и т.д.), с фильтрацией по параметрам. Параметры фильтрации должны быть определены на этапе технического проектирования. Должно быть обеспечено автоматическое и принудительное обновление данных, отображаемых на дашбордах

4.4.7.1.5. Требования к используемым зависимостям (библиотекам) Все внешние зависимости проекта должны быть зафиксированы с указанием точных версий. Для контроля версий зависимостей в репозиторий обязательно должны быть включены следующие файлы: · Для JavaScript: package-lock.json или yarn.lock; · Для Python: requirements.txt (с зафиксированными версиями) или Pipfile.lock; · Для Go: go.mod и go.sum; Загрузка всех зависимостей должна производиться исключительно через внутренний прокси-репозиторий Заказчика, настроенный в соответствующем системе менеджере пакетов. Запрещается: · Использование плавающих версий (например, ^1.2.3, ~4.5.0, latest); · Использование библиотек, содержащих критические уязвимости, в том числе зарегистрированные в реестре CVE (Common Vulnerabilities and Exposures). 4.4.7.1.6. Требования к процессу непрерывной интеграции (CI) Сборка программного обеспечения, включая этапы компиляции, тестирования и анализа кода, должна выполняться исключительно в инфраструктуре непрерывной интеграции Заказчика. 4.4.7.1.7. Требования к хранению артефактов сборки Все артефакты сборки (результирующие пакеты, Docker-образы и т.д.) подлежат обязательному хранению в предназначенной для этого инфраструктуре Заказчика (артефакторий). Запрещается размещение финальных артефактов сборки на сторонних ресурсах

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

4.5. Общие технические требования 4.5.1. Требования к численности и квалификации персонала и пользователей Модуля СЦ Программное обеспечение Модуля СЦ не должно требовать изменения штатной численности персонала Заказчика. Программное обеспечение Модуля СЦ не должно требовать наличия у пользователей дополнительной квалификации в сфере информационных технологий, кроме базовых знаний в обращении с персональным компьютером, базовых навыков работы в интернет-обозревателях и знаний о Модуле СЦ в объеме документов Руководство пользователя, Руководство администратора

4.2.4. Создание компонента «Интерактивная карта» (2 очередь) В составе создаваемого компонента должны отображаться данные, доступные в компоненте визуализации. Требования к интерфейсу интерактивной карты: – интерактивная карта должна быть представлена в виде объемной карты с учетом макетов, представленных в Приложении А к ТЗ; – интерфейс должен корректно отображаться на экранах мониторов (разрешение Full HD 1920?1080), телевизоров (разрешение 4К 3840?2160), жидкокристаллических панелей для видеостены, используемой Заказчиком, с параметрами каждой панели: диагональ 55 дюймов, разрешение 1920x1080; – интерфейс должен корректно отображаться на планшетных устройствах с диагональю экрана 10-12 дюймов, конкретные требования должны быть уточнены на этапе технического проектирования; – должна быть обеспечена кластеризация и генерализация отображения объектов на карте при изменении масштаба; – должно быть обеспечено отображение основных характеристик объектов при выборе их на карте; – должно быть обеспечено управление отображением слоев на карте; – должна быть обеспечена настройка цветовой индикации отображаемых объектов транспортной инфраструктуры; – должно быть обеспечено отображение легенды карты, содержащей отображаемые объекты на карте; – должна быть обеспечена возможность одновременного отображения не менее 5 000 ОТИ и ТС на карте.

На интерактивной карте должны быть отображены подвижные объекты совместно с объектами транспортной инфраструктуры (ОТИ), включая следующие возможности: § отображение местоположения транспортных средств (воздушный, водный и автомобильный транспорт) на карте в режиме реального времени (с заданным периодом обновления данных); § отображение маршрутов движения всех ТС за выбранный период времени, в том числе с использованием эффектов анимации; § отображение маршрутов движения ТС, связанных с карточкой события: ТС, являющихся участниками события, и ТС, находящиеся в заданном радиусе от события; § управление отображением сущностей и ОТИ на карте, включая настройку состава отображаемых объектов, поиск, фильтрацию, с использованием соответствующей панели управления и наглядным представлением результатов; § автоматическое изменение вида отображения объектов (цветовая индикация) по заданным условиям (например, при достижении критических значений параметров, характеризующих функционирование объекта); Должна обеспечиваться производительность обновления изображения на экране в 30 кадров в секунду на тестовой конфигурации пользовательского устройства (модель Бештау AIO2402/B560, входящая в Реестр российской промышленной продукции под номером 10394100 или аналог) при одновременном отображении не менее 5 000 объектов и 200 уникальных моделей объектов. Макеты интерфейсов Модуля СЦ должны быть предварительно согласованы с Заказчиком и разработаны с учетом требований ГОСТ Р ИСО 9241-161-2016 «Элементы графического пользовательского интерфейса»

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

В аварийном режиме осуществляется поиск неисправностей и проведение работ по их устранению. Перевод в аварийный режим должен осуществляться при возникновении сбоев, аварий и прочих незапланированных воздействий, сразу после наступления одной или нескольких аварийных ситуаций, с последующим возвратом в штатный режим функционирования сразу после окончания восстановительных работ. ПО Модуля СЦ должно обладать надежностью, обеспечивающей работу пользователей в произвольном режиме и оперативное восстановление работоспособности при сбоях. В целях обеспечения надежного функционирования ПО должно предусматривать: – сохранение целостности данных при нештатном завершении работы компонентов Модуля СЦ; – сохранение работоспособности программного обеспечения при некорректных действиях пользователя; – резервное копирование базы данных Модуля СЦ. – время восстановления работоспособности Модуля СЦ после отказа не более 4 часов. – отказоустойчивость на уровне 99% при единовременной количестве не менее 200 пользовательских сессий в Модуле СЦ. Указанные характеристики приведены без учета характеристик надежности инфраструктуры и времени передачи информации по каналам связи. При возникновении сбоев в аппаратном обеспечении, включая аварийное отключение электропитания, Модуль СЦ должен автоматически восстанавливать свою работоспособность (не требовать перенастройки) после устранения сбоев и корректного перезапуска аппаратного обеспечения

5. СОСТАВ И СОДЕРЖАНИЕ РАБОТ ПО РАЗВИТИЮ И ТЕХНИЧЕСКОЙ ПОДДЕРЖКЕ МОДУЛЯ СЦ (КАЛЕНДАРНЫЙ ПЛАН) - Сдача-приемка результатов выполненных работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная техническая документация, а также результаты работ предоставляются Заказчику в порядке, предусмотренном Контрактом и ТЗ, до размещения Подрядчиком в ЕИС документа о приемке. Документ о приемке размещается в ЕИС по каждому этапу в соответствии с условиями Контракта. Этапы выполнения работ по развитию Модуля СЦ приведены в Таблице 11. Таблица 11. Этапы выполнения работ по развитию Модуля СЦ. № этапа Наименование этапа Результат (отчетная документация) Срок исполнения этапа - - Значение характеристики не может изменяться участником закупки

1 Техническое проектирование Сопроводительным письмом предоставляются Заказчику: · Технический проект, включая следующие документы: – Ведомость технического проекта; – Ведомость машинных носителей информации – Пояснительная записка; – Описание информационного обеспечения системы; – Описание автоматизируемых функций; – Схема функциональной структуры; – Описание организации информационной базы; – Описание программного обеспечения; · Макеты экранных форм компонента «Интерактивная карта»; · Руководство по безопасной разработке программного обеспечения; · Документ о приемке Начало: с даты заключения контракта Окончание: не позднее 31.07.2026

2 Услуги по технической поддержке Модуля СЦ (с даты заключения контракта по 10.09.2026) По окончании оказания Услуг сопроводительным письмом предоставляются Заказчику: – Отчет об оказанных Услугах по технической поддержке; – Актуальные на дату окончания оказания Услуг по данному этапу исходные коды прикладного ПО на электронном носителе (в случае внесения изменений); – Инструкция по сборке и развертыванию (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство пользователя (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство администратора (в случае внесения изменений); – Документ о приемке Начало: с даты заключения контракта Окончание: не позднее 10.09.2026

3 Разработка программного обеспечения (1 очередь, пп. 4.2.1, 4.2.6 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ; – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 1 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 1 очереди; – Руководство по резервному копированию; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 16.09.2026

4 Разработка программного обеспечения (2 очередь, пп. 4.2.3, 4.2.4 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ. – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 2 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 2 очереди; – Руководство по резервному копированию; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 25.09.2026

5 Разработка программного обеспечения (3 очередь, пп. 4.2.2, 4.2.5 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ; – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 3 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 3 очереди; – Руководство по резервному копированию; – Описание ролевой модели; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 09.10.2026

6 Опытная эксплуатация (1 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акт о завершении опытной эксплуатации 1 очереди; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке 17.09.2026 Окончание: не позднее 26.10.2026

7 Опытная эксплуатация (2 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акт о завершении опытной эксплуатации 2 очереди; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке 26.09.2026 Окончание: не позднее 26.10.2026

8 Опытная эксплуатация (3 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Акт о завершении опытной эксплуатации 3 очереди; – Документ о приемке Начало: с 10.10.2026 Окончание: не позднее 26.10.2026

9 Приемочные испытания Сопроводительным письмом предоставляются Заказчику: – Программа и методика приёмочных испытаний; – Протокол приемочных испытаний; – Исходные коды и дистрибутивы на электронном носителе (при условии внесения изменений, с учетом доработок по результатам опытной эксплуатации и проведенных испытаний); – Комплект рабочей документации на Модуль СЦ (при условии внесения изменений, с учетом доработок по результатам опытной эксплуатации и проведенных испытаний); – Акт приемки Системы в эксплуатацию; – Акт приемки-передачи исключительных прав на объект; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке; – Документы в соответствии с разделом 4.5.9 ТЗ; – Обеспечение гарантийных обязательств Начало: с 27.10.2026 Окончание: не позднее 10.11.2026

10 Услуги по технической поддержке Модуля СЦ (с 11.09.2026 по 15.12.2026) По окончании оказания Услуг сопроводительным письмом предоставляются Заказчику: – Отчет об оказанных Услугах по технической поддержке; – Актуальные на дату окончания оказания Услуг по данному этапу исходные коды прикладного ПО на электронном носителе (в случае внесения изменений); – Инструкция по сборке и развертыванию (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство пользователя (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство администратора (в случае внесения изменений); – Документ о приемке Начало: с 11.09.2026 Окончание: не позднее 15.12.2026

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

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

6.1. Сведения о гарантийном обслуживании Модуля СЦ Под гарантией понимается устранение Подрядчиком своими силами и за свой счет допущенных по его вине недостатков, выявленных после приемки выполненных Работ, как в работе самой Модуля СЦ, так и недостатков в отчетной документации. Если в период гарантийного срока обнаружатся недостатки, то Подрядчик обязан устранить их за свой счет, в сроки, установленные Заказчиком. Гарантийный срок в этом случае продлевается на период устранения недостатков. Срок гарантии: 1 год с даты приемки Заказчиком результатов исполнения Этапа № 9 контракта. Подрядчиком должны быть внесены соответствующие исправления в техническую и рабочую документацию (указанную в пунктах 5 и 6 настоящего ТЗ), связанные с устранением замечаний к работе Модуля СЦ или в случае выявления Заказчиком недостатков в такой документации в период гарантийного срока. Внесение изменений в документацию технического и рабочего проектирования осуществляется в соответствии с ГОСТ 2.503-2023 и ГОСТ Р 2.504-2021.

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

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

8. ТРЕБОВАНИЯ К СОСТАВУ И СОДЕРЖАНИЮ РАБОТ ПО ПОДГОТОВКЕ МОДУЛЯ СЦ К ВВОДУ В ЭКСПЛУАТАЦИЮ - По результатам проведения приемочных испытаний оформляется Протокол приемочных испытаний и Акт приемки в эксплуатацию. В случае, если взаимодействие с внешними системами не может быть проверено на средах постоянной эксплуатации взаимодействующих систем (по причине неготовности со стороны внешней системы или иным причинам), функции взаимодействия, разработанные в соответствии с требованиями ТЗ, должны быть проверены на тестовых данных с использованием программ-имитаторов взаимодействия. По результатам выполнения этапа приемочных испытаний должны быть подготовлены материалы для регистрации доработанной версии Модуля СЦ (объекта учета) в НФАП в соответствии с требованиями постановления Правительства Российской Федерации от 30 января 2013?г. №?62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин» (с изменениями и дополнениями) в части обязательности размещения результатов работ в национальном фонде алгоритмов и программ для электронных вычислительных машин. Сдача-приемка результатов выполнения Работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная, техническая документация, а также программное обеспечение предоставляется Заказчику в порядке, предусмотренном Контрактом и ТЗ до размещения Подрядчиком в Единой информационной системе в сфере закупок документа о приемке. Результаты проведения опытной эксплуатации, предварительных и приемочных испытаний должны быть зафиксированы в соответствующих протоколах и актах. Выявленные отклонения от настоящего ТЗ, оформляются как недостатки Модуля СЦ - - Значение характеристики не может изменяться участником закупки

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

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

9. ТРЕБОВАНИЯ К ДОКУМЕНТИРОВАНИЮ - 9.1. Общие требования Документация на Модуль СЦ должна быть разработана в составе, указанном в разделах 5-8 данного ТЗ, и должна удовлетворять требованиям комплекса стандартов и руководящих документов на автоматизированные системы: – ГОСТ Р 2.105-2019 в части оформления текстовых документов; – ГОСТ 34.201-2020 в части наименования и обозначения документов. Документация на Модуль СЦ должны оформляться на листах формата А4. Допускается для размещения рисунков и таблиц использование листов формата А3 с подшивкой по короткой стороне листа. Документы объемом более 25 (двадцати пяти) листов должны содержать информационную часть, состоящую из аннотации и содержания. Исходные коды должны быть представлены в 1 (одном) экземпляре на электронном носителе, отчетные материалы должны быть представлены в 2 (двух) экземплярах на бумажном носителе (по одному экземпляру для Заказчика и Подрядчика) и в 1 (одном) экземпляре на электронном носителе в формате документов DOCX и PDF. При разработке документов на Модуль СЦ допускается отклонение от требований комплекса стандартов, описанных выше. Документам на Модуль СЦ должны в обязательном порядке присваиваться уникальные децимальные номера в соответствии с порядком, установленном в ГОСТ 34.201-2020. Документ «Программа и методика предварительных испытаний» должен включать приложения с формой протокола предварительных испытаний и формой акта приемки в опытную эксплуатацию. Документ «Программа опытной эксплуатации» должен включать приложение с формой журнала опытной эксплуатации. Документ «Программа и методика приемочных испытаний» должен включать приложения с формой протокола приемочных испытаний и формой акта приемки в эксплуатацию - - Значение характеристики не может изменяться участником закупки

10. ИСТОЧНИКИ РАЗРАБОТКИ - 10.1. Список литературы Специальная литература для разработки ТЗ не использовалась. 10.2. Нормативно-методические документы Список используемых нормативно-методических документов представлен в разделе 1.6 технического задания. ? Приложение А Эскизы визуального оформления компонента «Интерактивная карта» - - Значение характеристики не может изменяться участником закупки

Приложение Б Параметры оказания услуг - Б.2. Приоритеты и регламентные сроки решения обращений (заявок) В зависимости от уровня сбоя в работе Системы обращению (заявке) присваивается один из следующих приоритетов, а также в зависимости от приоритета обращения (заявки) устанавливаются следующие контрольные сроки решения в соответствии с таблицей ниже (Таблица Б.2.1). Таблица Б.2.1 – Приоритеты и регламентные сроки решения обращений (заявок) № п/п Приоритет Максимальное время реагирования Время решения (срок выполнения) Описание приоритета По информационно-консультационной поддержке сотрудников Заказчика и пользователей Системы 1 - не более 1 часа не более 10 часов - По решению инцидентов, связанных с работой ППО: 1 Критический не более 30 минут не более 4 часов - полная недоступность ППО; - недоступность ключевых функций - ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО; - невозможность информационного обмена с ППО для ИС более 4 часов 2 Высокий не более 1 часа не более 8 часов - ошибки/сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; - снижение быстродействия СПО (время отклика ППО на операции превышает 30 секунд); - недоступность управления правами и ролями пользователей 3 Средний не более 4 часов не более 24 часов - невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым -недоступность функции формирования отчетов 4 Низкий не более 8 часов не более 40 часов - отклонение в работе ППО, не влияющее на корректную работу функций; - другие сбои и ошибки, затрагивающие основные функции ППО - - Значение характеристики не может изменяться участником закупки

По адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) 1 Критический не более 40 минут не более 8 часов - изменения, необходимые при проведении аварийно-восстановительных работ для возобновления работоспособности Системы; - изменения, связанные с критичными ошибками, блокирующими возможность оказания государственных услуг и/или чтение и внесение данных в Систему 2 Высокий не более 1 часа не более 40 часов - изменения, относящиеся к обеспечению работоспособности основной функциональности Системы, устраняют выявленные дефекты в работе Системы, оказывающие существенное влияние на работу пользователей в Системе; - изменения, затрагивающие три и более подсистемы/модуля Системы для адаптации 3 Средний не более 4 часов не более 72 часов - изменения, связанные с развитием/улучшением/оптимизацией Системы и выводом новой функциональности в штатном режиме для одного-двух модулей/подсистем; - изменения, связанные с развитием интеграционных механизмов Системы, например обновление существующих и/или реализация новых видов сведений СМЭВ, обновление существующих и/или реализация новых API, адаптация и/или изменение механизмов импорта и экспорта данных Системы и т.д. 4 Низкий не более 8 часов не более 160 часов - изменения, связанные с ошибками/корректировкой/изменением в отображении информации в пользовательском графическом интерфейсе Системы (графика, текст, органы управления, элементы интерфейса)

По устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности 1 Критический не более 30 минут не более 24 часов - критические уязвимости, влияющие на возможную полную недоступность ППО, ключевых функций Системы, ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО без возможности восстановления работоспособности Системы. - Критический уровень CVSS > 8.0 2 Высокий не более 1 часа не более 84 часов - критические уязвимости, влияющие на ошибки и сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО. - Высокий уровень CVSS 5.0 - 8.0 3 Средний не более 4 часов не более 120 часов - уязвимости, влияющие на невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым - Средний уровень CVSS 2.0 - 4.9 4 Низкий не более 8 часов не более 160 часов - уязвимости, влияющие на отклонение в работе ППО, не влияющее на корректную работу функций; - другие сбои и ошибки, затрагивающие основные функции ППО - Низкий уровень CVSS < 2.0

Взаимодействие Заказчика и Подрядчика в части регистрации и контроля времени реагирования и решения обращения (заявки) осуществляется через СРО. Заказчик предоставляет Подрядчику доступ к СРО после заключения Контракта. Поступившие от разных пользователей заявки по поводу однотипных инцидентов или имеющие общую причину должны объединяться в одну заявку. Срок выполнения включает время диагностики инцидента, в ходе которого определяется причина инцидента (проблемы) и способ его устранения. Подрядчик должен обеспечить функционирование Модуля СЦ в соответствии с требованиями и параметрами, указанными в настоящем ТЗ и Регламенте оказании услуг. Основные параметры быстродействия типовых операций в Модуле СЦ указаны в таблице ниже (таблица Б.2.2). Таблица Б.2.2 - Параметры быстродействия Модуля СЦ № п/п Наименование параметра Значение (секунд) 1 Среднее время получения сообщения из очереди сообщений 10 2 Среднее время получения ответа от Системы 5 3 Среднее время открытия карточки реестра 5

Б.1. Базовые параметры оказания Услуг Базовые параметры оказания Услуг приведены ниже: – режимы оказания Услуг (таблица Б.1.1); – сроки предоставления отчетности (таблица Б.1.2). Таблица Б.1.1 - Режимы оказания Услуг № п/п Параметр Значение

1 Режим работы Системы Круглосуточно (24х7) 2 Режим доступности информационно-консультационной поддержки пользователей Системы 2.1 Прием и регистрация обращений (заявок) в СРО Регистрация обращений (заявок) производится круглосуточно в режиме 24х7, без праздников и выходных дней. Обработка заявок первой линией поддержки осуществляется в рабочие дни с 9 до 18 часов 2.2 Консультирование сотрудников Заказчика и пользователей Системы в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 3 Режим доступности по решению инцидентов, связанных с работой ППО: 3.1 - приоритет «Критический» Круглосуточно (24х7) 3.2 - приоритет «Высокий» Круглосуточно (24х7) 3.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 3.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4 Режим доступности услуг по адаптации, конфигурации и коррекционному сопровождению Системы 4.1 - приоритет «Критический» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.2 - приоритет «Высокий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 5 Режим доступности по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности 5.1 - приоритет «Критический» Круглосуточно (24х7) 5.2 - приоритет «Высокий» Круглосуточно (24х7) 5.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 5.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням)

Таблица Б.1.2. Сроки предоставления отчетности, с момента получения запроса № п/п Параметр Значение 1 Предоставление отчета об оказанных услугах за произвольный период 10 рабочих дней 2 Предоставление подробной информации по инциденту с приоритетом «Критический» 16 рабочих часов 3 Предоставление актуализированной документации 10 рабочих дней

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

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

Уровень технической поддержки Организационно-структурная часть технической поддержки, имеющая определённые организационно-нормативными документами зоны ответственности, обязанности, а также временные нормативы, в течение которых эти обязательства должны выполняться либо эскалироваться на следующий уровень технической поддержки Услуги Услуги по технической поддержке Информационно-аналитической системы регулирования на транспорте АСУ ТК ФИО Фамилия, имя, отчество Эскалация Процедура повышения внимания к обращению (заявке) путем повышения его приоритета и/или передачи на следующий уровень технической поддержки, а также привлечение ролей, которые могут принимать решения без передачи на следующий уровень технической поддержки API Англ. Application Programming Interface — программный интерфейс приложения, интерфейс прикладного программирования — описание способов (набор классов, процедур, функций, структур или констант), которыми одна компьютерная программа может взаимодействовать с другой программой

CVSS Англ. Common Vulnerability Scoring System - открытый стандарт, используемый для расчета количественных оценок уязвимости в безопасности компьютерной системы, обычно с целью понять приоритет ее исправления. В современном инструментарии информационной безопасности используется версия 3.0 и выше с дополнительными метриками к базовым оценкам ID Англ. Identifier – идентификатор, уникальный признак объекта, позволяющий отличать его от других объектов, то есть, идентифицировать SLA Англ. Service Level Agreement - утвержденные условия по обработке обращения (заявки) с установленными метриками времени, которые определяют пороговые значения для эскалации в зависимости от статуса обращения (заявки) (например, время реакции – время от регистрации до осуществления первичной обработки, время решения – время от регистрации обращения (заявки) до его решения и т.д.) SQL Англ. Structured Query Language — «язык структурированных запросов», — декларативный язык программирования, применяемый для создания, модификации и управления данными в реляционной базе данных, управляемой соответствующей СУБД

1 Общие сведения 1.1 Полное наименование Услуг Оказание услуг по технической поддержке Модуля СЦ АСУ ТК в 2026 году. 1.2 Предмет Регламента оказания услуг Требования Технического задания

2 Общие положения 2.1 Цель и задачи оказания услуг Целью технической поддержки Системы является обеспечение ее стабильного и безопасного функционирования и эксплуатации, предупреждение, выявление и устранение сбоев в работе Системы и минимизация их неблагоприятного влияния. Для достижения поставленной цели требуется решение следующих задач: 1. Обеспечение информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы. 2. Поддержание параметров функционирования ППО Системы, удовлетворяющих требованиям производственных процессов, включая их непрерывность. 3. Обеспечение бесперебойного функционирования ППО и своевременное устранение сбоев и аварийных ситуаций в Системе. 4. Своевременное устранение уязвимостей при выявлении таковых, в соответствии с требованиями к обеспечению информационной безопасности. 5. Адаптация, конфигурирование, коррекция программного обеспечения в соответствии с изменениями нормативно-правовой базы и запросами уполномоченных сотрудников органов государственной власти, включая выполнение процедур тестирования и участие в обновлениях ППО на стендах Заказчика. 6. Обеспечение сохранения работоспособности ППО в изменяемой среде эксплуатации. 7. Ведение документации по настоящему контракту и инициирование актуализации документации на Систему по результатам обработки запросов Заказчика и внесения соответствующих изменений в ППО

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

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

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

Таблица 1 - Типы обращений (заявок) Тип обращения (заявки) Описание Запрос на обслуживание Подготовка SQL запроса к СУБД для решения прикладной задачи и д р. – запрос на любое действие, не являющееся запросом информации и несовершенный на основе происшествия, прямо или косвенно влияющего на работу Системы Консультация (входит в тип обращения (заявки) «Запрос на обслуживание») «Где взять / куда обратиться...?», «Как сделать / выполнить…», «Как это работает…?» - запрос, имеющий своей целью получение информационной поддержки Инцидент Разбор ошибок/сбоев и подготовка материалов (корректировочных релизов, инструкций) для Заказчика для устранения ошибок/сбоев, которые приводят к частичному и полному нарушению работоспособности всех или отдельных функций ППО. Подготовка изменения и материалов, необходимых для проведения аварийно-восстановительных работ для возобновления работоспособности Системы. ЗНИ Подготовка изменений, связанных с изменением, улучшением/оптимизацией Системы и выводом новой модифицированной функциональности в штатном режиме. Подготовка изменений, связанных с модификацией существующих и/или реализация новых интеграционных механизмов для получения/обработки данных внешних систем. Подготовка изменений графического интерфейса по требованиям Заказчика

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

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

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

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

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

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

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

3.4.1 Инцидент На рисунке 2 представлена функциональная схема регистрации и сопровождения обращений (заявок) типа «Инцидент». Рисунок 2 - Функциональная схема регистрации и сопровождения обращений (заявок) типа «Инцидент» 3.4.2 Запрос на обслуживание На рисунке 3 представлена функциональная схема регистрации и сопровождения обращения (заявки) типа «ЗНО». Рисунок 3 - Функциональная схема регистрации и сопровождения обращения (заявки) типа «ЗНО» 3.4.3 Запрос на изменение На рисунке 4 представлена функциональная схема регистрации и сопровождения обращений (заявок) типа «ЗНИ». Рисунок 4 - Функциональная схема регистрации и сопровождения обращений (заявок) типа «ЗНИ»

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

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

4 Формы обращений (заявок) на оказание услуг по технической поддержке Системы, заполняемые в СРО 4.1. Форма обращения (заявки) на оказание услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы При подаче обращения (заявки) типа «ЗНО» в СРО указывается (Таблица 5): Таблица 5 – Описание атрибутов формы обращения (заявки) на оказание услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 5) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 5) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 5) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 5) Категория обращения: информационно-консультационная поддержка Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 5) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 5) Текст запроса на оказание услуги по информационно-консультационной поддержке сотрудников Заказчика Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 5)

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

4.2. Форма обращения (заявки) на оказание услуги по решению инцидентов, связанных с работой ППО При подаче обращения (заявки) типа «Инцидент» в СРО указывается (Таблица 6): Таблица 6 – Описание атрибутов формы обращения (заявки) на оказание услуги по решению инцидентов, связанных с работой ППО Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 6) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 6) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 6,) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 6) Категория обращения (заявки): инцидент Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 6) Приоритет изменения Время - одно из значений: Низкий, Средний, Высокий или Критический. Определяет, очередность решения обращения (заявки), ресурсы, привлекаемые для решения обращения (заявки), порядок/процедура действий при решении обращения (заявки) – поле СРО «Приоритет» (см. рисунок 6,)

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

На рисунке 6 приведена форма обращения (заявки) типа «Инцидент» в СРО. Рисунок 6 - Форма обращения (заявки) типа «Инцидент» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуги по решению инцидентов, связанных с работой ППО, заполненную в свободной форме

4.3. Форма обращения (заявки) на оказание услуг по адаптационному конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) При подаче обращения (заявки) типа «ЗНИ» в СРО указывается (Таблица 7): Таблица 7 – Описание атрибутов формы обращения (заявки) на оказание услуг по адаптационному, конфигурационному и коррекционному сопровождению Системы Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 10) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 9) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 10) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 10) Категория обращения (заявки): запрос на изменение Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 7) Приоритет изменения Время, очередность решения обращения (заявки), ресурсы, привлекаемые для решения обращения (заявки), порядок/процедура действий при решении обращения (заявки) – поле СРО «Приоритет» (см. рисунок 7) Тип изменения Справочник, классифицирующий типовые запросы характерные для Системы – поле СРО «Предмет обращения» (см. рисунок 7) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 7) Текст запроса на оказание услуги по адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 7)

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

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

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

На рисунке 8 приведена форма обращения (заявки) типа «Инцидент» в СРО. Рисунок 8 - Форма обращения (заявки) типа «Инцидент» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуги по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности, заполненную в свободной форме

Приложение 1 к Регламенту Матрица ответственных за взаимодействия в рамках выполнения работ по техническому сопровождению Системы Таблица 1 – Ответственные за взаимодействия в рамках выполнения работ по техническому сопровождению Системы со стороны Исполнителя ФИО Должность Адрес электронной почты Телефон — — — Общий контакт

Приложение 2 к Регламенту Приоритеты и регламентные сроки решения обращений (заявок) Приоритеты и регламентные сроки решения обращений (заявок) приведены в таблице 1. Таблица 1 – Приоритеты и регламентные сроки решения обращений (заявок) № п/п Приоритет Максимальное время реагирования Время решения (срок выполнения) Описание приоритета

По информационно-консультационной поддержке сотрудников Заказчика и пользователей Системы 1 – не более 1 часа не более 10 часов –

По решению инцидентов, связанных с работой ППО 1 Критический не более 30 минут не более 4 часов – полная недоступность ППО; – недоступность ключевых функций; – ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО; – невозможность информационного обмена с ППО для ИС более 4 часов 2 Высокий не более 1 часа не более 8 часов – ошибки/сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; – снижение быстродействия СПО (время отклика ППО на операции превышает 30 секунд); – невозможность управления правами и ролями пользователей 3 Средний не более 4 часов не более 24 часов – невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым недоступность функции формирования отчетов 4 Низкий не более 8 часов не более 40 часов – отклонение в работе ППО, не влияющее на корректную работу функций; – другие сбои и ошибки, затрагивающие основные функции ППО

По адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) 1 Критический не более 40 минут не более 8 часов – изменения необходимые при проведении аварийно-восстановительных работ для возобновления работоспособности Системы; – изменения, связанные с критичными ошибками, блокирующими возможность оказания государственных услуг и/или чтение и внесение данных в Систему 2 Высокий не более 1 часа не более 40 часов – изменения относящиеся к обеспечению работоспособности основной функциональности Системы, устраняют выявленные дефекты в работе Системы, оказывающие существенное влияние на процесс оказания государственных услуг и работу пользователей в Системе; – изменения, затрагивающие три и более подсистемы/модуля Системы для адаптации 3 Средний не более 4 часов не более 72 часов – изменения, связанные с развитием/улучшением/оптимизацией Системы и выводом новой функциональности в штатном режиме для одного-двух модулей/подсистем; – изменения, связанные с развитием интеграционных механизмов Системы, например, обновление существующих и/или реализация новых видов сведений СМЭВ, обновление существующих и/или реализация новых API, адаптация и/или изменение механизмов импорта и экспорта данных Системы и т.д. 4 Низкий не более 8 часов не более 160 часов – изменения, связанные с ошибками/ корректировкой/изменение в отображении информации в пользовательском графическом интерфейсе Системы (графика, текст, органы управления, элементы интерфейса)

По устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности 1 Критический не более 30 минут не более 24 часов – критические уязвимости, влияющие на возможную полную недоступность ППО, ключевых функций Системы, ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО без возможности восстановления работоспособности Системы; – Критический уровень CVSS > 8.0 2 Высокий не более 1 часа не более 84 часов – критические уязвимости, влияющие на ошибки и сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; – Высокий уровень CVSS 5.0 - 8.0 3 Средний не более 4 часов не более 120 часов – уязвимости, влияющие на невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым; – Средний уровень CVSS 2.0 - 4.9 4 Низкий не более 8 часов не более 160 часов – уязвимости, влияющие на отклонение в работе ППО, не влияющее на корректную работу функций; – другие сбои и ошибки, затрагивающие основные функции ППО; – Низкий уровень CVSS < 2.0

Приложение Г Форма Отчета об оказанных услугах Отчет об оказанных услугах за этап «наименование этапа» в период с «__» _________ по «__» _________. № п/п Наименование услуги Общее количество Номер ОРС Краткое Описание Время реагирования по ТЗ Время реагирования фактическое Время решения по ТЗ Время решения фактическое Результат соблюдения времени реагирования Результат соблюдения времени решения Примечание 1 Услуги по информационно-консультационной поддержке работников Заказчика 2 546782 Консультация по работе Модуля СЦ 1 2 10 часов 11 часов Нет Нет 567123 Консультация по схеме БД 1 1 10 часов 1 час Да Да 2 … … Заказчик Подрядчик /Должность/ /Должность/ ____________________ /Ф.И.О/ ___________________ /Ф.И.О/ М.П. М.П. «_____»_______________________202_г. «_____»_______________________202_г

Приложение 1 к Отчету об оказанных услугах Журнал обращений (заявок) на оказание услуги по информационно-консультационной поддержке пользователей Системы (шаблон) Наименование Исполнителя в этапе «наименование этапа» в период с ________________ по _______________ оказал(о) Услугу по поддержке пользователей Системы в объеме, указанном в Таблице 1 Таблица 1 - Журнал обращений (заявок) пользователей Системы № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. ИТОГО зарегистрировано: Всего обращений (заявок): ________ ИТОГО решено: Всего обращений (заявок): ________

Приложение 2 к Отчету об оказанных услугах Журнал обращений (заявок) по решению инцидентов, связанных с работой ППО (шаблон) Наименование Исполнителя в этапе «наименование этапа» в период с ________________ по _______________ оказал(о) Услугу по решению инцидентов в объеме, указанном в Таблице 1. Таблица 1 - Журнал по решению инцидентов № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. ИТОГО зарегистрировано: Всего инцидентов: ________ ИТОГО решено: Всего инцидентов: ________

Приложение 3 к Отчету об оказанных услугах Журнал обращений (заявок) выполнения адаптационного, конфигурационного и коррекционного сопровождения Системы (шаблон) Журнал выполнения адаптации, конфигурации и коррекции Системы сформирован за этап «наименование этапа» в период с «__» _________ по «__» ____________ и представлен в таблице ниже (Таблица 1). Таблица 1 - Журнал выполнения адаптации, конфигурации и коррекции сопровождения Системы № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. Количество выполненных заявок за этап: ________

Приложение 4 к Отчету об оказанных услугах Журнал обращений (заявок) по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности (шаблон) Журнал обращений (заявок) по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности сформирован за этап «наименование этапа» в период с «__» _________ по «__» ____________ и представлен в таблице ниже (Таблица 1). Таблица 1 - Журнал выполнения заявок по устранению уязвимостей в ППО № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. Количество выполненных заявок за этап: ________

Приложение Д Форма Протокола проверки результатов организационно-штатных и подготовительных мероприятий (шаблон) Протокол проверки результатов организационно-штатных и подготовительных мероприятий Настоящий Протокол содержит результаты проверки организационно-штатных и подготовительных мероприятий, проведенных Исполнителем (Таблица Д.1). Таблица Д.1. Протокол проверки результатов № Мероприятия Подготовительного этапа Результат проверки 1. Определить и направить Заказчику документ «Ответственные за взаимодействия в рамках выполнения работ по техническому сопровождению Системы со стороны Исполнителя». Документ содержит контактную информацию (ФИО, должность, адрес электронной рабочей почты, номер телефона) не менее чем о 2 лицах, ответственных за оказание услуг со стороны Подрядчика Выполнено/Не выполнено 2. Обеспечить подключение специалистов Подрядчика к Системе Выполнено/Не выполнено 3. Обеспечить подключение специалистов Подрядчика к СРО Выполнено/Не выполнено Заказчик Подрядчик /Должность/ /Должность/ ____________________ /Ф.И.О/ ___________________ /Ф.И.О/ М.П. М.П. «_____»_______________________202_г. «_____»_______________________202_г

- 62.01.11.000 - Этап№9: Приемочные испытания ОКПД2: 62.01.11.000 ОПРЕДЕЛЕНИЯ, ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ Автоматизированная система (АС) Система, состоящая из комплекса средств автоматизации, реализующего информационную технологию выполнения установленных функций, и персонала, обеспечивающего его функционирование (ГОСТ Р 59853-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения») АРМ Автоматизированное рабочее место АСУ ТК, Система Информационно-аналитическая система регулирования на транспорте АТС Автоматическая телефонная станция БД База данных ГИС Государственная информационная система ГОСТ Государственный стандарт ГЦОД СИЦ Минтранса России, ГЦОД Головной центр обработки данных ФГБУ «СИЦ Минтранса России» Дашборд Интерактивная аналитическая панель, графический интерфейс. ЕИС Единая информационная система в сфере закупок ЕСИА Единая система идентификации и аутентификации Заказчик Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» КИИ Критическая информационная инфраструктура Кластер Кла?стер (англ. cluster) – объединение нескольких однородных элементов, которое может рассматриваться как самостоятельная единица, обладающая определёнными свойствами Компонент Часть АС, выделенная по определенному признаку или совокупности признаков и рассматриваемая как единое целое (ГОСТ Р 59853-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения») Контракт Контракт на выполнение работ по развитию и оказанию услуг по технической поддержке Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК в 2026 году, заключаемый по результатам проведения конкурентной процедуры закупки в соответствии с требованиями Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» ... 1. ОБЩИЕ СВЕДЕНИЯ 1.2. Шифр темы или номер контракта Присваивается Заказчиком по результатам организации закупочных процедур. 1.2.1. Предмет контракта Выполнение работ по развитию Модуля СЦ. Код по ОКПД2: 62.01.11.000 – услуги по проектированию и разработке информационных технологий для прикладных задач и тестированию программного обеспечения. Оказание услуг по технической поддержке Модуля СЦ. Код по ОКПД2: 62.02.30.000 – услуги по технической поддержке информационных технологий. Выполнение работ по развитию Модуля СЦ предусмотрено с учетом ключевых результатов (ОКР) Ведомственной программы цифровой трансформации Минтранса России на 2026-2028 (далее - ВПЦТ Минтранса России) в составе мероприятия № 103.002 «АСУ ТК» ИТ расхода 103.26.000005 «Развитие Информационно-аналитической системы регулирования на транспорте (АСУ ТК)»: · «Обеспечено информационное взаимодействие с Минобороны о происшествиях на транспортных объектах»; · «Обеспечена автоматизация формирования отчетов о нештатных ситуациях на транспорте, в том числе по данным внешних систем». Выполнение работ по технической поддержке АСУ ТК предусмотрено ВПЦТ Минтранса России в составе мероприятия № 103.002 «АСУ ТК» ИТ расхода 103.26.000021 «Эксплуатация Информационно-аналитической системы регулирования на транспорте (АСУ ТК)» ... 2. ЦЕЛИ И НАЗНАЧЕНИЕ ВЫПОЛНЕНИЯ РАБОТ 2.1. Назначение АСУ ТК АСУ ТК предназначена для автоматизации и информационно-аналитического обеспечения процессов управления развитием транспортного комплекса Российской Федерации, обеспечения публичности деятельности органов государственного управления транспортным комплексом. Основными целями АСУ ТК являются: – повышение эффективности процессов управления функционированием и развитием транспортного комплекса на основе создания единой информационной среды и комплекса информационно-аналитических услуг на уровне органов государственного управления ТК; – повышение уровня безопасности ТК на базе получения полной, достоверной и оперативной информации о происходящих изменениях, своевременного выявления негативных тенденций и для принятия соответствующих мер по их устранению и ликвидации последствий ... - Условная единица - 1,00 - 3 617 680,03 - 3 617 680,03

- Наименование характеристики Значение характеристики Единица измерения характеристики Инструкция по заполнению характеристик в заявке ОПРЕДЕЛЕНИЯ, ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ Автоматизированная система (АС) Система, состоящая из комплекса средств автоматизации, реализующего информационную технологию выполнения установленных функций, и персонала, обеспечивающего его функционирование (ГОСТ Р 59853-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения») АРМ Автоматизированное рабочее место АСУ ТК, Система Информационно-аналитическая система регулирования на транспорте АТС Автоматическая телефонная станция БД База данных ГИС Государственная информационная система ГОСТ Государственный стандарт ГЦОД СИЦ Минтранса России, ГЦОД Головной центр обработки данных ФГБУ «СИЦ Минтранса России» Дашборд Интерактивная аналитическая панель, графический интерфейс. ЕИС Единая информационная система в сфере закупок ЕСИА Единая система идентификации и аутентификации Заказчик Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» КИИ Критическая информационная инфраструктура Кластер Кла?стер (англ. cluster) – объединение нескольких однородных элементов, которое может рассматриваться как самостоятельная единица, обладающая определёнными свойствами Компонент Часть АС, выделенная по определенному признаку или совокупности признаков и рассматриваемая как единое целое (ГОСТ Р 59853-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения») Контракт Контракт на выполнение работ по развитию и оказанию услуг по технической поддержке Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК в 2026 году, заключаемый по результатам проведения конкурентной процедуры закупки в соответствии с требованиями Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» Значение характеристики не может изменяться участником закупки Модуль iМинтранс Модуль сбора данных и представления показателей деятельности Министерства транспорта Российской Федерации iМинтранс АСУ ТК Модуль СЦ Модуль сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК НС Нештатная ситуация НСИ Нормативно-справочная информация ОТИ Объект транспортной инфраструктуры П-ГИС Геоинформационная подсистема П-ИВ Подсистема информационного взаимодействия П-НСИ Подсистема ведения нормативно-справочной информации и метаданных ПО Программное обеспечение Подрядчик, Исполнитель Организация, с которой будет заключен контракт на выполнение работ по развитию Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК П-СД Подсистема сбора данных Работы Работы по развитию Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК СЗИ Средство защиты информации СМЭВ Система межведомственного электронного взаимодействия СУБД Система управления базами данных ТЗ Техническое задание (настоящий документ) ТС Транспортное средство ТК Транспортный комплекс Учреждение Учреждения в области информационной безопасности ФГБУ «СИЦ Минтранса России» Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации», Заказчик Федеральный закон № 44-ФЗ Федеральный закон от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» ФЗ Функциональная задача ФЗ «Реестр объектов» Функциональная задача «Формирование и ведение единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации» ФСБ России Федеральная служба безопасности Российской Федерации ФСТЭК России Федеральная служба по техническому и экспортному контролю ЧС Чрезвычайная ситуация ЭВМ Электронно-вычислительная машина API От англ. Application Programming Interface – интерфейс прикладного программирования – совокупность инструментов и функций в виде интерфейса для взаимодействия с программой CSS От англ. Cascading Style Sheets — каскадные таблицы стилей FPS От англ. frame per second - количество кадров в секунду HTML От англ. HyperText Markup Language - стандартный язык разметки документов, создающий основу и структуру всех веб-страниц JSON От англ. JavaScript Object Notation – текстовый формат обмена данными, основанный на JavaScript WebAssembly (Wasm) Открытый стандарт, представляющий собой низкоуровневый бинарный формат инструкций, который позволяет выполнять код, написанный на языках C++, Rust или Go, в браузерах с производительностью, близкой к нативной 1. ОБЩИЕ СВЕДЕНИЯ 1.2. Шифр темы или номер контракта Присваивается Заказчиком по результатам организации закупочных процедур. 1.2.1. Предмет контракта Выполнение работ по развитию Модуля СЦ. Код по ОКПД2: 62.01.11.000 – услуги по проектированию и разработке информационных технологий для прикладных задач и тестированию программного обеспечения. Оказание услуг по технической поддержке Модуля СЦ. Код по ОКПД2: 62.02.30.000 – услуги по технической поддержке информационных технологий. Выполнение работ по развитию Модуля СЦ предусмотрено с учетом ключевых результатов (ОКР) Ведомственной программы цифровой трансформации Минтранса России на 2026-2028 (далее - ВПЦТ Минтранса России) в составе мероприятия № 103.002 «АСУ ТК» ИТ расхода 103.26.000005 «Развитие Информационно-аналитической системы регулирования на транспорте (АСУ ТК)»: · «Обеспечено информационное взаимодействие с Минобороны о происшествиях на транспортных объектах»; · «Обеспечена автоматизация формирования отчетов о нештатных ситуациях на транспорте, в том числе по данным внешних систем». Выполнение работ по технической поддержке АСУ ТК предусмотрено ВПЦТ Минтранса России в составе мероприятия № 103.002 «АСУ ТК» ИТ расхода 103.26.000021 «Эксплуатация Информационно-аналитической системы регулирования на транспорте (АСУ ТК)» Значение характеристики не может изменяться участником закупки 1.3. Заказчик Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» (ФГБУ «СИЦ Минтранса России»). Адрес: 107078, Москва, Садовая-Спасская ул., д.18, стр. 1. Оператором Системы является Заказчик - Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» (ФГБУ «СИЦ Минтранса России) 1.4. Подрядчик Определяется по результатам проведения конкурентной процедуры закупки в соответствии с требованиями Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (далее – Федеральный закон № 44-ФЗ) 1.5. Основания для выполнения работ Работы осуществляются на основании следующих документов: – постановление Правительства Российской Федерации от 30.12.2003 № 794 «О единой государственной системе предупреждения и ликвидации чрезвычайных ситуаций»; – постановление Правительства Российской Федерации от 08.11.2013 № 1007 «О силах и средствах единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций»; – распоряжение Правительства Российской Федерации от 27.11.2021 № 3363-р «О Транспортной стратегии Российской Федерации до 2030 года с прогнозом на период до 2035 года»; – Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 26.08.2025 №ЕФ-3; – Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 27.11.2025 №ЕФ-23; – Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 19.02.2026 №ЕФ-1; – План мероприятий по профилактике случаев непроизводственного травматизма граждан на железнодорожном транспорте, являющийся приложением к постановлению коллегии Министерства транспорта Российской Федерации от 11.03.2026 № 2 1.6. Перечень документов, требования которых должны быть учтены при выполнении работ – Федеральный закон Российской Федерации от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации»; – Федеральный закон Российской Федерации от 27.07.2006 № 152-ФЗ «О персональных данных»; – Федеральный закон Российской Федерации от 06.04.2011 № 63-ФЗ «Об электронной подписи»; – Федеральный закон Российской Федерации от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации»; – Указ Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации»; – Указ Президента Российской Федерации от 01.05.2022 № 250 «О дополнительных мерах по обеспечению информационной безопасности Российской Федерации»; – Указ Президента Российской Федерации от 31.03.2010 № 403 «О создании комплексной системы обеспечения безопасности населения на транспорте»; – постановление Правительства Российской Федерации от 30.07.2004 № 395 «Об утверждении Положения о Министерстве транспорта Российской Федерации»; – постановление Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации»; – постановление Правительства Российской Федерации от 16.11.2015 № 1236 «Об установлении запрета на допуск программного обеспечения, происходящего из иностранных государств, для целей осуществления закупок для обеспечения государственных и муниципальных нужд»; – постановление Правительства Российской Федерации от 23.12.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 Федерального закона «Об электронной подписи»; – постановление Правительства Российской Федерации от 08.06.2011 № 451 «Об инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг и исполнения государственных и муниципальных функций в электронной форме»; – постановление Правительства Российской Федерации от 30.01.2013 № 62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин»; – приказ ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации»; – приказ ФСТЭК России от 11.04.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений»; – приказ ФСБ России от 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.7. Сроки начала и окончания работ Начало работ: с даты заключения Контракта. Окончание работ: не позднее 15.12.2026. Работы выполняются в соответствии с этапами. Сроки выполнения этапов работ по развитию и технической поддержке Модуля СЦ определяются Календарным планом. Календарный план, приведен в разделе 5 настоящего ТЗ 1.8. Общие сведения об источниках и порядке финансирования работ Источником финансирования являются средства субсидии федерального бюджета Российской Федерации, предоставленной в соответствии с абзацем вторым пункта 1 статьи 78.1 Бюджетного кодекса Российской Федерации (код цели 08-01) 1.9. Порядок оформления и предъявления результатов работ Подрядчик должен передать Заказчику результаты работ в порядке, определенном Контрактом в сроки, установленные п. 5 настоящего ТЗ, в соответствии с Календарным планом 1.10. Место выполнения Работ Работы выполняются удаленно на комплексе технических средств Заказчика. Адрес размещения комплекса технических средств Заказчика: Московская обл., Богородский район, пос. Горбуша, Радиоцентр. Техническая возможность удаленного подключения обеспечивается Заказчиком (в части предоставления параметров доступа). Оплата телематических и иных услуг, технических и программных средств, необходимых Подрядчику для удаленного подключения и для выполнения требований по информационной безопасности, осуществляется Подрядчиком самостоятельно за свой счет 1.1. Наименование Системы Полное наименование системы: Информационно-аналитическая система регулирования на транспорте. Условное обозначение системы: АСУ ТК. Полное наименование модуля: Модуль сбора, ведения и анализа информации о нештатных ситуациях на транспорте. Условное обозначение модуля: Модуль СЦ. Модуль СЦ создан в рамках контракта от 05.08.2024 № ОК/24_04 на выполнение работ по развитию АСУ ТК в части создания модуля «Сбора, ведения и анализа информации о нештатных ситуациях на транспорте». Развитие Модуля СЦ осуществлено в рамках контракта от 19.05.2025 № ОК/25_09 на выполнение работ по развитию Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК 2. ЦЕЛИ И НАЗНАЧЕНИЕ ВЫПОЛНЕНИЯ РАБОТ 2.1. Назначение АСУ ТК АСУ ТК предназначена для автоматизации и информационно-аналитического обеспечения процессов управления развитием транспортного комплекса Российской Федерации, обеспечения публичности деятельности органов государственного управления транспортным комплексом. Основными целями АСУ ТК являются: – повышение эффективности процессов управления функционированием и развитием транспортного комплекса на основе создания единой информационной среды и комплекса информационно-аналитических услуг на уровне органов государственного управления ТК; – повышение уровня безопасности ТК на базе получения полной, достоверной и оперативной информации о происходящих изменениях, своевременного выявления негативных тенденций и для принятия соответствующих мер по их устранению и ликвидации последствий Значение характеристики не может изменяться участником закупки Основными задачами АСУ ТК являются: – автоматизация процессов прогнозирования развития транспортного комплекса и поддержки принятия управленческих решений; – автоматизация процессов мониторинга безопасности и устойчивости транспортного комплекса, управления в чрезвычайных и нештатных ситуациях; – автоматизация процессов управления программами и проектами развития и модернизации транспортного комплекса; – автоматизация процессов мониторинга состояния транспортного комплекса, в том числе с использованием набора ключевых показателей эффективности деятельности транспортного комплекса; – информационно-технологическая поддержка взаимодействия субъектов транспортного комплекса Российской Федерации, органов государственного управления и контроля, международных организаций на основе создания единой технологической среды взаимодействия и управления движением данных (и связанных с ними документов) в транспортном комплексе; – использование в процессах управления транспортным комплексом РФ современных технологий электронного документооборота и электронного обмена данными; – организация межведомственного электронного взаимодействия подразделений Министерства транспорта Российской Федерации, подведомственных агентств и службы с другими организациями 2.2. Назначение и цели развития и технической поддержки Модуля СЦ Назначение Модуля СЦ: – оперативный мониторинг нештатных и чрезвычайных ситуаций на транспорте ; – оповещение заинтересованных лиц и структур о нештатных и чрезвычайных ситуациях; – сбор, обработка и хранение данных о нештатных и чрезвычайных ситуациях. Целями развития Модуля СЦ являются: – расширение состава данных об оперативной обстановке на транспорте; – оптимизация процесса сбора данных об оперативной обстановке на транспорте; – повышение информированности пользователей за счет визуализация данных Модуля СЦ; – автоматизация процесса формирования отчетов о ЧС и нештатной ситуации на транспорте; – обеспечение информационного взаимодействия с заинтересованными организациями по вопросам ведения. Целями оказания услуг по технической поддержке являются: – обеспечение информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы; – поддержание параметров функционирования ППО Системы, удовлетворяющих требованиям производственных процессов, включая их непрерывность; – обеспечение бесперебойного функционирования ППО и своевременное устранение сбоев и аварийных ситуаций в Системе; – своевременное устранение уязвимостей при выявлении таковых, в соответствии с требованиями к обеспечению информационной безопасности; – адаптация, конфигурирование, коррекция программного обеспечения в соответствии с изменениями нормативно-правовой базы и запросами уполномоченных сотрудников органов государственной власти, включая выполнение процедур тестирования и участие в обновлениях ППО на стендах Заказчика; – обеспечение сохранения работоспособности ППО в изменяемой среде эксплуатации; – ведение документации по настоящему ТЗ, инициирование и актуализация документации на Систему по результатам обработки запросов Заказчика и внесении соответствующих изменений в ППО. Модуль СЦ применяется в деятельности Министерства транспорта Российской Федерации, подведомственных агентств и службы и другими организациями в соответствии с соглашениями об информационном обмене 3. ХАРАКТЕРИСТИКА ОБЪЕКТА АВТОМАТИЗАЦИИ 3.1. Описание объекта автоматизации АСУ ТК Объектом автоматизации являются процессы основной и обеспечивающей деятельности, направленные на управление транспортным комплексом, в том числе, процессы информационного взаимодействия с другими организациями и субъектами транспортного комплекса. АСУ ТК относится к государственным информационным системам, а также к информационным системам персональных данных и значимым объектам критической информационной инфраструктуры Российской Федерации. АСУ ТК соответствует требованиям, предъявляемым к: – ГИС второго класса защищенности в соответствии с приказом ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах»; – ИС персональных данных при обеспечении третьего уровня защищенности персональных данных в соответствии с требованиями постановления Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»; – значимым объектам КИИ Российской Федерации второй категории значимости с постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении Правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений». Модуль СЦ является подсистемой АСУ ТК. Перечень платформенных решений и функциональных задач АСУ ТК представлен в Таблице 1 Значение характеристики не может изменяться участником закупки Таблица 1 – Перечень платформенных решений и функциональных задач АСУ ТК № Наименование подсистемы/ функциональной задачи/ модуля Назначение 1 Подсистема сбора данных и централизованного хранилища данных Подсистема обеспечивает выполнение сбора данных в АСУ ТК, и в т. ч., в рамках функциональных задач «Формирование и ведение межрегионального транспортного баланса пассажирских перевозок в дальнем (межрегиональном) сообщении» и «Формирование и ведение транспортного паспорта региона» 2 Подсистема информационного взаимодействия Подсистема информационного предназначена для обеспечения информационного взаимодействия подсистем АСУ ТК, а также, взаимодействия АСУ ТК с АС федеральных органов исполнительной власти 3 Подсистема ведения нормативно-справочной информации и метаданных Подсистема предназначена для автоматизации функций формирования и актуализации справочников, классификаторов, реестров и регистров, необходимых для обеспечения информационной поддержки пользователей НСИ и интеграции подсистем АСУ ТК в части применения НСИ 4 Модуль СМЭВ Модуль взаимодействия со СМЭВ представляет собой набор сервисов взаимодействия: сервис синхронного взаимодействия и сервис отправки, осуществляющих дополнительную обработку сообщений, отправляемых в СМЭВ и принимаемых из СМЭВ 5 Геоинформационная подсистема Программное обеспечение геоинформационной подсистемы предназначено для обеспечения смежных подсистем АСУ ТК возможностью работы с картографической информацией, в том числе, отображения на электронных картах объектов транспортной инфраструктуры и получения информации о местоположении, характеристиках контролируемых транспортных объектов 6 Подсистема информационного портала АСУ ТК Подсистема информационного портала предназначена для отображения и входа в функциональные задачи АСУ ТК 7 Подсистема технического портала АСУ ТК Подсистема технического портала АСУ ТК предназначена для управления заявками пользователей и технологического документооборота заявок 8 Подсистема проектного архива АСУ ТК Подсистема проектного архива АСУ ТК предназначена для автоматизации деловых процессов должностных лиц Министерства транспорта Российской Федерации, подведомственных агентств и службы, в том числе, и процессов информационного взаимодействия внутреннего и внешнего характера 9 ФЗ «Реестр объектов» Функциональная задача предназначена для формирования и ведения единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации 10 ФЗ «СТП» Функциональная задача предназначена для организации информационно-аналитической поддержки процессов территориального планирования Российской Федерации в области федерального транспорта 11 ФЗ «МРТБ ПП» Функциональная задача предназначена для формирования и ведения межрегионального транспортного баланса пассажирских перевозок в дальнем (межрегиональном) сообщении 12 ФЗ «МДД» Функциональная задача предназначена для осуществления мониторинга дорожного движения 13 ФЗ «ТПР» Функциональная задача предназначена для формирования и ведения транспортного паспорта региона 14 ФЗ «Данные по грузообороту» Функциональная задача предназначена для обеспечения подсистем и пользователей АСУ ТК данными по грузообороту между Российской Федерацией и зарубежными странами 15 ФЗ «МЖТ» Функциональная задача предназначена для осуществления мониторинга железнодорожного транспорта 16 ФЗ «МГМП» Функциональная задача предназначена для осуществления мониторинга грузопотоков в морских портах с целью формирования единой цифровой среды мониторинга и планирования перевозок в/из портов Дальнего Востока 17 Модуль ГЭТ Модуль предназначен для получения, хранения данных инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по отдельно взятому предприятию-перевозчику. Формирования отчетов об инвентаризации с детальными данными по каждому разделу инвентаризации с маршрутизацией в муниципалитет / регион / Минтранс. Содержит агрегированные данные инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по всем перевозчикам, относящихся к данному муниципалитету. Формирует сводный отчет по муниципалитету по каждому разделу инвентаризации с маршрутизацией в регион / Минтранс. Формирует агрегированные данные инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по всем перевозчикам, относящиеся к данному региону и по всем муниципалитетам, относящимся к данному региону. Аналитические и статистические данные о состоянии ГЭТ региона. Содержит данные о видах транспорта, цифровых транспортных сервисах и платежных инструментах Региона. Формирует сводный отчет по каждому разделу инвентаризации с маршрутизацией в Минтранс. Формирует агрегированную статистику и аналитику по всем регионам страны в разрезе транспортных средств, маршрутов, пассажиропотоков, инфраструктуры ГЭТ. Данные о рейтинге регионов и перевозчиков на основании выбранных параметров, документооборот с участниками Системы: получение подписанных печатных форм, их утверждение, возврат на доработку. 18 Модуль iМинтранс Модуль создан для отчета по ключевым показателям транспортного комплекса России (Отраслевые и статистические показатели, исполнение бюджета, исполнение поручений, аналитика СМИ, происшествия по видам транспорта). 19 Модуль СЦ Модуль СЦ предназначен для оперативного мониторинга нештатных ситуаций транспортной отрасли, оповещения заинтересованных лиц и структур и предоставления данных о нештатных ситуациях АСУ ТК осуществляет идентификацию и авторизацию посредством Единой системы идентификации и аутентификации (ЕСИА). Информационный обмен с внешними информационными системами осуществляется посредством СМЭВ 3 и СМЭВ 4. АСУ ТК развернута на вычислительных мощностях ГЦОД СИЦ Минтранса России 3.2. Описание и текущее состояние объекта автоматизации Модуля СЦ Объектом автоматизации является процесс организации мониторинга информации о НС и ЧС на транспорте. Предметом деятельности Учреждения являются следующие функции: – информационное обеспечение в области транспортной безопасности, защиты населения и территорий от чрезвычайных ситуаций природного и техногенного характера в транспортном комплексе; – подготовка справочных материалов при угрозе возникновения и возникновении чрезвычайных ситуаций и иных происшествий в транспортном комплексе; – взаимодействие и обмен оперативной информацией с органами управления Единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций; – организация оперативного мониторинга обстановки на объектах транспорта при угрозе и возникновении чрезвычайных ситуаций и иных происшествий. Перечень компонентов Модуля СЦ и выполняемые ими функции представлены в Таблице 2 Таблица 2. Перечень компонентов Модуля СЦ и их функции № п/п Компонент Выполняемые функции 1 Регистрация событий – ведение карточки события; – удаление комментария; – динамическое отображение существующих событий в заданном радиусе и за заданный период; – возможность автоматической проверки вводимых данных в части количества пострадавших; – отображение карточки ОТИ, ТС в соответствии с ФЗ Реестр объектов; – сохранение и отображение версии карточки события; – привязка события к координатам по картографической основе; – указание признака выполнения действия по отработке события; – перевод статуса события; – закрытие карточки события; – публикация информации о событии в канале мессенджера; – возможность перехода из карточки события на картографическую основу для просмотра местоположения события 2 Визуализация – отображение событий на картографической основе в виде пиктограмм; – масштабирование карты; – отображение краткой карточки события при выборе события на картографической основе; – отображение списка событий; – отображение карточки события; – отображение журнала действий пользователя; – отображение дополнительной информации (текстовая информация и приложенные файлы); – отображение справки о событиях и отчета о событиях; – отображение фильтров и количества отфильтрованных объектов; – отображение результатов поиска; – отображение статистики по событиям на экране; – возможность создания события с картографической основы; – отображения картографических слоев в зависимости от примененных фильтров; – возможность настройки шага картографической сети; – возможность настройки географической точки центра карты; – отображение количества непрочитанных сообщений; – возможность перехода к детальной карточке события из краткой карточки события при выборе события на картографической основе 3 Информирование – ведение справочника способов оповещения (веб-интерфейс, мессенджер); – формирование сценария выполнения оповещения (настройка условий, способа, параметров оповещения); – выполнение оповещений пользователей 4 Отчетность – формирование отчета и справки о событиях; – фильтрация событий для выгрузки в справку о событиях или в отчет о событиях 5 Администрирование – ведение ролей пользователей; – ведение учетных данных пользователей; – ведение справочника организаций; – ведение справочника групп системы мгновенного обмена сообщениями; – выполнение исходящего звонка на контактный телефонный номер организации; – формирование матрицы эскалации событий Архитектура Модуля СЦ представлена на рисунке 1. Рисунок 1. Архитектура Модуля СЦ 3.3. Состав используемого ПО Модуля СЦ Программная архитектура Модуля СЦ разработана как трехуровневая клиент-серверная архитектура. Архитектура включает в себя следующие уровни: • уровень представления – презентационный уровень, обеспечивающий взаимодействие с пользователя с клиентскими приложениями с использованием веб-браузера («тонкий» клиент); • уровень приложений – реализован в виде сервисов, обеспечивает обработку запросов, поступающих от клиентских приложений, формирование ответов на запрос в доступном пользователю виде (формирование пользовательских интерфейсов); • уровень хранения данных – реализуется как сервер БД и обеспечивает хранение и целостность хранимых данных, создание резервных копий, ведение журнала транзакций, восстановление данных после сбоев. Программная архитектура Модуля СЦ включает в себя сервисы и интерфейсы, указанные в Таблице 3. Таблица 3. Программная архитектура Модуля СЦ Программный сервис/интерфейс Технологии реализации Уровень представления Интерфейс пользователя и администратора (front-end) Javascript Уровень приложений Сервис (GateWay) Kotlin Сервис геокодирования (geocoding-service) Kotlin Сервис уведомлений (notifiсation-service) Kotlin Сервис работы с файлами (file-service) Kotlin Сервис отчетности (report-service) Kotlin Сервис управления событиями (event-service) Kotlin Сервис информирования через мессенджер (messenger-notifier) Python Сервис внешних интеграций (integration-service) Сбор информации из внешних систем и сервисов Брокер сообщений Kafka Уровень хранения данных Файловое хранилище MinIO S3 СУБД Postgres Pro Enterprise 3.4. Информационное взаимодействие программных сервисов и интерфейсов Модуля СЦ Объект автоматизации функционирует в распределенной информационной среде. Обмен данными осуществляется по защищенным каналам связи (в том числе ведомственным сетям передачи данных). Источники информации включают: · внешние автоматизированные системы (органов государственной власти); · внутренние базы данных (реестры объектов транспортной инфраструктуры, паспорта регионов и пр.); · оперативная информация от персонала, поступающая через автоматизированные рабочие места (АРМ) и мобильные устройства. 3.4.1. Взаимодействие Модуля СЦ со смежными подсистемами АСУ ТК Модуль СЦ входит в состав АСУ ТК и взаимодействует со следующими ее функциональными задачами и подсистемами: · Функциональной задачей «Формирование и ведение единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации» (ФЗ «Реестр объектов»); · Геоинформационной подсистемой АСУ ТК (П-ГИС); · Подсистемой ведения нормативно-справочной информации и метаданных (П-НСИ); · Подсистемой сбора данных и централизованное хранилище данных (П-СД); · Подсистемой информационного взаимодействия (П-ИВ). 3.4.2. Взаимодействие с внешними информационными системами Список внешних информационных систем, с которыми осуществляется взаимодействие Модуля СЦ: · ЕСИА; · мессенджер; · Яндекс Геокодер; · Информационная система «Централизованная система сбора информации систем-112»; · ПВК «Поиск-Море», АИС РПТ; · облачная АТС 3.5. Требования к эксплуатации Применяемое в Системе программное обеспечение, программно-аппаратные и аппаратные комплексы должны соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации» 4. ТРЕБОВАНИЯ К МОДУЛЮ СЦ 4.3.1.2. Требования к общему порядку оказания услуг Техническая поддержка Модуля СЦ должна быть организована на трех уровнях: – первый и второй уровни технической поддержки организуется Заказчиком; – третий уровень технической поддержки организуется Подрядчиком. Перечень действий на каждом уровне технической поддержки указан в Таблице 5: Таблица 5 – Перечень действий на каждом уровне технической поддержки Уровень технической поддержки Доступные действия Условия передачи задачи на следующий уровень Первый уровень технической поддержки (далее – 1-й уровень) – принимает обращения (заявки) пользователей Модуля СЦ и работников Заказчика; – регистрирует обращения в Модуле СЦ регистрации обращений; – присваивает уникальный идентификационный номер, классифицирует обращения; – самостоятельно решает обращения, которые связаны с недостаточной квалификацией пользователей или настройками в рамках своей компетенции; – взаимодействует с пользователями Модуля СЦ при решении проблемы Передает обращение на второй уровень поддержки в случае невозможности решения на своем уровне Второй уровень технической поддержки (далее – 2-й уровень) – принимает обращения от 1-го уровня; – уточняет классификацию обращения в результате дополнительного анализа; – самостоятельно решает обращения в рамках своей компетенции; – осуществляет техническую и консультационную поддержку Модуля СЦ; – взаимодействует с сотрудниками 1-го и 3-го уровня и пользователями Модуля СЦ; – формирует заявки для 3-го уровня и контролирует исполнение Передает обращение на третий уровень поддержки в случае невозможности решения на своем уровне Третий уровень технической поддержки (далее – 3-й уровень) – принимает обращения от 2-го уровня; – обеспечивает выполнение требований, предъявляемых Контрактом и настоящим Техническим заданием к Услугам, оказываемым Подрядчиком Все поступающие обращения должны быть исполнены Подрядчиком Значение характеристики не может изменяться участником закупки Для обеспечения взаимодействия с Заказчиком Подрядчик со своей стороны определяет ответственных лиц, уполномоченных в структуре Подрядчика за своевременное и качественное оказание Услуг в рамках настоящего ТЗ, а также контактную информацию ответственных лиц (телефон, электронную почту). Подрядчик должен предоставить Заказчику единый адрес электронной почты для приема обращений (заявок) в течение 3 (трех) рабочих дней после заключения Контракта. Указанный в настоящем пункте адрес электронной почты (способ направления обращений (заявок) применяется в случае сбоя в работе СРО Заказчика. Со своей стороны, Заказчик предоставляет Подрядчику перечень и контактную информацию (телефон, электронную почту) уполномоченных лиц для осуществления взаимодействия с указанием зон ответственности. О любых изменениях в контактной информации ответственных лиц Стороны должны уведомить друг друга в течение 1 (одного) рабочего дня с момента возникновения таких изменений посредством уведомления на электронную почту ответственных лиц и/или в письменной форме. В результате оказания услуг по настоящему ТЗ не должны быть изменены исходные коды, дистрибутивы и иные компоненты Модуля СЦ вне согласованных с Заказчиком изменений. Любые изменения исходных кодов, дистрибутивов и иных компонентов Модуля СЦ должны производиться только после согласования с Заказчиком уполномоченными лицами по электронной почте или иным заранее согласованным способом. Не должна быть ухудшена надежность и производительность Модуля СЦ. Оказание услуг по Контракту не должно нарушать требования к информационной безопасности, описанной в документации на Модуль СЦ – выполнение требований по обеспечению в автоматизированном режиме с Национальной системой противодействия DDoS-атакам (НСПА) Центра мониторинга и управления сетью связи общего пользования ФГУП «ГРЧЦ» в рамках реализации мер по защите ГИС от атак, направленных на отказ в обслуживании; – детализированные требования к составу и содержанию работ по аттестации, а также к их результатам в соответствии с пунктами 13, 15 и 16 требований приказа ФСТЭК России от 29.04.2021 № 77 «Об утверждении Порядка организации и проведения работ по аттестации объектов информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну» 4.5.5.1. Требования к безопасности исходного кода Процесс разработки исходного кода должен соответствовать требованиям законодательства, нормативным правовым актам Российской Федерации, приказу ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по безопасности значимых объектов критической информационной инфраструктуры Российской Федерации», а также учитывать отраслевые практики безопасной разработки. Подрядчик должен предоставить Заказчику Руководство по безопасной разработке программного обеспечения (далее – Руководство), применяемое при разработке исходного кода Модуля СЦ. Руководство должно содержать: · описание процесса безопасной разработки и ролевой модели, отражающей зоны ответственности сотрудников Подрядчика; · описание процессов моделирования, оценки и формирования мер предотвращения угроз, применяемых Подрядчиком; · описание методик, применяемых Подрядчиком при разработке исходного кода (правила написания кода); · описание методик, периодичности проведения и инструментария статического, динамического, композитного и фаззинг тестирования исходного кода, включающего критерии отбора релизных версий ПО, применяемые Подрядчиком в процессе разработки; · описание механизмов безопасности в процессе сборки и доставки (безопасность образов, безопасность секретов, безопасность окружения и сборочной среды), применяемые Подрядчиком; · утвержденные шаблоны отчетной документации (в том числе акты), в соответствии с которыми Заказчик принимает результаты проверок (артефакты сборочного процесса), проведенных Подрядчиком; · описание процедур отслеживания и исправления обнаруженных ошибок и уязвимостей программного обеспечения; · описание способов и сроков доведения Подрядчиком до Заказчика информации об уязвимостях программного обеспечения, о компенсирующих мерах по защите информации или ограничениях по применению программного обеспечения, способов получения пользователями программного обеспечения его обновлений, проверки их целостности и подлинности Подрядчик должен обеспечить реализацию и проведение внутренних проверок мер по разработке безопасного ПО, приведенных в Руководстве. Подрядчик должен провести анализ угроз безопасности информации программного обеспечения в соответствии с ГОСТ 58412-2019 «Защита информации. Разработка безопасного программного обеспечения. Угрозы безопасности информации при разработке программного обеспечения». Подрядчик должен провести испытания по выявлению уязвимостей в программном обеспечении Системы: · проведение статического анализа исходного кода программы; · проведение динамического анализа исходного кода программы; · проведение композитного анализа исходного кода и образов программы; · проведение фаззинг-тестирования программы, направленного на выявление в ней уязвимостей. Испытания по выявлению уязвимостей в программном обеспечении Системы должны быть проведены в рамках: · предварительных испытаний; · опытной эксплуатации; · приемочных испытаний Оказание услуг в рамках данного технического задания осуществляется Подрядчиком по обращению (заявке) Заказчика, направляемой посредством СРО Заказчика. Регистрация обращений, поступивших непосредственно в Модуль СЦ регистрации обращений Заказчика, производится сотрудниками Заказчика, которые обеспечивают первый уровень технической поддержки Модуля СЦ. В случае назначения приоритета «Критический» или «Высокий», информация о назначении также дублируется оповещением ответственных представителей Подрядчика посредством звонка на предоставленные номера телефонов. Обращение (заявка) должна содержать следующую информацию: – контакты пользователя/организации; – приоритет обращения, соответствующий Приложению 2 к Регламенту; – время обнаружения; – наименование компонента АСУ ТК - Модуль СЦ; Информация может быть расширена по согласованию с Заказчиком. Обращения (заявки) сотрудников Заказчика должны приниматься Подрядчиком через веб-интерфейс СРО. В процессе обработки обращений (заявок) Подрядчик должен обеспечить выполнение следующих процедур: – прием обращений(заявок) от сотрудников Заказчика; – оказание информационно-консультационной поддержки в соответствии с требованиями настоящего Технического задания; – информирование сотрудников Заказчика о статусе обработки и результатах обработки обращений(заявок). Подрядчик осуществляет обязательную регистрацию и учет всех обращений и заявок, поступивших к Подрядчику от представителей Заказчика в рамках оказания настоящих услуг Примечание: в случае приостановки работы по обращению или заявке (обращение или заявка находится в статусе «Приостановлено»), указываются причины, по которым работы по обращению или заявке приостановлены с указанием перечня действий/информации, запрошенных у инициатора обращения, а также даты, формы и адресата такого запроса. В случае отклонения обращения или заявки (заполняется в случае, если обращению или заявке присваивается статус «Отклонено»), указываются подробно причины такого отклонения, а также фиксируется дата и время перехода в статус «Отклонено». В случае, если обращение или заявка отклонены (отменены) самим Инициатором, то указывается дата и способ, которым от инициатора получено соответствующее уведомление. В случае невыполнения Подрядчиком регламентного времени реагирования или решения обращения (заявки) Заказчик вправе отозвать обращение и направить его Подрядчику повторно. При этом каждое отозванное обращение учитывается в Отчёте об оказанных услугах, как обращение с превышением времени реагирования или решения, но оплате не подлежит. В случае, если обращение (заявка) связано с некачественным выполнением Подрядчиком другой задачи, такое обращение решается в регламентное время, установленное Техническим заданием, при этом оплате такие обращения не подлежат, о чем указывается в Отчете об оказанных услугах в графе «Примечание» По результатам анализа угроз безопасности информации программного обеспечения и испытаний по выявлению уязвимостей в программном обеспечении Системы должна быть предоставлена отчетная документация по формам, утвержденным в Руководстве, и артефакты сборочной среды, подтверждающие проведение испытаний по выявлению уязвимостей в программном обеспечении Систем. Уязвимости подлежат устранению в сроки, обозначенные Заказчиком. В случае обнаружения уязвимого компонента Подрядчик должен заменить/обновить библиотеки. В случае, если уязвимость не подлежит исправлению на программном уровне, Подрядчик должен разработать меры предотвращения угроз безопасности, в том числе правила безопасности для наложенных средств защиты, рекомендации по безопасной настройке конфигурации для устранения потенциальных уязвимостей и снижения рисков информационной безопасности. Уязвимости, найденные ФСБ России, ФСТЭК России, Минцифры России, Роскомнадзором в ходе исполнения Контракта, а также в течение гарантийного периода, должны быть устранены Подрядчиком за свой счет в сроки, согласованные с Заказчиком 4.5.6. Требования к эргономике и технической эстетике Взаимодействие пользователей с Модулем СЦ должно осуществляться посредством визуального графического интерфейса. Ввод-вывод данных, прием управляющих команд и отображение результатов их исполнения должны выполняться в интерактивном режиме. Интерфейс должен быть рассчитан на преимущественное использование манипулятора типа «мышь», то есть управление Модулем СЦ должно осуществляться с помощью набора экранных меню, кнопок, значков и т. п. элементов. Клавиатурный режим ввода должен использоваться главным образом при заполнении и/или редактировании текстовых и числовых полей экранных форм. Все надписи экранных форм, а также сообщения, выдаваемые пользователю (кроме системных сообщений), должны быть на русском языке. Модуль СЦ должен обеспечивать проверку вводимых пользователем данных и предупреждать о некорректно введённых значениях Экранные формы должны проектироваться с учетом требований унификации: – все экранные формы пользовательского интерфейса должны быть выполнены в едином графическом дизайне, с одинаковым расположением основных элементов управления и навигации; – для обозначения сходных операций должны использоваться сходные графические элементы, кнопки и другие управляющие (навигационные) элементы. Термины, используемые для обозначения типовых операций, а также последовательности действий пользователя при их выполнении должны быть унифицированы; – внешнее поведение сходных элементов интерфейса (реакция на наведение указателя «мыши», переключение фокуса, нажатие кнопки) должно реализовываться одинаково. Структура размещения информации и представление этой структуры в Модуле СЦ должны соответствовать следующим требованиям: – пункты меню в пользовательском веб-интерфейсе должны быть сгруппированы в соответствии с тематикой информации, функциональными задачами и технологией работы; – каждому пункту меню должна соответствовать только одна выполняемая функция; – при совершении пользователями ошибочных действий должны выдаваться сообщения об ошибках. Эскизы визуального оформления компонента «Интерактивная карта» представлены в Приложении А. 4.3.1.3. Требования к регламенту оказания услуг Подрядчик должен руководствоваться Регламентом оказания услуг по технической поддержке Модуля СЦ. Регламент оказания услуг содержит следующую информацию: – порядок оказания услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Модуля СЦ; – порядок оказания услуги по решению инцидентов, связанных с работой ППО; – порядок оказания услуги адаптационного, конфигурационного и коррекционного сопровождения Модуля СЦ (в рамках действующих программных модулей и функциональностей); – порядок оказания услуги по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности. – Регламент содержит следующие формы заявок на оказание услуг: – форма заявки на оказание услуги по информационно-консультационной поддержке сотрудников Заказчика; – форма заявки на оказание услуги по решению инцидентов, связанных с работой ППО; – форма заявки на оказание услуг адаптационного, конфигурационного и коррекционного сопровождения Модуля СЦ (в рамках действующих программных модулей и функциональностей) (приоритет заявки определяется Заказчиком); – форма заявки на оказание услуги по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности 4.3.2. Требования к режиму обеспечения функционирования Модуля СЦ Режим оказания услуг определен в Приложении Б к настоящему ТЗ. По согласованию с Заказчиком, в целях недопущения остановки функционирования Модуля СЦ в период интенсивной работы пользователей в Модуле СЦ, отдельные услуги могут оказываться по специальному графику (в нерабочее время Подрядчика) в соответствии с заявками Заказчика 4.3.3. Требования к качеству оказываемых услуг Качество оказываемых услуг поддерживается Подрядчиком в соответствии с определяемыми данным ТЗ условиями и правилами и контролируется Заказчиком на постоянной основе, в том числе по соблюдению сроков исполнения и подтверждениям исполнения от инициаторов обращений и другим параметрам. По результатам выполнения работ по устранению инцидента должна быть устранена корневая причина инцидента с окончательным решением, устраняющим причину возникновения проблемы и исключающим вероятность повторного возникновения проблемы (инцидента). Время устранения корневых причин проблемы (инцидента) не должно составлять более 40 рабочих часов 4.5.7. Требования по сохранности информации при авариях В случае возникновения аварии или сбоя в процессе выполнения пользовательских задач должно быть обеспечено восстановление баз данных до состояния на момент последней завершенной Модулем СЦ транзакции, и структуры файлового хранилища. Все аварийные ситуации должны обрабатываться программно с выдачей соответствующих сообщений, с корректной обработкой ситуации (завершение транзакций, закрытие файлов и т.п.), без потери обрабатываемой информации. В Модуле СЦ должны быть предусмотрены меры, обеспечивающие целостность данных в случае отказа программного обеспечения или аппаратных средств, исключая случаи физического уничтожения носителя или нарушения функциональности носителя, операционной системы или СУБД по вине их производителя либо обслуживающего персонала. Используемые аппаратные и системные платформы должны обеспечивать сохранность и целостность информации в Модуле СЦ при полном или частичном отключении электропитания, аварии сетей телекоммуникации, полном или частичном отказе технических средств Модуля СЦ. Технические решения должны обеспечивать сохранность информации в случае возникновения следующих событий (аварий, отказов и т.п.): – отказ аппаратного обеспечения на сервере; – отключение питания на сервере; – отказ аппаратного обеспечения на рабочей станции; – отключение питания на рабочей станции администратора; – отказ линий связи, в том числе при осуществлении обмена данными 4.5.8. Требования к защите от влияния внешних воздействий Требования к защите от влияния внешних воздействий не предъявляются 4.5.9. Требования к патентной чистоте и патентоспособности 4.5.9.1. Исключительные права на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, базы данных, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, принадлежат Российской Федерации в лице Заказчика. Право собственности на результаты работ, отчетные документы и материалы, полученные в ходе выполнения работ по Контракту, принадлежат Российской Федерации в лице Заказчика и считаются переданными с момента подписания Сторонами Акта сдачи-приемки выполненных работ. Разработанное программное обеспечение поставляется вместе с исходными кодами. 4.5.9.2. Все проектные и технические решения должны отвечать требованиям четвертой части Гражданского кодекса Российской Федерации. Результаты Работ должны быть свободными от возможности предъявления любых прав и притязаний третьих лиц, основанных на промышленной, интеллектуальной или другой собственности. 4.5.9.3 Результаты выполненных Работ не должны повлечь необходимость осуществления Заказчиком закупок программного обеспечения (как исключительных, так и неисключительных прав) для обеспечения функциональности Системы в соответствии с Техническим заданием. При выполнении работ Подрядчик должен использовать только объекты интеллектуальной собственности, права на которые приобретены (получены) и используются без нарушений прав на интеллектуальную собственность третьих лиц или предоставлены Заказчиком 4.3.4. Требования к документированию результатов оказываемых услуг Для обеспечения контроля оказываемых услуг по поддержке Модуля СЦ со стороны Заказчика, по окончании каждого отчетного периода по контракту в соответствии с календарным планом, Подрядчик обязан предоставить Заказчику Отчет об оказанных услугах. Отчет должен содержать детальную информацию об оказанных услугах с указанием даты выполненных мероприятий и приложением обосновывающих документов (заявок, запросов, требований) или ссылкой на такие документы, если они содержатся в Модуле СЦ. Информация о выполненных мероприятиях по заявкам должна быть сформирована на основании соответствующих записей СРО по каждому этапу исполнения Контракта. В случае оказания услуги адаптационного, конфигурационного и коррекционного сопровождения Модуля СЦ, должны быть предоставлены документы, подтверждающие выполнение требований п. 29.3 приказа ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации». Фактическое время реагирования и время решения по всем обращениям, поступившим в СРО, формируется в СРО по итогам отчетного периода в разделе «Отчеты». Фактическое время реагирования и время решения по обращениям учитывает суммарное время, затраченное на реагирование и, соответственно, на работу по обращению с момента назначения обращения специалисту Подрядчика или группе исполнителей, ответственным за оказание услуг технической поддержки 3 уровня от начала до завершения работ Подрядчиком. При этом принимается суммарное время нахождения заявки в соответствующих статусах заявки СРО на стороне Подрядчика 4.3.5. Требования к классификации обращений и заявок Обращения и заявки Заказчика классифицируются в соответствии с приоритетами и регламентными сроками, указанными в Приложении 2 к Регламенту. Регистрация обращений и заявок предусматривает создание новой записи в СРО с присвоением поступившему обращению или заявке (новой записи) уникального идентификатора. Запись в СРО должна содержать вопрос или проблему, которую требуется решить или оказать консультацию. Состав обязательной информации, которую должно содержать обращение или заявка, зафиксирован в Регламенте оказания Услуг. Если обращение или заявка автоматически зарегистрированы в СРО при отправке представителем Заказчика, Подрядчик проверяет корректность классификации обращения или заявки и может обратиться к Заказчику с просьбой корректировки, предоставив обоснования в соответствии с настоящей классификацией (Таблица 6) 4.5.9.4. Подрядчик подтверждает, что обладает всеми правами на передачу Заказчику исключительных прав в соответствии с требованиями настоящего раздела Технического задания. В случае, если к Заказчику по вине Подрядчика будут предъявлены претензии в этой части, иски третьих лиц, связанные с нарушением их прав, Подрядчик принимает на себя такие претензии и иски и возмещает Заказчику все расходы и весь ущерб, понесенный в связи с ними. 4.5.9.5. Подрядчик обязан согласовать с Заказчиком необходимость использования при выполнении работ охраняемых результатов интеллектуальной деятельности, права на которые принадлежат Подрядчику или третьим лицам. 4.5.9.6. В случае, если при выполнении Работ используется готовое программное обеспечение (платформа, подсистема, СУБД и т.д.), которое становится частью (компонентом) Системы, Заказчику передаются полные исключительные права, или неисключительные права (путем заключения лицензионного/сублицензионного договора/соглашения) на такое программное обеспечение со следующими возможностями: – права передаются бессрочно (на весь срок действия исключительных прав); – территория действия Российская Федерация; – должно быть обеспечено право Российской Федерации (в лице Заказчика) передавать, дорабатывать, распространять, развивать результаты работ, созданные в процессе исполнения Контракта, а также перерабатывать такое программное обеспечение. Лицензионное (сублицензионное) соглашение (договор), Акт передачи прав, подписанные Подрядчиком, согласие правообладателя, оформленное в соответствии с положениями Гражданского кодекса Российской Федерации (в случае, если Подрядчик не является правообладателем такого программного обеспечения), инструкция по инсталляции, руководство администратора, руководство пользователя передаются Заказчику в сроки, установленные Техническим заданием для соответствующего функционала Системы Лицензионное (сублицензионное) соглашение (договор) не может возлагать на Заказчика какие-либо обязанности (в т.ч. в части конфиденциальности, предоставления отчетности), не предусмотренные Контрактом. 4.5.9.7. Передача Заказчику исключительных прав, или простых (неисключительных) прав не может повлечь увеличение стоимости Контракта и/или изменение иных существенных условий Контракта. 4.5.9.8. Функциональность Модуля СЦ передается в объеме и в сроки, установленные Техническим заданием. 4.5.9.9. Нарушение условий настоящего раздела Технического задания, в т.ч. отсутствие соответствующего лицензионного (сублицензионного) соглашения (или договора), либо предоставление лицензионного (сублицензионного) соглашения (или договора), не соответствующего требованиям действующего законодательства Российской Федерации или требованиям Контракта, является нарушением существенных условий Контракта. 4.5.9.10. В случае, если в соответствии с пунктом 4.5.9.6 Заказчику передается исключительное право, такая передача осуществляется в порядке, установленном Гражданским кодексом Российской Федерации. 4.5.9.11. В случае, если при выполнении Работ положения пунктов 4.5.9.5-4.5.9.6 не применялись, Подрядчик в составе отчетной документации предоставляет об этом декларацию в свободной форме. Декларация должна содержать сведения о полном соответствии результата Работ требованиям Контракта, а также о неприменении при выполнении работ готового программного обеспечения (платформ, подсистем, СУБД и т.д.), которое стало частью (компонентом) Системы Таблица 6. Категории обращений и заявок Категория Примеры Запрос на обслуживание Подготовка SQL запроса к СУБД для решения прикладной задачи и д.р. – запрос на любое действие, не являющееся запросом информации и несовершенный на основе происшествия, прямо или косвенно влияющего на работу Модуля СЦ Консультация «Где взять / куда обратиться...?», «Как сделать / выполнить…», «Как это работает…?» - запрос, имеющий своей целью получение информационной поддержки Инцидент Разбор ошибок/сбоев и подготовка материалов (корректировочных релизов, инструкций) для Заказчика для устранения ошибок/сбоев, которые приводят к частичному и полному нарушению работоспособности всех или отдельных функций ППО. Подготовка изменения и материалов, необходимых для проведения аварийно-восстановительных работ для возобновления работоспособности Модуля СЦ ЗНИ Подготовка изменений, связанных с изменением, улучшением/оптимизацией Модуля СЦ и выводом новой модифицированной функциональности в штатном режиме. Подготовка изменений, связанных с модификацией существующих и/или реализация новых интеграционных механизмов для получения/обработки данных внешних систем. Подготовка изменений графического интерфейса по требованиям Заказчика. Перечень статусов обращений (заявок) приведен в пункте 3.3. Регламента оказания Услуг. Назначение обращению (заявке) статуса «Закрыто» осуществляется Заказчиком только после получения от инициатора обращения (заявки) подтверждения о его исполнении или нахождения обращения (заявки) в статусе «Выполнено» и отсутствия повторных вопросов/запросов по данному обращению (заявки) в течение 5 рабочих дней. Категории и статусы обращений (заявок) могут быть скорректированы в процессе оказания услуг исключительно по согласованию с Заказчиком 4.3.6. Требования к услугам технической поддержки 4.3.6.1. Требования к организации третьего уровня технической поддержки Основными задачами организации третьего уровня технической поддержки в рамках оказания услуг по технической поддержке Модуля СЦ являются организация эксплуатационной службы Подрядчика, проверка готовности технических и программных средств для обеспечения непрерывного функционирования ППО Модуля СЦ. Подрядчиком должны быть проведены организационно-штатные и подготовительные мероприятия (в т. ч. технические) в рамках организации технической поддержки Модуля СЦ. Подрядчик в течение 5 (пяти) рабочих дней с даты заключения Контракта должен: – определить и направить Заказчику документ «Перечень уполномоченных специалистов», содержащий контактную информацию (ФИО, должность, адрес рабочей электронной почты) лиц, ответственных за оказание услуг со стороны Подрядчика; – обеспечить подключение специалистов Подрядчика к Системе регистрации обращений (заявок) (СРО предоставляется Заказчиком) для оказания услуг; – согласовать с Заказчиком способ доступа Подрядчика к Модулю СЦ. Результат выполнения мероприятий фиксируется в Протоколе проверки результатов организационно-штатных и подготовительных мероприятий (см. Приложение Д к настоящему ТЗ) 4.5.9.12. Передача Заказчику комплекта документов, материалов и сведений, предусмотренных нормативными правовыми актами Российской Федерации в сфере информационных технологий, защиты информации, правовой защиты интересов государства в области интеллектуальной собственности, включая документы, подтверждающие отказ авторов (разработчиков) от исключительных прав на передаваемые объекты интеллектуальной собственности в пользу Подрядчика, с проектами заявок на государственную регистрацию в установленном порядке прав Заказчика на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, базы данных, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, осуществляется Подрядчиком в составе отчетной документации, предусмотренной условиями Контракта. 4.5.9.13. По результатам выполнения работ по развитию системы должны быть подготовлены материалы для регистрации доработанной версии Системы (объекта учета) в НФАП в соответствии с требованиями постановления Правительства Российской Федерации от 30 января 2013?г. №?62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин» (с изменениями и дополнениями) в части обязательности размещения результатов работ в национальном фонде алгоритмов и программ для электронных вычислительных машин 4.5.10. Требования по стандартизации и унификации К Модулю СЦ предъявляются следующие требования в части стандартизации и унификации: – работы по развитию Модуля СЦ должны производиться в соответствии с действующими стандартами и нормами Российской Федерации; – при создании и модернизации элементов Модуля СЦ следует руководствоваться действующими в Российской Федерации национальными стандартами и другими нормативно-техническими документами; – используемые оборудование и материалы, подлежащие обязательной сертификации, должны иметь соответствующие сертификаты; – ПО Модуля СЦ должно проектироваться и разрабатываться с учётом обеспечения требований унификации; – применяемые при создании Модуля СЦ технические (форматы данных, протоколы передачи и прочие) и организационные (регламенты, требования, инструкции) решения должны быть доступны и документированы в виде, достаточном для независимой (без обращения к Подрядчику) реализации третьими сторонами; – термины, обозначения и наименования, используемые в ПО, должны быть стандартизованы и унифицированы, выполнены на русском языке; – взаимодействие элементов и их внешнее поведение должно быть реализовано одинаково и производиться по единым правилам 4.3.6.2. Требования к услугам информационно-консультационной поддержки работников Заказчика и пользователей Модуля СЦ Услуги информационно-консультационной поддержки сотрудников Заказчика включают: – обработку обращений и заявок, поступивших от сотрудников Заказчика; – консультирование сотрудников Заказчика и пользователей Модуля СЦ; – актуализацию документации, и других материалов по работе с Модулем СЦ при необходимости. – консультирование и разработку рекомендаций по настройке Модуля СЦ (без изменения программного кода), включая изменение настроек функционирования; – консультации по вопросам использования, настройки и возможностям Модуля СЦ; – консультации по проведению превентивных мер для недопущения аварийных ситуаций в Модуле СЦ; – консультации по предварительной диагностике и локализации возникшей неисправности Модуля СЦ; – консультации по вопросам обеспечения информационной безопасности Модуля СЦ и настройки функций, обеспечивающих корректную работу программного обеспечения для совершения юридически значимых действий в Модуле СЦ; – другие вопросы, связанные с работой Модуля СЦ. 4.3.6.2.1. Требования к порядку оказания услуг информационно-консультационной поддержки работников Заказчика и пользователей Модуля СЦ Подрядчик выполняет консультирование сотрудников Заказчика и пользователей Модуля СЦ. Консультация может быть предоставлена по согласованным с представителем Заказчика каналам коммуникации с регистрацией результата консультации в СРО Подрядчиком. Детальный порядок оказания консультационных услуг определен в Регламенте оказания Услуг 4.3.6.3. Требования к услугам по решению инцидентов, связанных с работой ППО Подрядчик устраняет неисправности Модуля СЦ, связанные с работой ППО, выявленные в рамках оказания услуг согласно настоящему Техническому заданию, при этом в зону ответственности Подрядчика не входит устранение неисправностей, выявленных на стороне Заказчика и на стороне третьих лиц (провайдера связи, поставщика электропитания и т.д.). Первичная диагностика выявленной неисправности проводится на 1 и 2 уровнях технической поддержки и не входит в зону ответственности Подрядчика. Если при проведении первичной диагностики и попытке устранить неисправности на 1 и 2 уровнях технической поддержки, данную неисправность устранить не удалось и в процессе диагностики было выявлено, что проблема связана с работоспособностью ППО, обращение (заявка) назначается сотруднику Подрядчика, ответственному за оказание услуг технической поддержки 3 уровня. Инцидентами вне зоны ответственности Подрядчика являются: – работоспособность функциональности, выходящая за рамки текущей реализации функций в Модуле СЦ и/или являющаяся расширением требований Заказчика к функциям Модуля СЦ; – проведение профилактических и плановых работ, согласованных с Заказчиком; – нарушение работоспособности функций Модуля СЦ, вызванное проведением работ на стороне Заказчика 4.5.11. Требования к показателям назначения 4.5.11.1. Требования к показателям назначения мероприятий по развитию Модуля СЦ В рамках выполнения работ по развитию Модуля СЦ, предусмотренных ТЗ, показатель назначения «Количество пользователей» должен соответствовать значениям, приведенным в данном разделе. Пояснения по показателям, связанным с количеством пользователей, приведены в Таблице 8. Таблица 8. Определения показателей, связанных с количеством пользователей в Модуле СЦ № Показатель Определение Расчетное количество пользователей Количество пользователей, работу которых должен обеспечить Модуль СЦ к моменту сдачи работ по Контракту с учетом достижения всех показателей назначения Расчетное количество одновременно работающих пользователей Количество одновременно работающих пользователей, работу которых должен обеспечивать Модуль СЦ к моменту сдачи работ по Контракту с учетом достижения всех показателей назначения Значения показателей количества пользователей, достижение которых необходимо обеспечить, представлено в Таблице 9 Таблица 9. Значения показателей количества пользователей № Показатель Значение 1. Расчетное количество пользователей 1 000 2. Расчетное среднее количество одновременно работающих пользователей 200 Развитие Модуля СЦ должно быть направлено на достижение следующего эффекта (показателя), подставленного в мероприятии 103.002 «Информационно-аналитическая система регулирования на транспорте (АСУ ТК)» ВПЦТ Минтранса России: Выполнение работ по развитию Модуля СЦ предусмотрено мероприятием по развитию АСУ ТК, приведенном в ВПЦТ Минтранса России на 2026-2028 гг: № 103.002 «АСУ ТК» в составе ИТ расхода 103.26.000005 «Развитие предусматривает реализацию ОКР и эффектов, приведенных в Таблице 10. Таблица 10. ОКР и эффекты, приведенные в ВПЦТ Минтранса России на 2026 г. № ОКР Дата ОКР Эффекты 1 Обеспечено информационное взаимодействие с Минобороны России о происшествиях на транспортных объектах 25.12.2026 Сокращено время сбора и передачи сведений для Минобороны России о ЧС и НС на транспорте с 120 до 10 минут 2 Обеспечена автоматизация формирования отчетов о нештатных ситуациях на транспорте, в том числе по данным внешних систем 25.12.2026 Сокращено время на подготовку отчетов о нештатных ситуациях на транспорте с 20 до 5 минут Реализация остальных ОКР не является предметом данного ТЗ и проводится в рамках отдельного технического задания. 4.5.11.2. Требования к показателям назначения мероприятий по эксплуатации Модуля СЦ. Работы по эксплуатации Модуля СЦ не должны обеспечивать режимы функционирования Модуля СЦ, приведенные в разделе 4.5.2 данного ТЗ Работы по устранению неисправности приостанавливаются (по согласованию с Заказчиком) в следующих случаях: – если Подрядчиком в результате диагностики выявлено, что неисправность находится в зоне ответственности Заказчика. Подрядчик информирует Заказчика о выявленной неисправности в зоне его ответственности по согласованным каналам связи; – требуется действие со стороны Заказчика – до момента выполнения данного действия Заказчика. Заказчик информируется о необходимых действиях по согласованным каналам связи; – отсутствие возможности связаться со специалистами Заказчика, участие которых необходимо для устранения неисправности; – требуется доставить оборудование на объект – до момента доставки и установки оборудования. В случаях, представленных выше, время приостановки работ не входит в учет продолжительности устранения неисправности. Учет времени устранения неисправности Подрядчиком считается с момента назначения Инцидента специалисту Подрядчика, ответственному за оказание услуг технической поддержки 3 уровня. Подтверждение необходимости приостановления работ находится в зоне ответственности Подрядчика. Приостановление сроков выполнения задач в соответствии с настоящим пунктом подтверждается Заказчиком по мотивированному обращению Подрядчика в СРО, основанному на данных диагностики или на иных фактических обстоятельствах В случае непринятия Подрядчиком необходимых мер по информированию Заказчика (отсутствие надлежащего обращения от Подрядчика или отсутствие уведомления о необходимости осуществления каких-либо действий Заказчиком) не может являться основанием для приостановления работ по устранению неисправности. В отдельных случаях Подрядчику может потребоваться выполнение технологических работ для устранения причин неисправности или недопущения повторения их в будущем. Для обеспечения устранения неисправности Модуля СЦ Заказчиком проводится классификация в соответствии с приоритетами по степени срочности их устранения. Продолжительность устранения неисправности, а также периодичность информирования Подрядчиком Заказчика о ходе устранения неисправности, определены в Регламенте оказания услуг. При подаче обращения (заявки) наивысшего приоритета через СРО Заказчик должен дополнительно проинформировать службу поддержки Подрядчика о созданном обращении (заявки) по телефону уполномоченного сотрудника Подрядчика. При этом временем подачи обращения (заявки) считается время подачи обращения (заявки) через СРО 4.3.6.3.1. Требования к порядку оказания услуги по решению инцидентов, связанных с работой ППО При поступлении от Заказчика обращения (заявки), являющегося неисправностью в работе Модуля СЦ (инцидентом), Исполнитель реагирует на инцидент в СРО в срок не более 30 минут с момента поступления. В случае необходимости, для решения инцидента ответственный специалист должен связаться с инициатором обращения (заявки) для уточнения условий воспроизведения проблемы или для получения дополнительных сведений. После получения необходимых сведений от инициатора обращения (заявки) ответственный специалист производит диагностику с целью выявления причины инцидента и возможных путей устранения. В случае, если инцидент невозможно решить без получения дополнительных сведений от инициатора, и не удается связаться с инициатором в течение пяти рабочих дней, обращение (заявка) отклоняется в связи с недостатком данных для его решения, Заказчику направляется уведомление об отклонении обращения (заявки). Время, в течение которого невозможно связаться с инициатором, вычитается из общего времени обработки обращения (заявки). Все попытки связаться с инициатором должны фиксироваться с указанием даты и времени попытки, используемого способа связи (номер телефона, адрес электронной почты) и результата попытки (не удалось дозвониться, абонент недоступен, и т.д.) Факт и время решения инцидента должны быть зафиксированы и отражены в СРО. В случае, если причиной сбоя в работе Модуля СЦ является выход из строя аппаратного обеспечения или неработоспособность смежной информационной системы, время работы над инцидентом приостанавливается до момента устранения неисправности. В ходе решения инцидентов могут быть выявлены дефекты ППО Модуля СЦ. В случае обнаружения дефектов ППО, Подрядчик информирует об этом Заказчика. Исполнитель может быть привлечен к проверке результата устранения дефекта по инициативе Заказчика. Приоритеты инцидентов приведены в Приложении Б к ТЗ. Детальный порядок оказания услуги по решению инцидентов, связанных с работой ППО Модуля СЦ определен в Регламенте оказания Услуг 4.3.6.4. Требования к услугам адаптационного, конфигурационного и коррекционного сопровождения и доработки Модуля СЦ (в рамках действующих программных модулей и функциональностей) Услуги адаптационного, конфигурационного и коррекционного сопровождения и доработки Модуля СЦ включают: – управление изменениями и адаптация функций Модуля СЦ; – изменение настроек функционирования Модуля СЦ; – внесение изменений и/или модификаций Модуля СЦ (в рамках действующих программных модулей и функциональностей), направленных на улучшение их работоспособности и функциональных возможностей; – подготовка и передача Заказчику SQL запросов в СУБД для получения агрегированной информации из Модуля СЦ, которую невозможно получить с использованием графического пользовательского интерфейса; – адаптация модулей интеграций со смежными информационными системами 4.3.6.4.1. Требования к проведению изменений Основанием для внесения изменений является запрос от Заказчика. Все активности по внесению изменений должны быть согласованы с Заказчиком, а действия Подрядчика при оказании данной услуги должны быть зафиксированы. В рамках данного Технического задания изменениями считаются локальные доработки функционала Модуля СЦ, которые не должны приводить к необходимости выполнения дополнительных аттестационных испытаний или переаттестации АСУ ТК в соответствии с п. 33 приказа от 29.04.2021 № 77 «Об утверждении Порядка организации и проведения работ по аттестации объектов информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну». При необходимости внесения изменений в Модуль СЦ, не связанных с критичным инцидентом, существенно нарушающим работоспособность Модуля СЦ, Заказчик направляет Подрядчику обращение (заявку), в котором излагает суть изменения, которое требуется внести в Модуль СЦ. Исполнитель, в течение 3 (трех) рабочих дней с момента поступления соответствующего обращения (заявки), оценивает техническую возможность реализации запрашиваемого изменения и варианты реализации. По итогу проведения оценки Подрядчик направляет Заказчику заключение о возможности реализации данного изменения с описанием возможных вариантов реализации и согласует с Заказчиком проведение данного изменения При проведении работ по изменению и адаптации Подрядчик должен: – обеспечить выполнение требований безопасной разработки программного обеспечения; – обеспечить предварительное проектирование технических решений и согласование с Заказчиком проекта реализации изменения; – использовать семантическое версионирование (SemVer) в работе, передать Заказчику все артефакты разработки (исходный код и сторонние библиотеки, конфигурации, сборочные и собранные образы и др.); – подготовить полноценное описание функционала, включенного в релиз, с необходимыми схемами и пояснениями к обновлению на стендах Заказчика; – обеспечить тестирование разработанного функционала на стендах Заказчика силами Подрядчика; – решение о переносе измененного ППО на продуктивный стенд принимается Заказчиком по итогу результатов проведенного тестирования; – обеспечить техническое сопровождение процедуры тестирования ППО и переноса измененного ППО на продуктивный стенд Заказчика; – обеспечить экстренное внесение соответствующих изменений в случае выявления некорректной работы продуктивного стенда Заказчика после проведения обновления по итогам разработанного изменения в кратчайшие сроки; – актуализировать при необходимости комплект эксплуатационной документации: o руководство пользователя; o руководство администратора; o иные документы (при необходимости). Результат выполнения изменений должен быть отражен в Отчете по оказанию услуг. Типы и приоритеты изменений могут быть скорректированы в процессе оказания услуг исключительно по согласованию с Заказчиком 4.3.6.4.2. Требования к изменению настроек функционирования Изменение настроек функционирования может проводиться в рамках допустимых пределов изменения функционирования, заложенных в архитектуру Модуля СЦ. Изменение настроек функционирования включает в себя изменение данных и справочников, изменение форм документов, формируемых Модулем СЦ, изменение и настройку форматов и версий передачи данных в смежные системы. Доработка программного кода Модуля СЦ может допускаться (в случае необходимости) при выполнении работ по адаптации функций Модуля СЦ в части изменения формата передачи данных в смежные информационные системы при условии соблюдения требований пункта 29.3 приказа ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации» 4.3.6.5. Требования к услугам по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности По запросу Заказчика Подрядчик должен провести работу по приведению ППО в соответствие с требованиями по обеспечению информационной безопасности. Критичность уязвимости оценивается в соответствии в соответствии с Методическим документом ФСТЭК России «Методика оценки уровня критичности уязвимостей программных, программно-аппаратных средств» (утвержден ФСТЭК России 30.06.2025), а также с учетом ГОСТ 56545-2015 и международными стандартами (CVSS 3.0 и выше), и задает необходимый срок устранения. В процессе проведения Заказчиком обследования Модуля СЦ и выявления уязвимостей в ППО, связанных с исходным кодом Модуля СЦ и/или используемыми компонентами (библиотеками), Заказчик направляет Подрядчику обращение (заявку) на устранение, с указанием критичности и срочности принятия мер по устранению в СРО. Подрядчик при оказании услуг по обновлению или устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности должен: – провести анализ уязвимостей и связанных с ними исходным кодом и/или используемыми компонентами (библиотеками); – выработать варианты устранения указанных уязвимостей и согласовать с Заказчиком их реализацию; – своевременно внести изменения в исходный код Модуля СЦ и/или используемые компоненты (библиотеки) и подготовить соответствующее обновление; – провести обновление Модуля СЦ в тестовом контуре Заказчика и проинформировать Заказчика о готовности проведения тестирования; – протестировать успешность обновления или устранения уязвимостей в ППО и корректность функционирования Модуля СЦ на тестовом контуре, совместно с Заказчиком; – при невозможности незамедлительного устранения уязвимости приоритетов «Критический» и «Высокий» Подрядчик обязан предоставить исчерпывающий список причин и согласовать план достаточных компенсирующих мер с ответственными сотрудниками Заказчика. Результат внесения изменений отображается в соответствующей записи в СРО и в составе Отчета об оказанных услугах 4.3.6.5.1. Требования к порядку оказания услуг по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности Подрядчик в соответствии с приоритетами обращений и контрольными сроками исполнения (см. Приложение Б к ТЗ) оценивает техническую возможность и сроки устранения уязвимостей, и реализацию обновления Модуля СЦ. По итогу проведения оценки Подрядчик направляет в заявке СРО Заказчику заключение о возможности устранения уязвимостей и/или обновления в ППО и согласует с Заказчиком проведение данных работ При проведении работ по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности необходимо выполнить следующее: – Заказчику сформировать заявку на устранение (обновление) в СРО с полным списком обнаруженных уязвимостей и планируемыми работами; – согласовать в рабочем порядке время начала и завершения работ, перечень работ, выполняемых в рамках обновления или устранения уязвимостей в ППО с Заказчиком; – оповестить Заказчика о начале проведения работ на тестовом контуре; – провести работы по обновлению или устранению уязвимостей в ППО на тестовом контуре Модуля СЦ в установленные сроки; – протестировать выполнение работ в тестовом контуре и проинформировать Заказчика о готовности переноса ППО на продуктивный контур; – силами Заказчика обновить продуктивный контур Модуля СЦ, в соответствии с планом устранения и выполненными работами; – совместно с Заказчиком проверить корректность функционирования Модуля СЦ и устранения уязвимостей в продуктивном контуре Модуля СЦ по результатам обновления; – при необходимости актуализировать документацию (описание архитектуры, анкеты постановки на мониторинг и иные документы). Любые изменения в части обновления или устранения уязвимостей в ППО на промышленном контуре Модуля СЦ должны применяться только в случае успешного проведения аналогичных работ на тестовом контуре. Детальный порядок оказания услуги по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности определен в Регламенте оказания Услуг 4.4. Требования к видам обеспечения 4.4.1. Требования к лингвистическому обеспечению Документация на Модуль СЦ должна разрабатываться на русском языке. Взаимодействие пользователей с Модулем СЦ посредством графического интерфейса должно происходить на русском языке за исключением сообщений, зависящих от настроек системного программного обеспечения, установленного на рабочих местах пользователей. При разработке программных решений Модуля СЦ должно быть предусмотрено использование языков программирования высокого уровня, приведенных в Таблице 7. Таблица 7. Языки и средства разработки, специального программного обеспечения Модуля СЦ Категория Наименование Назначение Языки программирования Kotlin Разработка серверной логики и сервисов (backend) JavaScript / TypeScript Разработка клиентской части (frontend) Python Разработка скриптов интеграции, обработки данных и автоматизации Фреймворки и библиотеки Vue.JS Разработка пользовательских интерфейсов (веб-интерфейсы компонентов визуализации и отчетности) React Разработка пользовательских интерфейсов (при необходимости создания сложных интерактивных компонентов) Решения по лингвистическому обеспечению, включая перечень используемых языков программирования, должны быть согласованы с Заказчиком на этапе технического проектирования 4.4.2. Требования к математическому обеспечению Требования к математическому обеспечению не предъявляются. 4.4.3. Требования к метрологическому обеспечению Требования к метрологическому обеспечению не предъявляются. 4.4.4. Требования к организационному обеспечению Требования к организационному обеспечению не предъявляются. 4.4.5. Требования к методическому обеспечению Задачи методического обеспечения Модуля СЦ должны быть обеспечены за счет использования технологических и методических документов касающихся вопросов функционирования транспортного комплекса и разработки и эксплуатации ПО. 4.4.6. Требования к информационному обеспечению Состав, структура и способы организации информационного обеспечения в Модуле СЦ должны быть определены на этапе технического проектирования. Факты информационного обмена с внешними системами должны фиксироваться в соответствующем журнале 4.1. Требования к структуре Модуля СЦ В процессе работ по развитию Системы должны сохраниться основные требования к построению архитектуры Системы в соответствии с принципами трехуровневой архитектуры: 1. уровень хранения данных или уровень базы данных (сервер СУБД); 2. уровень сервера приложений (сервер аналитической обработки); 3. презентационный уровень, обеспечивающий взаимодействие с клиентскими приложениями. В состав Системы должны входить следующие основные компоненты: 4. сервер баз данных; 5. сервер приложений; 6. веб-сервер. Сервер баз данных должен обеспечивать хранение и целостность хранимых данных, создание резервных копий, ведение журнала транзакций, восстановление данных после сбоев. Сервер приложений должен обеспечивать обработку запросов, поступающих от клиентских приложений (через веб-сервер), формирование ответов на запрос в доступном пользователю виде (формирование пользовательских интерфейсов). Веб-сервер должен обеспечивать взаимодействие с оператором и внешними системами по HTTP / HTTPS протоколу в режиме «запрос-ответ» (получения запросов от пользователя и передачи ответа в виде соответствующей информации, обработанной серверами приложений). Взаимодействие Системы с пользователем должно отвечать требованиям модели «тонкого клиента» (т.е. представлять на стороне клиента (пользователя) лишь графический пользовательский интерфейс). Все составляющие Системы должны использовать единую методологию и отвечать единым принципам взаимодействия, надежности и управления. Перечень компонентов Модуля СЦ представлен в Таблице 4. Таблица 4. Перечень компонентов Модуля СЦ, в отношении которых выполняются работы по развитию № п.п. Наименование компонента Модуля СЦ Раздел ТЗ 1 Компонент регистрации событий 4.2.1. 2 Компонент отчетности 4.2.2 3 Компонент визуализации 4.2.3 4 «Интерактивная карта» (компонент создается) 4.2.4 5 Компонент администрирования 4.2.5 4.2. Требования к дорабатываемым функциям модуля СЦ 4.2.1. Развитие компонента регистрации событий (1 очередь) Должны быть выполнены следующие доработки: – обеспечение логирования действий пользователя, связанных с карточкой события; – доработка объектной модели в части создания новых типов сущностей (карточек) с учетом реализуемых интеграций с информационными ресурсами (силы и средства предупреждения и ликвидации ЧС и нештатных ситуаций на транспорте, ТС, ограничения воздушного пространства, неблагоприятные и опасные природные явления); – реализация механизма установления связи между сущностями в Модуле СЦ автоматизированным и ручным способами (события, природные явления, силы и средства предупреждения и ликвидации ЧС и нештатных ситуаций на транспорте, ограничения воздушного пространства, ОТИ, ТС и др.); – отображение в карточке установленных связей между сущностями. 4.4.7. Требования к программному обеспечению Общесистемное ПО, используемое в составе Модуля СЦ, должно быть зарегистрировано в Едином реестре российских программ для электронных вычислительных машин и баз данных и соответствовать рекомендованным показателям эффективности и соответствующим им значениям индикаторов эффективности перехода подведомственных организаций на использование российского ПО, заданных Приказом Минцифры России от 18.01.2023 № 21 «Об утверждении методических рекомендаций по переходу на использование российского программного обеспечения, в том числе на значимых объектах критической информационной инфраструктуры Российской Федерации, и о реализации мер, направленных на ускоренный переход органов государственной власти и организаций на использование российского программного обеспечения в Российской Федерации». Применяемое в системе программное обеспечение должно соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации, постановления Правительства Российской Федерации от 23 декабря 2024 г. № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц» Прикладное программное обеспечение должно отвечать следующим требованиям: – совместимость программных продуктов в части используемых технических средств, системного программного обеспечения и общесистемной инфраструктуры в пределах требований к техническому обеспечению, а также их информационная совместимость в пределах требований к информационному обмену; – обеспечение трехуровневой архитектуры с разделением на уровень хранения данных (сервер БД), уровень бизнес-логики (сервер приложений) и уровень представления ( 4.4.7.1. Требования к инструментам разработки и процессу контроля версий программного обеспечения 4.4.7.1.1. Система контроля версий Для управления исходным кодом должна использоваться система контроля версий кода, развернутая в инфраструктуре Заказчика. 4.4.7.1.2. Правила именования веток Имя ветки должно соответствовать следующему формату: / / Категории веток: ? feature/ — разработка новой функциональности, а также рефакторинг или удаление существующей; ? fix/ — исправление ошибок; ? hotfix/ — срочные исправления, применяемые в обход стандартного процесса разработки; ? test/ — для проведения экспериментов, не влияющих на основную разработку. Идентификатор задачи: после категории указывается ссылка на задачу (issue) в системе контроля версий кода. Описание: добавляется краткое описание решаемой задачи в формате kebab-case (слова разделяются дефисами, например, add-user-auth). Примеры именования веток: ? feature/#123/add-payment-integration; ? fix/#45/correct-calculation-logic; ? hotfix/#67/urgent-database-connection-patch. 4.4.7.1.3. Правила именования коммитов Сообщение коммита должно соответствовать соглашению Conventional Commits и состоять из категории и описания: : ? fix — исправление ошибки. Примеры сообщений коммитов: ? feat: добавление формы регистрации пользователя; ? fix: исправление ошибки валидации email-адреса; ? refactor: оптимизация алгоритма сортировки данных; ? chore: обновление версий в файле dependencies. 4.4.7.1.4. Модель ветвления В процессе разработки используются следующие основные ветви: ? main / master — стабильная ветка, содержит только код, прошедший полное тестирование и развернутый в продуктивных контурах; ? dev — ветка для интеграции завершенных задач, предназначенная для сборки и тестирования в тестовых средах. Попадание кода в main осуществляется только через Merge Request (MR) из dev 4.2.2. Развитие компонента отчетности (3 очередь) Должна быть обеспечена автоматизация процессов формирования отчетов о ЧС и нештатных ситуациях на транспорте, в т.ч. на основе данных из внешних систем. Включает следующие доработки: – разработка шаблонов отчетов в различных форматах (табличный, текстовый); – реализация выбора фотоматериалов для включения в справку; – форматирование содержимого справок с учетом правил русского языка в отношении окончаний слов (в зависимости от падежа, склонения, числа и рода); – автоматизированное формирование выводов к содержимому справки на основе настраиваемых критериев; – создание интерфейса выбора параметров (фильтрации) для формирования отчетов: o состав полей для включения в отчёт; o настройка диапазонов значений характеристик и дат; o порядок отображения полей; o настройка заголовка. – реализация способа подготовки отчётов в асинхронном режиме (очереди); – реализация интерфейса компонента формирования отчетности для отображения очереди формирования отчетов и статусов их подготовки; – экспорт отчётов в форматы xlsx, csv и справок в форматы pdf, docx. Необходимо разработать не менее 10 шаблонов отчетов и/или справок. Перечень, структура и содержание шаблонов должны быть согласованы с Заказчиком на этапе технического проектирования. 4.2.3. Развитие компонента визуализации (2 очередь) В рамках развития компонента визуализации должны быть выполнены следующие доработки, обеспечивающие: – вывод перечней (списков) сил и средств предупреждения и ликвидации ЧС и нештатных ситуаций на транспорте с отображением мест их постоянного размещения (дислокации) на карте, включая: o отображение зон ответственности на карте; o возможность их фильтрации (по видам транспорта, регионам и пр.); o реализацию инструмента расчета расстояния (с использованием сети автомобильных и железных дорог) между местом события и местами дислокации сил и средств, а также вывода маршрутов на карте; – отображение зон (полигонов) с установленными ограничениями движения в воздушном пространстве на карте; – отображение термических точек; – реализация возможности отображения данных из паспорта региона, отображаемого в модуле iМинтранс (модуль АСУ ТК); – отображение краткой карточки сущностей и ОТИ (краткой информации и/или динамических характеристик объекта) при выборе объекта на карте с возможностью перехода в полную карточку сущности и ОТИ; – отображение данных от Росгидромета, предусматривающих: o отображение неблагоприятных и опасных природных явлений на карте (с заданным периодом обновления данных); o управление отображением явлений на карте, включая настройку состава отображаемых объектов, поиск, фильтрацию, с использованием соответствующей панели управления; o выведение краткой карточки явления при выборе объекта, с возможностью перехода в полную карточку объекта – отображение на карте связанных сущностей и ОТИ; – реализация функции выбора темного и светлого стилей отображения элементов интерфейса, карточек сущностей, картографической основы и объектов, отображаемых на карте; – реализация механизма для выбора картографической основы в одном из распространенных форматов WMTS, TMS, MVT и др. Должна быть предусмотрена возможность настройки перечня картографических основ и параметров доступа к ним; – настройка базового набора дашбордов, содержащих преднастроенные виджеты о количестве событий в разрезе видов транспорта с возможностью перехода к исходным данным (карточкам событий, ОТИ и т.д.), с фильтрацией по параметрам. Параметры фильтрации должны быть определены на этапе технического проектирования. Должно быть обеспечено автоматическое и принудительное обновление данных, отображаемых на дашбордах 4.4.7.1.5. Требования к используемым зависимостям (библиотекам) Все внешние зависимости проекта должны быть зафиксированы с указанием точных версий. Для контроля версий зависимостей в репозиторий обязательно должны быть включены следующие файлы: · Для JavaScript: package-lock.json или yarn.lock; · Для Python: requirements.txt (с зафиксированными версиями) или Pipfile.lock; · Для Go: go.mod и go.sum; Загрузка всех зависимостей должна производиться исключительно через внутренний прокси-репозиторий Заказчика, настроенный в соответствующем системе менеджере пакетов. Запрещается: · Использование плавающих версий (например, ^1.2.3, ~4.5.0, latest); · Использование библиотек, содержащих критические уязвимости, в том числе зарегистрированные в реестре CVE (Common Vulnerabilities and Exposures). 4.4.7.1.6. Требования к процессу непрерывной интеграции (CI) Сборка программного обеспечения, включая этапы компиляции, тестирования и анализа кода, должна выполняться исключительно в инфраструктуре непрерывной интеграции Заказчика. 4.4.7.1.7. Требования к хранению артефактов сборки Все артефакты сборки (результирующие пакеты, Docker-образы и т.д.) подлежат обязательному хранению в предназначенной для этого инфраструктуре Заказчика (артефакторий). Запрещается размещение финальных артефактов сборки на сторонних ресурсах 4.4.8. Требования к техническому обеспечению Количество серверов, подключаемых и настраиваемых сервисов, их параметров, схемы соединений и настройки межсетевого взаимодействия должны быть согласованы с Заказчиком на этапе № 1 Техническое проектирование. Доступ к комплексу технических средств предоставляется Заказчиком по письменному запросу Подрядчика. Применяемые в Системе программно-аппаратные и аппаратные комплексы должны соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации», требованиям Постановления Правительства Российской Федерации от 23 декабря 2024 г. № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц». Модуль СЦ, работающий в составе АСУ ТК, развернут на вычислительных мощностях ГЦОД СИЦ Минтранса России 4.5. Общие технические требования 4.5.1. Требования к численности и квалификации персонала и пользователей Модуля СЦ Программное обеспечение Модуля СЦ не должно требовать изменения штатной численности персонала Заказчика. Программное обеспечение Модуля СЦ не должно требовать наличия у пользователей дополнительной квалификации в сфере информационных технологий, кроме базовых знаний в обращении с персональным компьютером, базовых навыков работы в интернет-обозревателях и знаний о Модуле СЦ в объеме документов Руководство пользователя, Руководство администратора 4.2.4. Создание компонента «Интерактивная карта» (2 очередь) В составе создаваемого компонента должны отображаться данные, доступные в компоненте визуализации. Требования к интерфейсу интерактивной карты: – интерактивная карта должна быть представлена в виде объемной карты с учетом макетов, представленных в Приложении А к ТЗ; – интерфейс должен корректно отображаться на экранах мониторов (разрешение Full HD 1920?1080), телевизоров (разрешение 4К 3840?2160), жидкокристаллических панелей для видеостены, используемой Заказчиком, с параметрами каждой панели: диагональ 55 дюймов, разрешение 1920x1080; – интерфейс должен корректно отображаться на планшетных устройствах с диагональю экрана 10-12 дюймов, конкретные требования должны быть уточнены на этапе технического проектирования; – должна быть обеспечена кластеризация и генерализация отображения объектов на карте при изменении масштаба; – должно быть обеспечено отображение основных характеристик объектов при выборе их на карте; – должно быть обеспечено управление отображением слоев на карте; – должна быть обеспечена настройка цветовой индикации отображаемых объектов транспортной инфраструктуры; – должно быть обеспечено отображение легенды карты, содержащей отображаемые объекты на карте; – должна быть обеспечена возможность одновременного отображения не менее 5 000 ОТИ и ТС на карте. На интерактивной карте должны быть отображены подвижные объекты совместно с объектами транспортной инфраструктуры (ОТИ), включая следующие возможности: § отображение местоположения транспортных средств (воздушный, водный и автомобильный транспорт) на карте в режиме реального времени (с заданным периодом обновления данных); § отображение маршрутов движения всех ТС за выбранный период времени, в том числе с использованием эффектов анимации; § отображение маршрутов движения ТС, связанных с карточкой события: ТС, являющихся участниками события, и ТС, находящиеся в заданном радиусе от события; § управление отображением сущностей и ОТИ на карте, включая настройку состава отображаемых объектов, поиск, фильтрацию, с использованием соответствующей панели управления и наглядным представлением результатов; § автоматическое изменение вида отображения объектов (цветовая индикация) по заданным условиям (например, при достижении критических значений параметров, характеризующих функционирование объекта); Должна обеспечиваться производительность обновления изображения на экране в 30 кадров в секунду на тестовой конфигурации пользовательского устройства (модель Бештау AIO2402/B560, входящая в Реестр российской промышленной продукции под номером 10394100 или аналог) при одновременном отображении не менее 5 000 объектов и 200 уникальных моделей объектов. Макеты интерфейсов Модуля СЦ должны быть предварительно согласованы с Заказчиком и разработаны с учетом требований ГОСТ Р ИСО 9241-161-2016 «Элементы графического пользовательского интерфейса» 4.5.2. Требования к режимам функционирования Модуля СЦ Модуль СЦ должен предусматривать наличие следующих режимов работы: – штатный; – регламентный (профилактический); – аварийный. Основным режимом функционирования является штатный. В штатном режиме все компоненты корректно и полностью выполняют свои функции. Перерывов в работе как Модуля СЦ в целом, так и одного, либо нескольких компонентов не предусмотрено. Режим регламентного (профилактического) обслуживания предназначен для проведения работ по обновлению и техническому обслуживанию компонентов Модуля СЦ, а также резервному копированию данных. При работе в данном режиме допускаются перерывы в работе Модуля СЦ с предварительным информированием пользователей. Состав процедур по регламентному обслуживанию Модуля СЦ и их периодичность определяются Подрядчиком в процессе выполнения работ по созданию Модуля СЦ. В режиме регламентного (профилактического) обслуживания Модуль СЦ может функционировать с частичным ограничением своих функциональных возможностей, либо без ограничения, но со снижением показателей надежности и производительности. Перевод в данный режим работы должен осуществляться сразу после начала выполнения любой операции, отнесенной к этому режиму, с последующим возвратом в штатный режим функционирования сразу после ее завершения. Перевод в указанный режим должен осуществляться при возникновении необходимости проведения работ по обновлению и техническому обслуживанию компонентов Модуля СЦ, а также резервному копированию данных с условием предварительного оповещения пользователей. Аварийный режим функционирования характеризуется отказом одной или нескольких подсистем, вызванных выходом из строя аппаратного и/или программного обеспечения, а также в случае временной неработоспособности каналов связи между серверами. В аварийном режиме осуществляется поиск неисправностей и проведение работ по их устранению. Перевод в аварийный режим должен осуществляться при возникновении сбоев, аварий и прочих незапланированных воздействий, сразу после наступления одной или нескольких аварийных ситуаций, с последующим возвратом в штатный режим функционирования сразу после окончания восстановительных работ. ПО Модуля СЦ должно обладать надежностью, обеспечивающей работу пользователей в произвольном режиме и оперативное восстановление работоспособности при сбоях. В целях обеспечения надежного функционирования ПО должно предусматривать: – сохранение целостности данных при нештатном завершении работы компонентов Модуля СЦ; – сохранение работоспособности программного обеспечения при некорректных действиях пользователя; – резервное копирование базы данных Модуля СЦ. – время восстановления работоспособности Модуля СЦ после отказа не более 4 часов. – отказоустойчивость на уровне 99% при единовременной количестве не менее 200 пользовательских сессий в Модуле СЦ. Указанные характеристики приведены без учета характеристик надежности инфраструктуры и времени передачи информации по каналам связи. При возникновении сбоев в аппаратном обеспечении, включая аварийное отключение электропитания, Модуль СЦ должен автоматически восстанавливать свою работоспособность (не требовать перенастройки) после устранения сбоев и корректного перезапуска аппаратного обеспечения 4.2.4.1. Требования к технической реализации компонента «Интерактивная карта» При реализации компонента «Интерактивная карта» должны учитываться требования, указанные ниже. 4.2.4.1.1. Требования к отображению элементов Повторяющихся элементы карты (ТС, ОТИ, события и пр.) должны отрисовываться с использованием аппаратного создания экземпляров объектов на пользовательском устройстве (WebGL/WebGPU)). Отрисовка каждого объекта отдельным запросом не допускается, должна обеспечиваться возможность одновременного отображения не менее 5 000 объектов без снижения производительности (30 кадров в секунду на тестовой конфигурации). 4.2.4.1.2. Уровни детализации объектов Для управления отображением сложных объектов должно быть создано не менее 3-х уровней детализации, отображаемых при изменении масштаба с возможностью автоматического переключения между уровнями. Все отображаемые объекты должны масштабироваться с учетом разрешения экрана пользователя с сохранением качества детализации. 4.2.4.1.3. Полигональная оптимизация и текстурирование При реализации компонента «Интерактивная карта» должна обеспечиваться технология рельефного тестурирования объектов. Не должны использоваться высокополигональные трехмерные модели. Все повторяющиеся элементы должны генерироваться единоразово и повторно использоваться при последующих отображениях. 4.2.4.1.4. Управление памятью Требуется реализовать потоковую загрузку на устройство пользователя элементов карты и текстур. Загрузка данных целиком при старте приложения не допускается. Необходимо реализовать механизм очистки памяти от элементов, которые находятся вне области видимости камеры в течение заданного времени. 4.2.4.1.5. Требования к взаимодействию пользователя с интерфейсом компонента «Интерактивная карта» Программная реализация механизмов управление камерой (масштабирование и навигация) должна быть выполнена с поддержкой технологии WebAssembly (WASM). Элементы управления должны являться неотъемлемой частью интерактивной карты. 4.2.5. Развитие компонента администрирования (3 очередь) Должна быть выполнена доработка ролевой модели. Ролевая модель должна обеспечивать управление доступом к отдельным объектам Модуля СЦ и их элементам (атрибутам) с разграничением по видам транспорта, регионам и пр., в частности: – определение набора конкретных действий, доступных пользователям (выполняемых над объектом доступа, например, удаление записи, редактирование записи, формирование отчета и др.); – реализация возможности объединения пользователей в группы; – определение прав доступа для групп пользователей; – реализация интерфейса визуальной настройки прав доступа пользователей к объектам Модуля СЦ Технические меры по обеспечению надежности должны предусматривать: – резервирование критически важных компонентов и данных Системы и отсутствие единой точки отказа; – использование программного резервирования (программной избыточности); – изменение конфигурации используемых средств и применение специализированного ПО, обеспечивающего высокую надёжность. Организационные меры по обеспечению надежности должны быть направлены на минимизацию ошибок пользователей (а также обслуживающего персонала при эксплуатации и проведении работ по обслуживанию), минимизацию времени ремонта или замены вышедших из строя компонентов за счёт: – обеспечения для обслуживающего персонала требуемого уровня квалификации; – регламентации и нормативного обеспечения выполнения работ обслуживающим персоналом; – своевременной диагностики неисправностей. Расчетное значение коэффициента доступности Модуля СЦ должно составлять не менее 0,95. 4.5.3. Требования по диагностированию Модуля СЦ Диагностирование Модуля СЦ должно осуществляться путем анализа записей в системных журналах СУБД, операционных систем серверов, а также с помощью встроенных средств диагностирования общего программного обеспечения Модуля СЦ. Диагностированию подлежат: – сбои и нарушения функционирования технического обеспечения (серверов) Модуля СЦ; – сбои и нарушения функционирования системного программного обеспечения серверов, используемых для работы Модуля СЦ; – сбои и нарушения функционирования прикладного программного обеспечения серверов, используемых для работы Модуля СЦ; – случаи недоступности (отсутствия ответа) или некорректные ответы внешних систем; – сбои и нарушения функционирования СУБД; – сбои при выполнении регламентных операций резервного копирования. При возникновении аварийных ситуаций либо ошибок в программном обеспечении диагностические инструменты должны позволять сохранять набор информации, необходимой для идентификации и устранения проблемы. Модуль СЦ и ее компоненты должны обеспечивать возможность диагностики своей работоспособности с возможностью интеграции с модулем мониторинга АСУ ТК. Набор передаваемых журналов и метрик должен быть определен на этапе технического проектирования 4.5.4. Требования к надежности Должно быть предусмотрено сохранение работоспособности Модуля СЦ при некорректных действиях пользователя и сохранение целостности данных при нештатном завершении работы Модуля СЦ (отказ рабочей станции, потеря сетевого доступа и т.п.). Модуль СЦ должен предоставлять механизмы обеспечения сохранности данных через применение процедур резервного копирования и восстановления, описанных в документации на Систему. Ключевые показатели надежности информационной системы — допустимое время на восстановление работоспособности Модуля СЦ (RTO - recovery time objective) и/или допустимый интервал времени потери изменений в данных при сбоях/отказах (RPO – recovery point objective) должны быть определены Подрядчиком и согласованы с Заказчиком на этапе технического проектирования 4.2.6. Взаимосвязи с внешними автоматизированными системами (1 очередь) Способы взаимодействия с внешними информационными системами должны быть определены на этапе технического проектирования. Должны быть выполнены следующие доработки: – интеграции с информационными ресурсами в целях получения данных о движении подвижных ТС (воздушные суда, суда водного транспорта); – интеграция с информационным ресурсом в целях получения данных о событиях на железнодорожном транспорте. Реализация интеграций должна включать проектирование и реализацию интеграционных механизмов обмена данными с учетом доступных вариантов реализации, обеспечение защищенных способов взаимодействия, настройку отображения отдельных данных на карте (настройка слоев). Взаимодействия, имеющие каналы связи, выходящие за пределы контролируемой зоны взаимодействующих систем, считаются защищенными, если для их защиты используются программные и/или программно-аппаратные шифровальные (криптографические) средства, сертифицированные ФСБ России (далее – СКЗИ). Выбор СКЗИ, схемы подключения и требуемого класса криптостойкости должен производиться в соответствии с Техническими условиями на подключение к информационным ресурсам ФГБУ «СИЦ Минтранса России» и инструкциями по подключению пользователей к ресурсам инфраструктуры Головного центра обработки данных, утвержденных приказом директора ФБГУ «СИЦ Минтранса России» от 24.05.2024 № 21-ОД 4.3. Требования к оказанию услуг по технической поддержке Модуля СЦ 4.3.1. Общие требования к оказанию Услуг Техническая поддержка Модуля СЦ должна осуществляться с учетом требований постановления Правительства Российской Федерации от 06.07.2015 N 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации». Подрядчик обязан выполнять требования законодательства в сфере защиты информации, требования по защите информации, информационной безопасности, указанные в локальных нормативных актах ФГБУ «СИЦ Минтранса России», регламентирующих условия информационного взаимодействия, защиты информации и подключения к информационным ресурсам ФГБУ «СИЦ Минтранса России», участвующих в информационном взаимодействии в рамках оказания услуг по технической поддержке АСУ ТК в 2026 году 4.3.1.1. Требования к составу и содержанию услуг третьего уровня технической поддержки Оказание услуг по технической поддержке Системы осуществляется в рамках этапов в соответствии с календарным планом. Подрядчик в течение 5 рабочих дней с даты заключения Контракта должен предоставить со своей стороны, а Заказчик со своей стороны Матрицу ответственных за взаимодействия в соответствии с Приложением 1 к Регламенту оказания услуг по третьему уровню технической поддержки Модуля СЦ (далее – Регламент, Приложение В). Подрядчик в течение 10 рабочих дней с даты заключения Контракта должен провести мероприятия по организации третьего уровня технической поддержки в соответствии с Регламентом. Услуги по третьему уровню технической поддержки Модуля СЦ должны включать: – организацию Подрядчиком третьего уровня технической поддержки; – информационно-консультационную поддержку работников Заказчика; – решение инцидентов, связанных с работой ППО; – адаптационное, конфигурационное и коррекционное сопровождение Модуля СЦ (в рамках действующих программных модулей и функциональности); – устранение уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности 4.5.5. Требования к информационной безопасности Работы по защите информации/информационной безопасности, не включенные в состав настоящего раздела, требуемые в соответствии с требованиями постановления Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации», а также нормативно правовых актов в области защиты персональных данных и обеспечения безопасности объектов критической информационной инфраструктуры, будут проведены в рамках исполнения отдельного контракта, заключенного по результатам отдельной закупочной процедуры (не является частью данного ТЗ), включающего: – определение актуальных угроз безопасности информации и актуализация модели угроз безопасности информации (при необходимости); – выполнение требований о согласовании технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России в установленном порядке; – выполнение требований по устранению Подрядчиком замечаний и недостатков, в случае их выявления при согласовании Заказчиком технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России; – выполнение требований к классу защищенности ГИС, уровню защищенности персональных данных и категории значимости объекта КИИ РФ, установленных для Головного центра обработки данных ФГБУ «СИЦ Минтранса России» (далее – ГЦОД); – определение перечня объектов защиты информационной системы; – описание (актуализированных) требований к системе защиты информации, а также к мерам защиты информации информационной системы в зависимости от установленных классов защищенности, уровня защищенности персональных данных и категории значимости объектов КИИ РФ (приказы ФСТЭК России № 21, 117, 239); – выполнение требований к мерам по защите ГИС от атак, направленных на отказ в обслуживании, в соответствии с пунктами 30, 34, 59, 63 Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений, утвержденных приказом ФСТЭК России от 11.04.2025 № 117; – описание (актуализированных) требований по защите информации, подлежащих реализации в информационно телекоммуникационной инфраструктуре ГЦОД; – выполнение требований о применении сертифицированных средств защиты информации, включая их классы защиты и уровни доверия; – выполнение требований о запрете использования с 01.01.2025 органами (организациями) средств защиты информации странами происхождения, которых являются иностранные государства в соответствии с пунктом 6 Указа Президента Российской Федерации от 01.05.2022 № 250; – выполнение требований по обеспечению непрерывного взаимодействия с ГосСОПКА в установленном порядке; 5. СОСТАВ И СОДЕРЖАНИЕ РАБОТ ПО РАЗВИТИЮ И ТЕХНИЧЕСКОЙ ПОДДЕРЖКЕ МОДУЛЯ СЦ (КАЛЕНДАРНЫЙ ПЛАН) Сдача-приемка результатов выполненных работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная техническая документация, а также результаты работ предоставляются Заказчику в порядке, предусмотренном Контрактом и ТЗ, до размещения Подрядчиком в ЕИС документа о приемке. Документ о приемке размещается в ЕИС по каждому этапу в соответствии с условиями Контракта. Этапы выполнения работ по развитию Модуля СЦ приведены в Таблице 11. Таблица 11. Этапы выполнения работ по развитию Модуля СЦ. № этапа Наименование этапа Результат (отчетная документация) Срок исполнения этапа Значение характеристики не может изменяться участником закупки 1 Техническое проектирование Сопроводительным письмом предоставляются Заказчику: · Технический проект, включая следующие документы: – Ведомость технического проекта; – Ведомость машинных носителей информации – Пояснительная записка; – Описание информационного обеспечения системы; – Описание автоматизируемых функций; – Схема функциональной структуры; – Описание организации информационной базы; – Описание программного обеспечения; · Макеты экранных форм компонента «Интерактивная карта»; · Руководство по безопасной разработке программного обеспечения; · Документ о приемке Начало: с даты заключения контракта Окончание: не позднее 31.07.2026 2 Услуги по технической поддержке Модуля СЦ (с даты заключения контракта по 10.09.2026) По окончании оказания Услуг сопроводительным письмом предоставляются Заказчику: – Отчет об оказанных Услугах по технической поддержке; – Актуальные на дату окончания оказания Услуг по данному этапу исходные коды прикладного ПО на электронном носителе (в случае внесения изменений); – Инструкция по сборке и развертыванию (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство пользователя (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство администратора (в случае внесения изменений); – Документ о приемке Начало: с даты заключения контракта Окончание: не позднее 10.09.2026 3 Разработка программного обеспечения (1 очередь, пп. 4.2.1, 4.2.6 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ; – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 1 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 1 очереди; – Руководство по резервному копированию; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 16.09.2026 4 Разработка программного обеспечения (2 очередь, пп. 4.2.3, 4.2.4 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ. – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 2 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 2 очереди; – Руководство по резервному копированию; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 25.09.2026 5 Разработка программного обеспечения (3 очередь, пп. 4.2.2, 4.2.5 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ; – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 3 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 3 очереди; – Руководство по резервному копированию; – Описание ролевой модели; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 09.10.2026 6 Опытная эксплуатация (1 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акт о завершении опытной эксплуатации 1 очереди; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке 17.09.2026 Окончание: не позднее 26.10.2026 7 Опытная эксплуатация (2 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акт о завершении опытной эксплуатации 2 очереди; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке 26.09.2026 Окончание: не позднее 26.10.2026 8 Опытная эксплуатация (3 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Акт о завершении опытной эксплуатации 3 очереди; – Документ о приемке Начало: с 10.10.2026 Окончание: не позднее 26.10.2026 9 Приемочные испытания Сопроводительным письмом предоставляются Заказчику: – Программа и методика приёмочных испытаний; – Протокол приемочных испытаний; – Исходные коды и дистрибутивы на электронном носителе (при условии внесения изменений, с учетом доработок по результатам опытной эксплуатации и проведенных испытаний); – Комплект рабочей документации на Модуль СЦ (при условии внесения изменений, с учетом доработок по результатам опытной эксплуатации и проведенных испытаний); – Акт приемки Системы в эксплуатацию; – Акт приемки-передачи исключительных прав на объект; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке; – Документы в соответствии с разделом 4.5.9 ТЗ; – Обеспечение гарантийных обязательств Начало: с 27.10.2026 Окончание: не позднее 10.11.2026 10 Услуги по технической поддержке Модуля СЦ (с 11.09.2026 по 15.12.2026) По окончании оказания Услуг сопроводительным письмом предоставляются Заказчику: – Отчет об оказанных Услугах по технической поддержке; – Актуальные на дату окончания оказания Услуг по данному этапу исходные коды прикладного ПО на электронном носителе (в случае внесения изменений); – Инструкция по сборке и развертыванию (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство пользователя (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство администратора (в случае внесения изменений); – Документ о приемке Начало: с 11.09.2026 Окончание: не позднее 15.12.2026 Работы по развитию Системы (за исключением этапов проведения опытной эксплуатации и услуг по технической поддержке) могут быть выполнены досрочно. При досрочном выполнении работ (этапов работ) Подрядчик в письменной форме уведомляет Заказчика о готовности представить для приемки результаты проведения работ в соответствии с требованиями Контракта. Подрядчик также вправе досрочно приступать к работам в рамках очередного этапа при наличии технической, организационной готовности - при условии получения соответствующего согласования Заказчиком. Сдача-приемка результатов выполненных работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная, техническая документация, а также результаты Работ по каждому этапу предоставляется Заказчику в порядке, предусмотренном Контрактом и настоящим Техническим заданием, до размещения Подрядчиком в Единой информационной системе в сфере закупок документа о приемке. Документ о приемке размещается в ЕИС по каждому этапу в соответствии с условиями Контракта. Согласование документов осуществляется в электронном виде посредством переписки с адресов электронной почты Заказчика и Подрядчика, указанных в контракте. 6. ПОРЯДОК РАЗРАБОТКИ МОДУЛЯ СЦ Проектирование Модуля СЦ должно включать разработку следующих документов: – Ведомость технического проекта; – Ведомость машинных носителей информации – Пояснительная записка; – Описание информационного обеспечения системы; – Описание автоматизируемых функций; – Схема функциональной структуры; – Описание организации информационной базы; – Руководство по безопасной разработке программного обеспечения; – Описание программного обеспечения; – Макеты экранных форм компонента «Интерактивная карта». Структура документов должна соответствовать ГОСТ Р 59795-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов». Разработка Модуля СЦ должна включать в себя: – разработку программного обеспечения в части новых функций Модуля СЦ; – сборка исходного кода, развертывание и настройку доработанного программного обеспечения Модуля СЦ на вычислительных мощностях Заказчика (тестовый контур); – Комплект рабочей документации на Модуль СЦ; – разработку документа «Программа и методика предварительных испытаний»; – разработку документа «Программа и методика приемочных испытаний»; – разработку документа «Программа опытной эксплуатации». Структура документов должна соответствовать ГОСТ Р 59795-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов». В ходе выполнения работ формируется правоустанавливающая, отчетная, рабочая и техническая документация в соответствии с Контрактом и Календарным планом, приведенном в разделе 5. Значение характеристики не может изменяться участником закупки 6.1. Сведения о гарантийном обслуживании Модуля СЦ Под гарантией понимается устранение Подрядчиком своими силами и за свой счет допущенных по его вине недостатков, выявленных после приемки выполненных Работ, как в работе самой Модуля СЦ, так и недостатков в отчетной документации. Если в период гарантийного срока обнаружатся недостатки, то Подрядчик обязан устранить их за свой счет, в сроки, установленные Заказчиком. Гарантийный срок в этом случае продлевается на период устранения недостатков. Срок гарантии: 1 год с даты приемки Заказчиком результатов исполнения Этапа № 9 контракта. Подрядчиком должны быть внесены соответствующие исправления в техническую и рабочую документацию (указанную в пунктах 5 и 6 настоящего ТЗ), связанные с устранением замечаний к работе Модуля СЦ или в случае выявления Заказчиком недостатков в такой документации в период гарантийного срока. Внесение изменений в документацию технического и рабочего проектирования осуществляется в соответствии с ГОСТ 2.503-2023 и ГОСТ Р 2.504-2021. 7. ПОРЯДОК КОНТРОЛЯ И ПРИЕМКИ РЕЗУЛЬТАТОВ ВЫПОЛНЕНИЯ РАБОТ ПО РАЗВИТИЮ МОДУЛЯ СЦ Испытания должны быть организованы и проведены в соответствии с ГОСТ Р 59792-2021 «Информационная технология. Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем». Должны быть проведены следующие виды испытаний: – предварительные испытания; – опытная эксплуатация; – приемочные испытания. Указанные виды испытаний проводятся в отношении не функциональных требований и функциональных возможностей, разрабатываемых в соответствии с настоящим ТЗ. Отдельные виды испытаний проводятся поэтапно в сроки, установленные Календарным планом. Предварительные испытания, опытная эксплуатация, приемочные испытания проводятся комиссией, создаваемой организационно-распорядительным документом Заказчика, который должен определять состав комиссии, порядок ее работы. Методы предварительных испытаний и порядок их проведения должны быть определены в документе «Программа и методика предварительных испытаний», который должен быть утвержден Заказчиком до начала предварительных испытаний. По результатам предварительных испытаний оформляется Протокол предварительных испытания и Акт о приемке в опытную эксплуатацию. Порядок проведения и методы испытаний во время опытной эксплуатации должны быть определены в документе «Программа опытной эксплуатации», который должен быть утвержден Заказчиком до начала опытной эксплуатации. Ход и результаты опытной эксплуатации отражаются в документе «Журнал опытной эксплуатации», и учитываются в ходе приемочных испытаний. По результатам опытной эксплуатации подписывается Акт о завершении опытной эксплуатации Значение характеристики не может изменяться участником закупки До момента подключения внешних ИС, Подрядчиком могут быть использованы эмуляторы ИС для прохождения предварительных испытаний, опытной эксплуатации и приемочных испытаний. В рамках опытной эксплуатации должны быть проведены мероприятия по нагрузочному тестированию Модуля СЦ. Документ «Программа и методика приемочных испытаний» должен быть разработан с учетом недостатков, выявленных в ходе опытной эксплуатации, утвержден Заказчиком до начала приемочных испытаний, при этом проверки Модуля СЦ в части не устраненных недостатков, выявленных в процессе опытной эксплуатации, должны быть вынесены в отдельный раздел «Программы и методики приемочных испытаний». В процессе приемочных испытаний должно быть проверено устранение недостатков, полученных в ходе опытной эксплуатации. После завершения устранения всех замечаний, препятствующих приемке Системы в эксплуатацию, перечисленных в Протоколе приемочных испытаний, Подрядчик должен письменно уведомить Заказчика о том, что все замечания устранены, после чего приемочные испытания по решению Заказчика могут быть проведены повторно. Процедура приемочных испытаний проводится до подписания Протокола приемочных испытаний, не содержащего замечаний, препятствующих приемке Системы в эксплуатацию. Приемочные испытания Системы считаются завершенными успешно, если Протокол приемочных испытаний не содержит замечаний, препятствующих приемке Системы в эксплуатацию 8. ТРЕБОВАНИЯ К СОСТАВУ И СОДЕРЖАНИЮ РАБОТ ПО ПОДГОТОВКЕ МОДУЛЯ СЦ К ВВОДУ В ЭКСПЛУАТАЦИЮ По результатам проведения приемочных испытаний оформляется Протокол приемочных испытаний и Акт приемки в эксплуатацию. В случае, если взаимодействие с внешними системами не может быть проверено на средах постоянной эксплуатации взаимодействующих систем (по причине неготовности со стороны внешней системы или иным причинам), функции взаимодействия, разработанные в соответствии с требованиями ТЗ, должны быть проверены на тестовых данных с использованием программ-имитаторов взаимодействия. По результатам выполнения этапа приемочных испытаний должны быть подготовлены материалы для регистрации доработанной версии Модуля СЦ (объекта учета) в НФАП в соответствии с требованиями постановления Правительства Российской Федерации от 30 января 2013?г. №?62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин» (с изменениями и дополнениями) в части обязательности размещения результатов работ в национальном фонде алгоритмов и программ для электронных вычислительных машин. Сдача-приемка результатов выполнения Работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная, техническая документация, а также программное обеспечение предоставляется Заказчику в порядке, предусмотренном Контрактом и ТЗ до размещения Подрядчиком в Единой информационной системе в сфере закупок документа о приемке. Результаты проведения опытной эксплуатации, предварительных и приемочных испытаний должны быть зафиксированы в соответствующих протоколах и актах. Выявленные отклонения от настоящего ТЗ, оформляются как недостатки Модуля СЦ Значение характеристики не может изменяться участником закупки Протоколы предварительных и приемочных испытаний должны содержать вывод о соответствии Модуля СЦ предъявляемым требованиям, а также сроки устранения замечаний и реализации рекомендаций, сформулированных комиссией в ходе предварительных и приемочных испытаний. Условием для передачи Модуля СЦ в промышленную эксплуатацию является устранение всех замечаний. Документация на Модуль СЦ и ее части (техническая и рабочая) должна содержать исчерпывающее описание принятых проектных решений в объеме, достаточном для ее дальнейшего развития и эксплуатации. Техническая и рабочая документация должна содержать описание разработанных результатов работ, в том числе программ для ЭВМ, прикладных программных интерфейсов, алгоритмов и протоколов информационного взаимодействия, технических требований, спецификаций и форматов обмена данными для взаимодействия с другими информационными системами, в объеме, достаточном для их установки, настройки, эксплуатации и развития в дальнейшем без привлечения Подрядчика. Исходные коды передаются в виде и составе, позволяющем провести: – сборку (компиляцию) Модуля СЦ в контролируемой Заказчиком среде; – установку полученной Модуля СЦ на специально подготовленную контролируемую Заказчиком инфраструктуру; – проверку функциональных возможностей Модуля СЦ; – оформление Модуля СЦ в качестве объекта национального фонда алгоритмов и программ для электронных вычислительных машин 8.1. Требования, предъявляемые в соответствии с Приказом Минцифры России от 17.12.2020 № 715 «Об утверждении типовых условий контрактов на выполнение работ по созданию и (или) развитию (модернизации) государственных (муниципальных) и (или) иных информационных систем» Передача исходных кодов, разработанных в ходе выполнения работ, программ для электронных вычислительных машин (далее – программа для ЭВМ) должна сопровождаться передачей всех необходимых для сборки и запуска программы для ЭВМ библиотек зависимостей, программных сценариев (скриптов) для проведения установки (развертывания) программы для ЭВМ. Подрядчик в процессе сдачи-приемки работ по Контракту должен провести демонстрацию процесса и установки (развертывания) разработанных программ для ЭВМ. Документация на Модуль СЦ должна содержать описание принятых проектных решений в объеме, достаточном для ее дальнейшего развития и эксплуатации 9. ТРЕБОВАНИЯ К ДОКУМЕНТИРОВАНИЮ 9.1. Общие требования Документация на Модуль СЦ должна быть разработана в составе, указанном в разделах 5-8 данного ТЗ, и должна удовлетворять требованиям комплекса стандартов и руководящих документов на автоматизированные системы: – ГОСТ Р 2.105-2019 в части оформления текстовых документов; – ГОСТ 34.201-2020 в части наименования и обозначения документов. Документация на Модуль СЦ должны оформляться на листах формата А4. Допускается для размещения рисунков и таблиц использование листов формата А3 с подшивкой по короткой стороне листа. Документы объемом более 25 (двадцати пяти) листов должны содержать информационную часть, состоящую из аннотации и содержания. Исходные коды должны быть представлены в 1 (одном) экземпляре на электронном носителе, отчетные материалы должны быть представлены в 2 (двух) экземплярах на бумажном носителе (по одному экземпляру для Заказчика и Подрядчика) и в 1 (одном) экземпляре на электронном носителе в формате документов DOCX и PDF. При разработке документов на Модуль СЦ допускается отклонение от требований комплекса стандартов, описанных выше. Документам на Модуль СЦ должны в обязательном порядке присваиваться уникальные децимальные номера в соответствии с порядком, установленном в ГОСТ 34.201-2020. Документ «Программа и методика предварительных испытаний» должен включать приложения с формой протокола предварительных испытаний и формой акта приемки в опытную эксплуатацию. Документ «Программа опытной эксплуатации» должен включать приложение с формой журнала опытной эксплуатации. Документ «Программа и методика приемочных испытаний» должен включать приложения с формой протокола приемочных испытаний и формой акта приемки в эксплуатацию Значение характеристики не может изменяться участником закупки 10. ИСТОЧНИКИ РАЗРАБОТКИ 10.1. Список литературы Специальная литература для разработки ТЗ не использовалась. 10.2. Нормативно-методические документы Список используемых нормативно-методических документов представлен в разделе 1.6 технического задания. ? Приложение А Эскизы визуального оформления компонента «Интерактивная карта» Значение характеристики не может изменяться участником закупки Приложение Б Параметры оказания услуг Б.1. Базовые параметры оказания Услуг Базовые параметры оказания Услуг приведены ниже: – режимы оказания Услуг (таблица Б.1.1); – сроки предоставления отчетности (таблица Б.1.2). Таблица Б.1.1 - Режимы оказания Услуг № п/п Параметр Значение Значение характеристики не может изменяться участником закупки 1 Режим работы Системы Круглосуточно (24х7) 2 Режим доступности информационно-консультационной поддержки пользователей Системы 2.1 Прием и регистрация обращений (заявок) в СРО Регистрация обращений (заявок) производится круглосуточно в режиме 24х7, без праздников и выходных дней. Обработка заявок первой линией поддержки осуществляется в рабочие дни с 9 до 18 часов 2.2 Консультирование сотрудников Заказчика и пользователей Системы в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 3 Режим доступности по решению инцидентов, связанных с работой ППО: 3.1 - приоритет «Критический» Круглосуточно (24х7) 3.2 - приоритет «Высокий» Круглосуточно (24х7) 3.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 3.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4 Режим доступности услуг по адаптации, конфигурации и коррекционному сопровождению Системы 4.1 - приоритет «Критический» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.2 - приоритет «Высокий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 5 Режим доступности по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности 5.1 - приоритет «Критический» Круглосуточно (24х7) 5.2 - приоритет «Высокий» Круглосуточно (24х7) 5.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 5.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) Таблица Б.1.2. Сроки предоставления отчетности, с момента получения запроса № п/п Параметр Значение 1 Предоставление отчета об оказанных услугах за произвольный период 10 рабочих дней 2 Предоставление подробной информации по инциденту с приоритетом «Критический» 16 рабочих часов 3 Предоставление актуализированной документации 10 рабочих дней Б.2. Приоритеты и регламентные сроки решения обращений (заявок) В зависимости от уровня сбоя в работе Системы обращению (заявке) присваивается один из следующих приоритетов, а также в зависимости от приоритета обращения (заявки) устанавливаются следующие контрольные сроки решения в соответствии с таблицей ниже (Таблица Б.2.1). Таблица Б.2.1 – Приоритеты и регламентные сроки решения обращений (заявок) № п/п Приоритет Максимальное время реагирования Время решения (срок выполнения) Описание приоритета По информационно-консультационной поддержке сотрудников Заказчика и пользователей Системы 1 - не более 1 часа не более 10 часов - По решению инцидентов, связанных с работой ППО: 1 Критический не более 30 минут не более 4 часов - полная недоступность ППО; - недоступность ключевых функций - ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО; - невозможность информационного обмена с ППО для ИС более 4 часов 2 Высокий не более 1 часа не более 8 часов - ошибки/сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; - снижение быстродействия СПО (время отклика ППО на операции превышает 30 секунд); - недоступность управления правами и ролями пользователей 3 Средний не более 4 часов не более 24 часов - невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым -недоступность функции формирования отчетов 4 Низкий не более 8 часов не более 40 часов - отклонение в работе ППО, не влияющее на корректную работу функций; - другие сбои и ошибки, затрагивающие основные функции ППО По адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) 1 Критический не более 40 минут не более 8 часов - изменения, необходимые при проведении аварийно-восстановительных работ для возобновления работоспособности Системы; - изменения, связанные с критичными ошибками, блокирующими возможность оказания государственных услуг и/или чтение и внесение данных в Систему 2 Высокий не более 1 часа не более 40 часов - изменения, относящиеся к обеспечению работоспособности основной функциональности Системы, устраняют выявленные дефекты в работе Системы, оказывающие существенное влияние на работу пользователей в Системе; - изменения, затрагивающие три и более подсистемы/модуля Системы для адаптации 3 Средний не более 4 часов не более 72 часов - изменения, связанные с развитием/улучшением/оптимизацией Системы и выводом новой функциональности в штатном режиме для одного-двух модулей/подсистем; - изменения, связанные с развитием интеграционных механизмов Системы, например обновление существующих и/или реализация новых видов сведений СМЭВ, обновление существующих и/или реализация новых API, адаптация и/или изменение механизмов импорта и экспорта данных Системы и т.д. 4 Низкий не более 8 часов не более 160 часов - изменения, связанные с ошибками/корректировкой/изменением в отображении информации в пользовательском графическом интерфейсе Системы (графика, текст, органы управления, элементы интерфейса) По устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности 1 Критический не более 30 минут не более 24 часов - критические уязвимости, влияющие на возможную полную недоступность ППО, ключевых функций Системы, ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО без возможности восстановления работоспособности Системы. - Критический уровень CVSS > 8.0 2 Высокий не более 1 часа не более 84 часов - критические уязвимости, влияющие на ошибки и сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО. - Высокий уровень CVSS 5.0 - 8.0 3 Средний не более 4 часов не более 120 часов - уязвимости, влияющие на невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым - Средний уровень CVSS 2.0 - 4.9 4 Низкий не более 8 часов не более 160 часов - уязвимости, влияющие на отклонение в работе ППО, не влияющее на корректную работу функций; - другие сбои и ошибки, затрагивающие основные функции ППО - Низкий уровень CVSS < 2.0 Взаимодействие Заказчика и Подрядчика в части регистрации и контроля времени реагирования и решения обращения (заявки) осуществляется через СРО. Заказчик предоставляет Подрядчику доступ к СРО после заключения Контракта. Поступившие от разных пользователей заявки по поводу однотипных инцидентов или имеющие общую причину должны объединяться в одну заявку. Срок выполнения включает время диагностики инцидента, в ходе которого определяется причина инцидента (проблемы) и способ его устранения. Подрядчик должен обеспечить функционирование Модуля СЦ в соответствии с требованиями и параметрами, указанными в настоящем ТЗ и Регламенте оказании услуг. Основные параметры быстродействия типовых операций в Модуле СЦ указаны в таблице ниже (таблица Б.2.2). Таблица Б.2.2 - Параметры быстродействия Модуля СЦ № п/п Наименование параметра Значение (секунд) 1 Среднее время получения сообщения из очереди сообщений 10 2 Среднее время получения ответа от Системы 5 3 Среднее время открытия карточки реестра 5 Приложение В Регламент оказания услуг Термины и сокращения В настоящем регламенте используются следующие термины и сокращения на русском и английском языках: Термины/сокращения Полное наименование/описание БЗ (База знаний) База данных Системы регистрации обращений (заявок), созданная для сбора, хранения и поиска способов решения известных проблем в рамках Системы Жизненный цикл обращения (заявки) Совокупность статусов, по которым проходит обращение (заявка), и правила перехода обращения (заявки) из одного статуса в другой Заказчик ФГБУ «СИЦ Минтранса России» – Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» ЗНИ Запрос на изменение – тип заявки, предполагающий внесение изменений в прикладное программное обеспечение Системы ЗНО Запрос на обслуживание – тип заявки, предполагающий работы по предоставлению консультации, предоставление доступа к Системе или стандартизированные типовые изменения конфигураций Системы Инцидент Тип заявки, классифицируемый как нештатное событие в работе компонентов функциональных задач Системы, которое привело или может привести к нарушению или снижению качества функционирования Системы ИС Информационная система Исполнитель Организация, которая определяется по результатам конкурсных процедур Классификация Анализ и заполнение классификационных полей справочными значениями, определяющими последовательность действий и этапов жизненного цикла заявки, а также порядок рассмотрения заявок Консультация Разъяснения по алгоритму работы, требуемых настроек прикладного программного обеспечения и технологии обработки данных при работе с Системой, предоставление информации Маршрутизация Определение процесса движения обращения (заявки) в Системе управления заявками между уровнями технической поддержки и организационными структурами на уровнях поддержки путем назначения обращения (заявки) в соответствии с его классификацией и выставленным приоритетом Значение характеристики не может изменяться участником закупки Обращение (заявка) Устное или письменное обращение пользователя АСУ ТК с вопросом, касающимся работоспособности АСУ ТК, по одному из определённых каналов связи: электронная почта, Система регистрации обращений (заявок) Пользователь Инициатор обращения (заявки) или пользователь Системы ППО Прикладное программное обеспечение Предмет обращения Справочник, классифицирующий типовые запросы в Системе регистрации обращений (заявок), характерные для Системы, выбранное значение определяет маршрутизацию обращения (заявки) (группу ответственных сотрудников) Приоритизация Значение, определяющее время, очередность решения обращений (заявок), ресурсы, привлекаемые для решения обращений (заявок), . Приоритет устанавливается в соответствии с масштабом выявленной проблемы, которая привела или может привести к нарушению или снижению качества функционирования Системы Релиз Выпуск версии прикладного программного обеспечения Системы, от разработки до тестирования и планового обновления Системы на продуктивной среде для установки изменений, связанных с развитием/улучшением/оптимизацией Системы Система, АСУ ТК, Информационно-аналитическая система регулирования на транспорте Информационно-аналитическая система, предназначенная для автоматизации и информационно-аналитического обеспечения процессов управления развитием транспортного комплекса Российской Федерации, обеспечения публичности деятельности органов государственного управления транспортным комплексом, а также обеспечения процессов оказания государственных услуг в электронном виде в сфере транспорта СМЭВ Система межведомственного электронного взаимодействия СПО Системное программное обеспечение СРО Система регистрации обращений (заявок) Статус обращения (заявки) Текущее состояние обращения (заявки) в жизненном цикле процесса оказания технической поддержки Системы СУБД Система управления базами данных Уровень технической поддержки Организационно-структурная часть технической поддержки, имеющая определённые организационно-нормативными документами зоны ответственности, обязанности, а также временные нормативы, в течение которых эти обязательства должны выполняться либо эскалироваться на следующий уровень технической поддержки Услуги Услуги по технической поддержке Информационно-аналитической системы регулирования на транспорте АСУ ТК ФИО Фамилия, имя, отчество Эскалация Процедура повышения внимания к обращению (заявке) путем повышения его приоритета и/или передачи на следующий уровень технической поддержки, а также привлечение ролей, которые могут принимать решения без передачи на следующий уровень технической поддержки API Англ. Application Programming Interface — программный интерфейс приложения, интерфейс прикладного программирования — описание способов (набор классов, процедур, функций, структур или констант), которыми одна компьютерная программа может взаимодействовать с другой программой CVSS Англ. Common Vulnerability Scoring System - открытый стандарт, используемый для расчета количественных оценок уязвимости в безопасности компьютерной системы, обычно с целью понять приоритет ее исправления. В современном инструментарии информационной безопасности используется версия 3.0 и выше с дополнительными метриками к базовым оценкам ID Англ. Identifier – идентификатор, уникальный признак объекта, позволяющий отличать его от других объектов, то есть, идентифицировать SLA Англ. Service Level Agreement - утвержденные условия по обработке обращения (заявки) с установленными метриками времени, которые определяют пороговые значения для эскалации в зависимости от статуса обращения (заявки) (например, время реакции – время от регистрации до осуществления первичной обработки, время решения – время от регистрации обращения (заявки) до его решения и т.д.) SQL Англ. Structured Query Language — «язык структурированных запросов», — декларативный язык программирования, применяемый для создания, модификации и управления данными в реляционной базе данных, управляемой соответствующей СУБД 1 Общие сведения 1.1 Полное наименование Услуг Оказание услуг по технической поддержке Модуля СЦ АСУ ТК в 2026 году. 1.2 Предмет Регламента оказания услуг Требования Технического задания 2 Общие положения 2.1 Цель и задачи оказания услуг Целью технической поддержки Системы является обеспечение ее стабильного и безопасного функционирования и эксплуатации, предупреждение, выявление и устранение сбоев в работе Системы и минимизация их неблагоприятного влияния. Для достижения поставленной цели требуется решение следующих задач: 1. Обеспечение информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы. 2. Поддержание параметров функционирования ППО Системы, удовлетворяющих требованиям производственных процессов, включая их непрерывность. 3. Обеспечение бесперебойного функционирования ППО и своевременное устранение сбоев и аварийных ситуаций в Системе. 4. Своевременное устранение уязвимостей при выявлении таковых, в соответствии с требованиями к обеспечению информационной безопасности. 5. Адаптация, конфигурирование, коррекция программного обеспечения в соответствии с изменениями нормативно-правовой базы и запросами уполномоченных сотрудников органов государственной власти, включая выполнение процедур тестирования и участие в обновлениях ППО на стендах Заказчика. 6. Обеспечение сохранения работоспособности ППО в изменяемой среде эксплуатации. 7. Ведение документации по настоящему контракту и инициирование актуализации документации на Систему по результатам обработки запросов Заказчика и внесения соответствующих изменений в ППО 2.2 Общее описание процесса оказания сопровождения (технической поддержки) Системы Процесс оказания технической поддержки Системы включает: 1. Поступление обращений (заявок) от пользователей и их регистрацию. 2. Сопровождение обращений (заявок) в соответствии с их классификацией и приоритизацией, в том числе, с их последующей эскалацией. 3. Определение ролей и регламент их взаимодействия при осуществлении деятельности по процессу. 4. Решение обращений (заявок) в установленные настоящим Регламентом сроки. 5. Взаимодействие между 1-м, 2-м и 3-м уровнями технической поддержки, в том числе, с формированием заданий для сопровождения Системы. 6. Контроль качества выполняемых Исполнителем работ, состоящий из проверки сценария, приводящего к ошибке, зафиксированной в Инциденте, и/или к ошибке воспроизведения, а также тестирование внесенных изменений в рамках ЗНИ. 7. Обеспечение мониторинга и проведение анализа процесса обработки поступающих в техническую поддержку обращений (заявок). Техническая поддержка реализуется путем проведения ответственными сотрудниками соответствующей информационно-консультационной деятельности в соответствии с определенными ролями, а также выполнения Исполнителем конкретных действий по своевременному выявлению причин сбоев и аварийных ситуаций и их устранению, а также по адаптации, конфигурированию, корректировке Системы, включая выполнение процедур тестирования и участия в обновлениях Системы. Все роли подразделяются на уровни поддержки, взаимодействующие между собой в соответствии с блок-схемой процесса технической поддержки. Общая схема процесса рассмотрения обращений (заявок) в соответствии с видами технической поддержки представлена на рисунке 1. . Рисунок 1 - Общая схема процесса рассмотрения обращений (заявок) в соответствии с видами технической поддержки 2.3 Каналы связи Должна быть предусмотрена омниканальность в части приема обращений (заявок). Получение обращений (заявок) технической поддержкой происходит по следующим каналам связи: – СРО; – электронная почта; – телефонная линия. Исполнитель обеспечивает прием обращений (заявок) от Заказчика и предоставляет информацию в рамках оказания услуг по техническому сопровождению Системы, руководствуясь матрицей взаимодействия, приведенной в Приложении 1 к настоящему Регламенту 3 Порядок оказания Услуг 3.1 Типы обращений (заявок) Обращения и заявки Заказчика классифицируются в соответствии с приоритетами и регламентными сроками, указанными в Приложении 2 к настоящему Регламенту. Регистрация обращений и заявок предусматривает создание новой записи в СРО с присвоением поступившему обращению или заявке (новой записи) уникального идентификатора. Запись в СРО должна содержать вопрос или проблему, которую требуется решить или оказать консультацию. Если обращение или заявка автоматически зарегистрированы в СРО при отправке представителем Заказчика, Исполнитель проверяет корректность указанного типа обращения (заявки) и может обратиться к Заказчику с просьбой корректировки, предоставив обоснования в соответствии с настоящей классификацией (Таблица 1) Таблица 1 - Типы обращений (заявок) Тип обращения (заявки) Описание Запрос на обслуживание Подготовка SQL запроса к СУБД для решения прикладной задачи и д р. – запрос на любое действие, не являющееся запросом информации и несовершенный на основе происшествия, прямо или косвенно влияющего на работу Системы Консультация (входит в тип обращения (заявки) «Запрос на обслуживание») «Где взять / куда обратиться...?», «Как сделать / выполнить…», «Как это работает…?» - запрос, имеющий своей целью получение информационной поддержки Инцидент Разбор ошибок/сбоев и подготовка материалов (корректировочных релизов, инструкций) для Заказчика для устранения ошибок/сбоев, которые приводят к частичному и полному нарушению работоспособности всех или отдельных функций ППО. Подготовка изменения и материалов, необходимых для проведения аварийно-восстановительных работ для возобновления работоспособности Системы. ЗНИ Подготовка изменений, связанных с изменением, улучшением/оптимизацией Системы и выводом новой модифицированной функциональности в штатном режиме. Подготовка изменений, связанных с модификацией существующих и/или реализация новых интеграционных механизмов для получения/обработки данных внешних систем. Подготовка изменений графического интерфейса по требованиям Заказчика 3.2 Участники технической поддержки, осуществляющие сопровождение обращений (заявок) Техническая поддержка Системы должна быть организована на трех уровнях: 1. Первый и второй уровни технической поддержки организуется Заказчиком. 2. Третий уровень технической поддержки организуется Исполнителем. Зона ответственности каждого уровня технической поддержки указана в Таблице 2. Таблица 2 - Зона ответственности каждого уровня технической поддержки Участники технической поддержки Описание Первый уровень технической поддержки (далее – 1-й уровень) Группа ответственных сотрудников 1-го уровня Заказчика, осуществляющая прием и первичную обработку обращений (заявок) (описание предмета обращения, первичная классификация и приоритизация, определение назначения, маршрутизация обращений (заявок) по назначению), руководствуется в своей работе настоящим Регламентом и БЗ, наполняемой 2-м уровнем поддержки, самостоятельно решает часть обращений (заявок), связанных с недостаточной квалификацией пользователей или настройками в рамках своей компетенции. В случае невозможности решения обращений (заявок) на 1-ом уровне ответственный сотрудник передает ее на 2-й уровень Второй уровень технической поддержки (далее – 2-й уровень) Группа ответственных сотрудников 2-го уровня Заказчика по установленным компетенциям (информационная безопасность, сопровождение и эксплуатация информационно-аналитических систем, развитие информационно-аналитических систем, техническая поддержка информационно-аналитических систем) отвечает за поддержание работоспособности Системы, обработку обращений (заявок) и их решение в регламентные сроки в соответствии с установленными приоритетами. Осуществляет информационно-консультационную поддержку пользователей Системы в рамках своей компетенции. Оказывает экспертную помощь ответственным сотрудникам 1-го уровня в части формирования БЗ, содержащей ответы на часто задаваемые вопросы пользователей, с целью передачи знаний, навыков и инструментария на 1-й уровень для ускорения решения обращений (заявок). В случае невозможности решения обращения (заявки) на 2-ом уровне ответственный сотрудник передает его на 3-й уровень. При выявлении необходимости изменений в ППО Системы инициирует формирование обращения (заявки) и направляет его на группу ответственных сотрудников 3-го уровня по соответствующему классификатору (ЗНО, ЗНИ, и т.д.) Третий уровень технической поддержки (далее – 3-й уровень) Группа ответственных сотрудников Исполнителя, отвечающая за устранение сбоев и аварий, проведение информационно-консультационной поддержки пользователей Системы, проведение адаптации и конфигурирования Системы в объемах действующих контрактов на оказание технической поддержки 3.3 Перечень и описание статусов обращений (заявок) В Таблице 3 приведен перечень статусов обращений (заявок), действующий в СРО, и их описание. Таблица 3 - Перечень статусов обращений (заявок) и их описание Статус Описание Зарегистрирован Обращение (заявка) принято и зарегистрировано Направлен в группу Присваивается при назначении ответственными сотрудниками 1-го уровня группе ответственных сотрудников 2-го уровня по тематике обращения (заявки) после заполнения всей необходимой информации и полей обращения (заявки), а также при его передаче между группами 2-го уровня Передан в группу Присваивается при передаче обращения (заявки) ответственными сотрудниками 2-го уровня на группу ответственных сотрудников 3-го уровня Назначен Присваивается при назначении обращения (заявки) на ответственного сотрудника для его решения в рамках компетенции В работе Присваивается при приеме обращения (заявки) в работу ответственным сотрудником для его решения Решен Присваивается ответственным сотрудником, выполнившим работы по обращению (заявке) Закрыт Присваивается автоматически при решении запроса по обращению (заявке), а также отсутствии дополнительных запросов пользователя в соответствии с действующим SLA, или при подтверждении решения обращения (заявки) со стороны пользователя Запрос доп. информации Присваивается при необходимости запроса дополнительной информации и/или уточнения предмета обращения по обращению (заявке) у пользователя Ответ предоставлен Присваивается после ответа пользователем на запрос дополнительной информации Отклонен Присваивается, если обращение (заявка) не актуальна (по информации от пользователя), отсутствует техническая возможность решения обращения (заявки), предмет обращения не входит в компетенции технической поддержки, или существует влияние доработки на другие компоненты, что нарушает общий порядок работы Системы Согласование Присваивается при необходимости согласования направления обращения (заявки) ответственным сотрудником Заказчика на 3-й уровень Анализ Присваивается при проведении анализа на предмет возможности внесения изменений, связанных с развитием/улучшением/оптимизацией Системы и выводом новой функциональности и оценке ресурсоемкости Тестирование Присваивается Исполнителем при завершении разработки и проведенном предварительном тестировании для последующего осуществления приемочного тестирования Специалистом 2-го уровня Релиз Присваивается ответственным сотрудником Заказчика при принятии решения о возможности вывода доработки в продуктивную среду Утверждение заказчиком Присваивается при согласовании группой профильных специалистов на 2-м уровне поддержки с пользователем технического задания для внесения изменений, связанных с развитием/улучшением/оптимизацией Системы и выводом новой функциональности Доработка Присваивается в случае несогласования Заказчиком работ, проведенных Исполнителем в рамках контрактных обязательств, по внесению изменений, связанных с развитием/улучшением/оптимизацией Системы и выводом новой функциональности в штатном режиме, и необходимости последующего направления Исполнителю для ее доработки Отложен Присваивается в случае невозможности выполнения запроса, изложенного в обращении (заявке), в связи с необходимостью запроса дополнительной информации у третьих сторон 3.4 Порядок регистрации и сопровождения Заявок Порядок регистрации и сопровождения обращений (заявок) в рамках оказываемых услуг по технической поддержке Системы зависит от типа обращения (заявки): 1. Услуга по решению инцидентов, связанных с работой ППО – тип обращения (заявки) «Инцидент». 2. Услуга по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности – тип обращения (заявки) «Инцидент». 3. Услуга информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы – тип обращения (заявки) «Запрос на обслуживание» (в том числе, консультационный запрос). 4. Услуга адаптационного, конфигурационного и коррекционного сопровождения Системы (в рамках действующих программных модулей и функциональностей) – тип обращения (заявки) «Запрос на изменение». В случае недоступности СРО взаимодействие и информирование Исполнителем о ходе оказания услуги по обращению (заявке), изменению статусов обращений (заявок) осуществляется по согласованию с Заказчиком в соответствии с матрицей взаимодействия, представленной в Приложении 1 к настоящему Регламенту. 3.4.1 Инцидент На рисунке 2 представлена функциональная схема регистрации и сопровождения обращений (заявок) типа «Инцидент». Рисунок 2 - Функциональная схема регистрации и сопровождения обращений (заявок) типа «Инцидент» 3.4.2 Запрос на обслуживание На рисунке 3 представлена функциональная схема регистрации и сопровождения обращения (заявки) типа «ЗНО». Рисунок 3 - Функциональная схема регистрации и сопровождения обращения (заявки) типа «ЗНО» 3.4.3 Запрос на изменение На рисунке 4 представлена функциональная схема регистрации и сопровождения обращений (заявок) типа «ЗНИ». Рисунок 4 - Функциональная схема регистрации и сопровождения обращений (заявок) типа «ЗНИ» 3.5 Порядок классификации и приоритизации обращений (заявок) Классификация является начальной стадией процесса оказания технической поддержки, необходимой для идентификации обращения (заявки) и определения соответствующих действий для его обработки. Для проведения первичной классификации необходимо получить от пользователя и зафиксировать в описании обращения (заявки) подробные сведения о сути запроса, в том числе, для Инцидентов зафиксировать сценарий воспроизведения обнаруженной ошибки. Для проведения вторичной классификации необходимо провести анализ и диагностику для определения корневой причины и затронутой Инцидентом функциональной области (инфраструктура, сеть, ППО). В процессе классификации осуществляется первичная диагностика и оценка проблемы, описанной пользователем Системы в обращении (заявке), в части функционирования и/или удобства использования Системы. Корректная классификация позволяет увеличить скорость обработки обращения (заявки) и решения описанной в обращении (заявке) проблемы при минимальном привлечении ресурсов, в частности, за счет использования известных решений для типовых обращений (заявок), которые должны описываться в БЗ СРО. Классификация позволяет произвести первоначальное назначение обращения (заявки) на ответственного сотрудника и выставить приоритет с учетом приоритизации. Приоритизация применяется для определения критичности описанной в обращении (заявке) проблемы для функционирования ППО Системы. Приоритет рассмотрения обращения (заявки) определяется в процессе ее классификации на основании ряда параметров, вводимых при заполнении обращения (заявки). Приоритизация используется для того, чтобы при одновременном наличии нескольких обращений (заявок) в первую очередь рассматривалась обращения (заявки) с наивысшим приоритетом и не позднее установленных для данного приоритета сроков Изменение приоритета уже зарегистрированного обращения (заявки) используется в случае появления новых обстоятельств, которые ведут к изменению влияния и/или срочности существующего обращения (заявки). При регистрации обращения (заявки) необходимо провести его приоритизацию. В процессе управления обращениями (заявками) каждому обращению (заявке) присваивается приоритет, принимающий одно из значений: Низкий, Средний, Высокий или Критический. В соответствии с приоритетом определяется время, очередность устранения, , ресурсы, привлекаемые для работ по обращению (заявке), а также может определяться порядок/процедура действий при работе с обращением (заявкой). Заказчиком в зависимости от уровня сбоя в работе Системы обращению (заявке) присваивается приоритет с указанием максимального времени реакции и решения в соответствии с требованиями, указанными в Приложении 2 к настоящему Регламенту 4 Формы обращений (заявок) на оказание услуг по технической поддержке Системы, заполняемые в СРО 4.1. Форма обращения (заявки) на оказание услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы При подаче обращения (заявки) типа «ЗНО» в СРО указывается (Таблица 5): Таблица 5 – Описание атрибутов формы обращения (заявки) на оказание услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 5) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 5) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 5) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 5) Категория обращения: информационно-консультационная поддержка Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 5) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 5) Текст запроса на оказание услуги по информационно-консультационной поддержке сотрудников Заказчика Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 5) На рисунке 5 приведена форма обращения (заявки) типа «ЗНО» в СРО. Рисунок 5 - Форма обращения (заявки) типа «ЗНО» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы, заполненную в свободной форме. 4.2. Форма обращения (заявки) на оказание услуги по решению инцидентов, связанных с работой ППО При подаче обращения (заявки) типа «Инцидент» в СРО указывается (Таблица 6): Таблица 6 – Описание атрибутов формы обращения (заявки) на оказание услуги по решению инцидентов, связанных с работой ППО Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 6) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 6) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 6,) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 6) Категория обращения (заявки): инцидент Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 6) Приоритет изменения Время - одно из значений: Низкий, Средний, Высокий или Критический. Определяет, очередность решения обращения (заявки), ресурсы, привлекаемые для решения обращения (заявки), порядок/процедура действий при решении обращения (заявки) – поле СРО «Приоритет» (см. рисунок 6,) Тип изменения Справочник, классифицирующий типовые запросы характерные для Системы – поле СРО «Предмет обращения» (см. рисунок 6) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 6) Полное описание инцидента, включая скриншоты и описание шагов, приведших к неисправности Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 6) Однократность/неоднократность Круг пользователей или компьютеров, затронутых данным инцидентом Действия, предпринятые для самостоятельного решения инцидента (при наличии) Версии используемого программного обеспечения на клиентской рабочей станции, где воспроизводится ошибка (операционная система, прикладное программное обеспечение) Дополнительная информация На рисунке 6 приведена форма обращения (заявки) типа «Инцидент» в СРО. Рисунок 6 - Форма обращения (заявки) типа «Инцидент» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуги по решению инцидентов, связанных с работой ППО, заполненную в свободной форме 4.3. Форма обращения (заявки) на оказание услуг по адаптационному конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) При подаче обращения (заявки) типа «ЗНИ» в СРО указывается (Таблица 7): Таблица 7 – Описание атрибутов формы обращения (заявки) на оказание услуг по адаптационному, конфигурационному и коррекционному сопровождению Системы Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 10) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 9) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 10) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 10) Категория обращения (заявки): запрос на изменение Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 7) Приоритет изменения Время, очередность решения обращения (заявки), ресурсы, привлекаемые для решения обращения (заявки), порядок/процедура действий при решении обращения (заявки) – поле СРО «Приоритет» (см. рисунок 7) Тип изменения Справочник, классифицирующий типовые запросы характерные для Системы – поле СРО «Предмет обращения» (см. рисунок 7) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 7) Текст запроса на оказание услуги по адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 7) На рисунке 7 приведена форма обращения (заявки) типа «ЗНИ» в СРО. Рисунок 7 - Форма обращения (заявки) типа «ЗНИ» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуг по адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей), заполненную в свободной форме 4.4. Форма обращения (заявки) на оказание услуги по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности При подаче обращения (заявки) типа «Инцидент» в СРО указывается (Таблица 8): Таблица 8 – Описание атрибутов формы обращения (заявки) на оказание услуг по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 8) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 8) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 8) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 8) Категория обращения (заявки): инцидент Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 8) Приоритет Время, очередность решения обращения (заявки), ресурсы, привлекаемые для решения обращения (заявки), порядок/процедура действий при решении обращения (заявки) – поле СРО «Приоритет» (см. рисунок 8) Тип изменения Справочник, классифицирующий типовые запросы характерные для Системы – поле СРО «Предмет обращения» (см. рисунок 8) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 8) Текст запроса на оказание услуги по обновлению или удалению уязвимых компонентов (библиотек) ППО в соответствии с требованиями к обеспечению информационной безопасности Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 8) На рисунке 8 приведена форма обращения (заявки) типа «Инцидент» в СРО. Рисунок 8 - Форма обращения (заявки) типа «Инцидент» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуги по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности, заполненную в свободной форме Приложение 1 к Регламенту Матрица ответственных за взаимодействия в рамках выполнения работ по техническому сопровождению Системы Таблица 1 – Ответственные за взаимодействия в рамках выполнения работ по техническому сопровождению Системы со стороны Исполнителя ФИО Должность Адрес электронной почты Телефон — — — Общий контакт Приложение 2 к Регламенту Приоритеты и регламентные сроки решения обращений (заявок) Приоритеты и регламентные сроки решения обращений (заявок) приведены в таблице 1. Таблица 1 – Приоритеты и регламентные сроки решения обращений (заявок) № п/п Приоритет Максимальное время реагирования Время решения (срок выполнения) Описание приоритета По информационно-консультационной поддержке сотрудников Заказчика и пользователей Системы 1 – не более 1 часа не более 10 часов – По решению инцидентов, связанных с работой ППО 1 Критический не более 30 минут не более 4 часов – полная недоступность ППО; – недоступность ключевых функций; – ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО; – невозможность информационного обмена с ППО для ИС более 4 часов 2 Высокий не более 1 часа не более 8 часов – ошибки/сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; – снижение быстродействия СПО (время отклика ППО на операции превышает 30 секунд); – невозможность управления правами и ролями пользователей 3 Средний не более 4 часов не более 24 часов – невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым недоступность функции формирования отчетов 4 Низкий не более 8 часов не более 40 часов – отклонение в работе ППО, не влияющее на корректную работу функций; – другие сбои и ошибки, затрагивающие основные функции ППО По адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) 1 Критический не более 40 минут не более 8 часов – изменения необходимые при проведении аварийно-восстановительных работ для возобновления работоспособности Системы; – изменения, связанные с критичными ошибками, блокирующими возможность оказания государственных услуг и/или чтение и внесение данных в Систему 2 Высокий не более 1 часа не более 40 часов – изменения относящиеся к обеспечению работоспособности основной функциональности Системы, устраняют выявленные дефекты в работе Системы, оказывающие существенное влияние на процесс оказания государственных услуг и работу пользователей в Системе; – изменения, затрагивающие три и более подсистемы/модуля Системы для адаптации 3 Средний не более 4 часов не более 72 часов – изменения, связанные с развитием/улучшением/оптимизацией Системы и выводом новой функциональности в штатном режиме для одного-двух модулей/подсистем; – изменения, связанные с развитием интеграционных механизмов Системы, например, обновление существующих и/или реализация новых видов сведений СМЭВ, обновление существующих и/или реализация новых API, адаптация и/или изменение механизмов импорта и экспорта данных Системы и т.д. 4 Низкий не более 8 часов не более 160 часов – изменения, связанные с ошибками/ корректировкой/изменение в отображении информации в пользовательском графическом интерфейсе Системы (графика, текст, органы управления, элементы интерфейса) По устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности 1 Критический не более 30 минут не более 24 часов – критические уязвимости, влияющие на возможную полную недоступность ППО, ключевых функций Системы, ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО без возможности восстановления работоспособности Системы; – Критический уровень CVSS > 8.0 2 Высокий не более 1 часа не более 84 часов – критические уязвимости, влияющие на ошибки и сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; – Высокий уровень CVSS 5.0 - 8.0 3 Средний не более 4 часов не более 120 часов – уязвимости, влияющие на невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым; – Средний уровень CVSS 2.0 - 4.9 4 Низкий не более 8 часов не более 160 часов – уязвимости, влияющие на отклонение в работе ППО, не влияющее на корректную работу функций; – другие сбои и ошибки, затрагивающие основные функции ППО; – Низкий уровень CVSS < 2.0 Приложение Г Форма Отчета об оказанных услугах Отчет об оказанных услугах за этап «наименование этапа» в период с «__» _________ по «__» _________. № п/п Наименование услуги Общее количество Номер ОРС Краткое Описание Время реагирования по ТЗ Время реагирования фактическое Время решения по ТЗ Время решения фактическое Результат соблюдения времени реагирования Результат соблюдения времени решения Примечание 1 Услуги по информационно-консультационной поддержке работников Заказчика 2 546782 Консультация по работе Модуля СЦ 1 2 10 часов 11 часов Нет Нет 567123 Консультация по схеме БД 1 1 10 часов 1 час Да Да 2 … … Заказчик Подрядчик /Должность/ /Должность/ ____________________ /Ф.И.О/ ___________________ /Ф.И.О/ М.П. М.П. «_____»_______________________202_г. «_____»_______________________202_г Приложение 1 к Отчету об оказанных услугах Журнал обращений (заявок) на оказание услуги по информационно-консультационной поддержке пользователей Системы (шаблон) Наименование Исполнителя в этапе «наименование этапа» в период с ________________ по _______________ оказал(о) Услугу по поддержке пользователей Системы в объеме, указанном в Таблице 1 Таблица 1 - Журнал обращений (заявок) пользователей Системы № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. ИТОГО зарегистрировано: Всего обращений (заявок): ________ ИТОГО решено: Всего обращений (заявок): ________ Приложение 2 к Отчету об оказанных услугах Журнал обращений (заявок) по решению инцидентов, связанных с работой ППО (шаблон) Наименование Исполнителя в этапе «наименование этапа» в период с ________________ по _______________ оказал(о) Услугу по решению инцидентов в объеме, указанном в Таблице 1. Таблица 1 - Журнал по решению инцидентов № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. ИТОГО зарегистрировано: Всего инцидентов: ________ ИТОГО решено: Всего инцидентов: ________ Приложение 3 к Отчету об оказанных услугах Журнал обращений (заявок) выполнения адаптационного, конфигурационного и коррекционного сопровождения Системы (шаблон) Журнал выполнения адаптации, конфигурации и коррекции Системы сформирован за этап «наименование этапа» в период с «__» _________ по «__» ____________ и представлен в таблице ниже (Таблица 1). Таблица 1 - Журнал выполнения адаптации, конфигурации и коррекции сопровождения Системы № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. Количество выполненных заявок за этап: ________ Приложение 4 к Отчету об оказанных услугах Журнал обращений (заявок) по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности (шаблон) Журнал обращений (заявок) по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности сформирован за этап «наименование этапа» в период с «__» _________ по «__» ____________ и представлен в таблице ниже (Таблица 1). Таблица 1 - Журнал выполнения заявок по устранению уязвимостей в ППО № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. Количество выполненных заявок за этап: ________ Приложение Д Форма Протокола проверки результатов организационно-штатных и подготовительных мероприятий (шаблон) Протокол проверки результатов организационно-штатных и подготовительных мероприятий Настоящий Протокол содержит результаты проверки организационно-штатных и подготовительных мероприятий, проведенных Исполнителем (Таблица Д.1). Таблица Д.1. Протокол проверки результатов № Мероприятия Подготовительного этапа Результат проверки 1. Определить и направить Заказчику документ «Ответственные за взаимодействия в рамках выполнения работ по техническому сопровождению Системы со стороны Исполнителя». Документ содержит контактную информацию (ФИО, должность, адрес электронной рабочей почты, номер телефона) не менее чем о 2 лицах, ответственных за оказание услуг со стороны Подрядчика Выполнено/Не выполнено 2. Обеспечить подключение специалистов Подрядчика к Системе Выполнено/Не выполнено 3. Обеспечить подключение специалистов Подрядчика к СРО Выполнено/Не выполнено Заказчик Подрядчик /Должность/ /Должность/ ____________________ /Ф.И.О/ ___________________ /Ф.И.О/ М.П. М.П. «_____»_______________________202_г. «_____»_______________________202_г - Наименование характеристики - Значение характеристики - Единица измерения характеристики - Инструкция по заполнению характеристик в заявке - ОПРЕДЕЛЕНИЯ, ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ - Автоматизированная система (АС) Система, состоящая из комплекса средств автоматизации, реализующего информационную технологию выполнения установленных функций, и персонала, обеспечивающего его функционирование (ГОСТ Р 59853-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения») АРМ Автоматизированное рабочее место АСУ ТК, Система Информационно-аналитическая система регулирования на транспорте АТС Автоматическая телефонная станция БД База данных ГИС Государственная информационная система ГОСТ Государственный стандарт ГЦОД СИЦ Минтранса России, ГЦОД Головной центр обработки данных ФГБУ «СИЦ Минтранса России» Дашборд Интерактивная аналитическая панель, графический интерфейс. ЕИС Единая информационная система в сфере закупок ЕСИА Единая система идентификации и аутентификации Заказчик Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» КИИ Критическая информационная инфраструктура Кластер Кла?стер (англ. cluster) – объединение нескольких однородных элементов, которое может рассматриваться как самостоятельная единица, обладающая определёнными свойствами Компонент Часть АС, выделенная по определенному признаку или совокупности признаков и рассматриваемая как единое целое (ГОСТ Р 59853-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения») Контракт Контракт на выполнение работ по развитию и оказанию услуг по технической поддержке Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК в 2026 году, заключаемый по результатам проведения конкурентной процедуры закупки в соответствии с требованиями Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» - - Значение характеристики не может изменяться участником закупки - Модуль iМинтранс Модуль сбора данных и представления показателей деятельности Министерства транспорта Российской Федерации iМинтранс АСУ ТК Модуль СЦ Модуль сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК НС Нештатная ситуация НСИ Нормативно-справочная информация ОТИ Объект транспортной инфраструктуры П-ГИС Геоинформационная подсистема П-ИВ Подсистема информационного взаимодействия П-НСИ Подсистема ведения нормативно-справочной информации и метаданных ПО Программное обеспечение Подрядчик, Исполнитель Организация, с которой будет заключен контракт на выполнение работ по развитию Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК П-СД Подсистема сбора данных Работы Работы по развитию Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК СЗИ Средство защиты информации СМЭВ Система межведомственного электронного взаимодействия СУБД Система управления базами данных ТЗ Техническое задание (настоящий документ) ТС Транспортное средство ТК Транспортный комплекс Учреждение Учреждения в области информационной безопасности - ФГБУ «СИЦ Минтранса России» Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации», Заказчик Федеральный закон № 44-ФЗ Федеральный закон от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» ФЗ Функциональная задача ФЗ «Реестр объектов» Функциональная задача «Формирование и ведение единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации» ФСБ России Федеральная служба безопасности Российской Федерации ФСТЭК России Федеральная служба по техническому и экспортному контролю ЧС Чрезвычайная ситуация ЭВМ Электронно-вычислительная машина API От англ. Application Programming Interface – интерфейс прикладного программирования – совокупность инструментов и функций в виде интерфейса для взаимодействия с программой CSS От англ. Cascading Style Sheets — каскадные таблицы стилей FPS От англ. frame per second - количество кадров в секунду HTML От англ. HyperText Markup Language - стандартный язык разметки документов, создающий основу и структуру всех веб-страниц JSON От англ. JavaScript Object Notation – текстовый формат обмена данными, основанный на JavaScript WebAssembly (Wasm) Открытый стандарт, представляющий собой низкоуровневый бинарный формат инструкций, который позволяет выполнять код, написанный на языках C++, Rust или Go, в браузерах с производительностью, близкой к нативной - 1. ОБЩИЕ СВЕДЕНИЯ - 1.2. Шифр темы или номер контракта Присваивается Заказчиком по результатам организации закупочных процедур. 1.2.1. Предмет контракта Выполнение работ по развитию Модуля СЦ. Код по ОКПД2: 62.01.11.000 – услуги по проектированию и разработке информационных технологий для прикладных задач и тестированию программного обеспечения. Оказание услуг по технической поддержке Модуля СЦ. Код по ОКПД2: 62.02.30.000 – услуги по технической поддержке информационных технологий. Выполнение работ по развитию Модуля СЦ предусмотрено с учетом ключевых результатов (ОКР) Ведомственной программы цифровой трансформации Минтранса России на 2026-2028 (далее - ВПЦТ Минтранса России) в составе мероприятия № 103.002 «АСУ ТК» ИТ расхода 103.26.000005 «Развитие Информационно-аналитической системы регулирования на транспорте (АСУ ТК)»: · «Обеспечено информационное взаимодействие с Минобороны о происшествиях на транспортных объектах»; · «Обеспечена автоматизация формирования отчетов о нештатных ситуациях на транспорте, в том числе по данным внешних систем». Выполнение работ по технической поддержке АСУ ТК предусмотрено ВПЦТ Минтранса России в составе мероприятия № 103.002 «АСУ ТК» ИТ расхода 103.26.000021 «Эксплуатация Информационно-аналитической системы регулирования на транспорте (АСУ ТК)» - - Значение характеристики не может изменяться участником закупки - 1.3. Заказчик Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» (ФГБУ «СИЦ Минтранса России»). Адрес: 107078, Москва, Садовая-Спасская ул., д.18, стр. 1. Оператором Системы является Заказчик - Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» (ФГБУ «СИЦ Минтранса России) - 1.4. Подрядчик Определяется по результатам проведения конкурентной процедуры закупки в соответствии с требованиями Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (далее – Федеральный закон № 44-ФЗ) - 1.5. Основания для выполнения работ Работы осуществляются на основании следующих документов: – постановление Правительства Российской Федерации от 30.12.2003 № 794 «О единой государственной системе предупреждения и ликвидации чрезвычайных ситуаций»; – постановление Правительства Российской Федерации от 08.11.2013 № 1007 «О силах и средствах единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций»; – распоряжение Правительства Российской Федерации от 27.11.2021 № 3363-р «О Транспортной стратегии Российской Федерации до 2030 года с прогнозом на период до 2035 года»; – Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 26.08.2025 №ЕФ-3; – Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 27.11.2025 №ЕФ-23; - – Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 19.02.2026 №ЕФ-1; – План мероприятий по профилактике случаев непроизводственного травматизма граждан на железнодорожном транспорте, являющийся приложением к постановлению коллегии Министерства транспорта Российской Федерации от 11.03.2026 № 2 - 1.6. Перечень документов, требования которых должны быть учтены при выполнении работ – Федеральный закон Российской Федерации от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации»; – Федеральный закон Российской Федерации от 27.07.2006 № 152-ФЗ «О персональных данных»; – Федеральный закон Российской Федерации от 06.04.2011 № 63-ФЗ «Об электронной подписи»; – Федеральный закон Российской Федерации от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации»; – Указ Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации»; – Указ Президента Российской Федерации от 01.05.2022 № 250 «О дополнительных мерах по обеспечению информационной безопасности Российской Федерации»; – Указ Президента Российской Федерации от 31.03.2010 № 403 «О создании комплексной системы обеспечения безопасности населения на транспорте»; – постановление Правительства Российской Федерации от 30.07.2004 № 395 «Об утверждении Положения о Министерстве транспорта Российской Федерации»; – постановление Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации»; – постановление Правительства Российской Федерации от 16.11.2015 № 1236 «Об установлении запрета на допуск программного обеспечения, происходящего из иностранных государств, для целей осуществления закупок для обеспечения государственных и муниципальных нужд»; – постановление Правительства Российской Федерации от 23.12.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 Федерального закона «Об электронной подписи»; - – постановление Правительства Российской Федерации от 08.06.2011 № 451 «Об инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг и исполнения государственных и муниципальных функций в электронной форме»; – постановление Правительства Российской Федерации от 30.01.2013 № 62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин»; – приказ ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации»; – приказ ФСТЭК России от 11.04.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений»; – приказ ФСБ России от 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.7. Сроки начала и окончания работ Начало работ: с даты заключения Контракта. Окончание работ: не позднее 15.12.2026. Работы выполняются в соответствии с этапами. Сроки выполнения этапов работ по развитию и технической поддержке Модуля СЦ определяются Календарным планом. Календарный план, приведен в разделе 5 настоящего ТЗ - 1.8. Общие сведения об источниках и порядке финансирования работ Источником финансирования являются средства субсидии федерального бюджета Российской Федерации, предоставленной в соответствии с абзацем вторым пункта 1 статьи 78.1 Бюджетного кодекса Российской Федерации (код цели 08-01) - 1.9. Порядок оформления и предъявления результатов работ Подрядчик должен передать Заказчику результаты работ в порядке, определенном Контрактом в сроки, установленные п. 5 настоящего ТЗ, в соответствии с Календарным планом - 1.10. Место выполнения Работ Работы выполняются удаленно на комплексе технических средств Заказчика. Адрес размещения комплекса технических средств Заказчика: Московская обл., Богородский район, пос. Горбуша, Радиоцентр. Техническая возможность удаленного подключения обеспечивается Заказчиком (в части предоставления параметров доступа). Оплата телематических и иных услуг, технических и программных средств, необходимых Подрядчику для удаленного подключения и для выполнения требований по информационной безопасности, осуществляется Подрядчиком самостоятельно за свой счет - 1.1. Наименование Системы Полное наименование системы: Информационно-аналитическая система регулирования на транспорте. Условное обозначение системы: АСУ ТК. Полное наименование модуля: Модуль сбора, ведения и анализа информации о нештатных ситуациях на транспорте. Условное обозначение модуля: Модуль СЦ. Модуль СЦ создан в рамках контракта от 05.08.2024 № ОК/24_04 на выполнение работ по развитию АСУ ТК в части создания модуля «Сбора, ведения и анализа информации о нештатных ситуациях на транспорте». Развитие Модуля СЦ осуществлено в рамках контракта от 19.05.2025 № ОК/25_09 на выполнение работ по развитию Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК - 2. ЦЕЛИ И НАЗНАЧЕНИЕ ВЫПОЛНЕНИЯ РАБОТ - 2.1. Назначение АСУ ТК АСУ ТК предназначена для автоматизации и информационно-аналитического обеспечения процессов управления развитием транспортного комплекса Российской Федерации, обеспечения публичности деятельности органов государственного управления транспортным комплексом. Основными целями АСУ ТК являются: – повышение эффективности процессов управления функционированием и развитием транспортного комплекса на основе создания единой информационной среды и комплекса информационно-аналитических услуг на уровне органов государственного управления ТК; – повышение уровня безопасности ТК на базе получения полной, достоверной и оперативной информации о происходящих изменениях, своевременного выявления негативных тенденций и для принятия соответствующих мер по их устранению и ликвидации последствий - - Значение характеристики не может изменяться участником закупки - Основными задачами АСУ ТК являются: – автоматизация процессов прогнозирования развития транспортного комплекса и поддержки принятия управленческих решений; – автоматизация процессов мониторинга безопасности и устойчивости транспортного комплекса, управления в чрезвычайных и нештатных ситуациях; – автоматизация процессов управления программами и проектами развития и модернизации транспортного комплекса; – автоматизация процессов мониторинга состояния транспортного комплекса, в том числе с использованием набора ключевых показателей эффективности деятельности транспортного комплекса; – информационно-технологическая поддержка взаимодействия субъектов транспортного комплекса Российской Федерации, органов государственного управления и контроля, международных организаций на основе создания единой технологической среды взаимодействия и управления движением данных (и связанных с ними документов) в транспортном комплексе; – использование в процессах управления транспортным комплексом РФ современных технологий электронного документооборота и электронного обмена данными; – организация межведомственного электронного взаимодействия подразделений Министерства транспорта Российской Федерации, подведомственных агентств и службы с другими организациями - 2.2. Назначение и цели развития и технической поддержки Модуля СЦ Назначение Модуля СЦ: – оперативный мониторинг нештатных и чрезвычайных ситуаций на транспорте ; – оповещение заинтересованных лиц и структур о нештатных и чрезвычайных ситуациях; – сбор, обработка и хранение данных о нештатных и чрезвычайных ситуациях. Целями развития Модуля СЦ являются: – расширение состава данных об оперативной обстановке на транспорте; – оптимизация процесса сбора данных об оперативной обстановке на транспорте; – повышение информированности пользователей за счет визуализация данных Модуля СЦ; – автоматизация процесса формирования отчетов о ЧС и нештатной ситуации на транспорте; – обеспечение информационного взаимодействия с заинтересованными организациями по вопросам ведения. - Целями оказания услуг по технической поддержке являются: – обеспечение информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы; – поддержание параметров функционирования ППО Системы, удовлетворяющих требованиям производственных процессов, включая их непрерывность; – обеспечение бесперебойного функционирования ППО и своевременное устранение сбоев и аварийных ситуаций в Системе; – своевременное устранение уязвимостей при выявлении таковых, в соответствии с требованиями к обеспечению информационной безопасности; – адаптация, конфигурирование, коррекция программного обеспечения в соответствии с изменениями нормативно-правовой базы и запросами уполномоченных сотрудников органов государственной власти, включая выполнение процедур тестирования и участие в обновлениях ППО на стендах Заказчика; – обеспечение сохранения работоспособности ППО в изменяемой среде эксплуатации; – ведение документации по настоящему ТЗ, инициирование и актуализация документации на Систему по результатам обработки запросов Заказчика и внесении соответствующих изменений в ППО. Модуль СЦ применяется в деятельности Министерства транспорта Российской Федерации, подведомственных агентств и службы и другими организациями в соответствии с соглашениями об информационном обмене - 3. ХАРАКТЕРИСТИКА ОБЪЕКТА АВТОМАТИЗАЦИИ - 3.1. Описание объекта автоматизации АСУ ТК Объектом автоматизации являются процессы основной и обеспечивающей деятельности, направленные на управление транспортным комплексом, в том числе, процессы информационного взаимодействия с другими организациями и субъектами транспортного комплекса. АСУ ТК относится к государственным информационным системам, а также к информационным системам персональных данных и значимым объектам критической информационной инфраструктуры Российской Федерации. АСУ ТК соответствует требованиям, предъявляемым к: – ГИС второго класса защищенности в соответствии с приказом ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах»; – ИС персональных данных при обеспечении третьего уровня защищенности персональных данных в соответствии с требованиями постановления Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»; – значимым объектам КИИ Российской Федерации второй категории значимости с постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении Правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений». Модуль СЦ является подсистемой АСУ ТК. Перечень платформенных решений и функциональных задач АСУ ТК представлен в Таблице 1 - - Значение характеристики не может изменяться участником закупки - Таблица 1 – Перечень платформенных решений и функциональных задач АСУ ТК № Наименование подсистемы/ функциональной задачи/ модуля Назначение 1 Подсистема сбора данных и централизованного хранилища данных Подсистема обеспечивает выполнение сбора данных в АСУ ТК, и в т. ч., в рамках функциональных задач «Формирование и ведение межрегионального транспортного баланса пассажирских перевозок в дальнем (межрегиональном) сообщении» и «Формирование и ведение транспортного паспорта региона» 2 Подсистема информационного взаимодействия Подсистема информационного предназначена для обеспечения информационного взаимодействия подсистем АСУ ТК, а также, взаимодействия АСУ ТК с АС федеральных органов исполнительной власти 3 Подсистема ведения нормативно-справочной информации и метаданных Подсистема предназначена для автоматизации функций формирования и актуализации справочников, классификаторов, реестров и регистров, необходимых для обеспечения информационной поддержки пользователей НСИ и интеграции подсистем АСУ ТК в части применения НСИ 4 Модуль СМЭВ Модуль взаимодействия со СМЭВ представляет собой набор сервисов взаимодействия: сервис синхронного взаимодействия и сервис отправки, осуществляющих дополнительную обработку сообщений, отправляемых в СМЭВ и принимаемых из СМЭВ 5 Геоинформационная подсистема Программное обеспечение геоинформационной подсистемы предназначено для обеспечения смежных подсистем АСУ ТК возможностью работы с картографической информацией, в том числе, отображения на электронных картах объектов транспортной инфраструктуры и получения информации о местоположении, характеристиках контролируемых транспортных объектов 6 Подсистема информационного портала АСУ ТК Подсистема информационного портала предназначена для отображения и входа в функциональные задачи АСУ ТК 7 Подсистема технического портала АСУ ТК Подсистема технического портала АСУ ТК предназначена для управления заявками пользователей и технологического документооборота заявок - 8 Подсистема проектного архива АСУ ТК Подсистема проектного архива АСУ ТК предназначена для автоматизации деловых процессов должностных лиц Министерства транспорта Российской Федерации, подведомственных агентств и службы, в том числе, и процессов информационного взаимодействия внутреннего и внешнего характера 9 ФЗ «Реестр объектов» Функциональная задача предназначена для формирования и ведения единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации 10 ФЗ «СТП» Функциональная задача предназначена для организации информационно-аналитической поддержки процессов территориального планирования Российской Федерации в области федерального транспорта 11 ФЗ «МРТБ ПП» Функциональная задача предназначена для формирования и ведения межрегионального транспортного баланса пассажирских перевозок в дальнем (межрегиональном) сообщении 12 ФЗ «МДД» Функциональная задача предназначена для осуществления мониторинга дорожного движения 13 ФЗ «ТПР» Функциональная задача предназначена для формирования и ведения транспортного паспорта региона 14 ФЗ «Данные по грузообороту» Функциональная задача предназначена для обеспечения подсистем и пользователей АСУ ТК данными по грузообороту между Российской Федерацией и зарубежными странами 15 ФЗ «МЖТ» Функциональная задача предназначена для осуществления мониторинга железнодорожного транспорта 16 ФЗ «МГМП» Функциональная задача предназначена для осуществления мониторинга грузопотоков в морских портах с целью формирования единой цифровой среды мониторинга и планирования перевозок в/из портов Дальнего Востока - 17 Модуль ГЭТ Модуль предназначен для получения, хранения данных инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по отдельно взятому предприятию-перевозчику. Формирования отчетов об инвентаризации с детальными данными по каждому разделу инвентаризации с маршрутизацией в муниципалитет / регион / Минтранс. Содержит агрегированные данные инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по всем перевозчикам, относящихся к данному муниципалитету. Формирует сводный отчет по муниципалитету по каждому разделу инвентаризации с маршрутизацией в регион / Минтранс. Формирует агрегированные данные инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по всем перевозчикам, относящиеся к данному региону и по всем муниципалитетам, относящимся к данному региону. Аналитические и статистические данные о состоянии ГЭТ региона. Содержит данные о видах транспорта, цифровых транспортных сервисах и платежных инструментах Региона. Формирует сводный отчет по каждому разделу инвентаризации с маршрутизацией в Минтранс. Формирует агрегированную статистику и аналитику по всем регионам страны в разрезе транспортных средств, маршрутов, пассажиропотоков, инфраструктуры ГЭТ. Данные о рейтинге регионов и перевозчиков на основании выбранных параметров, документооборот с участниками Системы: получение подписанных печатных форм, их утверждение, возврат на доработку. 18 Модуль iМинтранс Модуль создан для отчета по ключевым показателям транспортного комплекса России (Отраслевые и статистические показатели, исполнение бюджета, исполнение поручений, аналитика СМИ, происшествия по видам транспорта). 19 Модуль СЦ Модуль СЦ предназначен для оперативного мониторинга нештатных ситуаций транспортной отрасли, оповещения заинтересованных лиц и структур и предоставления данных о нештатных ситуациях - АСУ ТК осуществляет идентификацию и авторизацию посредством Единой системы идентификации и аутентификации (ЕСИА). Информационный обмен с внешними информационными системами осуществляется посредством СМЭВ 3 и СМЭВ 4. АСУ ТК развернута на вычислительных мощностях ГЦОД СИЦ Минтранса России - 3.2. Описание и текущее состояние объекта автоматизации Модуля СЦ Объектом автоматизации является процесс организации мониторинга информации о НС и ЧС на транспорте. Предметом деятельности Учреждения являются следующие функции: – информационное обеспечение в области транспортной безопасности, защиты населения и территорий от чрезвычайных ситуаций природного и техногенного характера в транспортном комплексе; – подготовка справочных материалов при угрозе возникновения и возникновении чрезвычайных ситуаций и иных происшествий в транспортном комплексе; – взаимодействие и обмен оперативной информацией с органами управления Единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций; – организация оперативного мониторинга обстановки на объектах транспорта при угрозе и возникновении чрезвычайных ситуаций и иных происшествий. Перечень компонентов Модуля СЦ и выполняемые ими функции представлены в Таблице 2 - Таблица 2. Перечень компонентов Модуля СЦ и их функции № п/п Компонент Выполняемые функции 1 Регистрация событий – ведение карточки события; – удаление комментария; – динамическое отображение существующих событий в заданном радиусе и за заданный период; – возможность автоматической проверки вводимых данных в части количества пострадавших; – отображение карточки ОТИ, ТС в соответствии с ФЗ Реестр объектов; – сохранение и отображение версии карточки события; – привязка события к координатам по картографической основе; – указание признака выполнения действия по отработке события; – перевод статуса события; – закрытие карточки события; – публикация информации о событии в канале мессенджера; – возможность перехода из карточки события на картографическую основу для просмотра местоположения события 2 Визуализация – отображение событий на картографической основе в виде пиктограмм; – масштабирование карты; – отображение краткой карточки события при выборе события на картографической основе; – отображение списка событий; – отображение карточки события; – отображение журнала действий пользователя; – отображение дополнительной информации (текстовая информация и приложенные файлы); – отображение справки о событиях и отчета о событиях; – отображение фильтров и количества отфильтрованных объектов; – отображение результатов поиска; – отображение статистики по событиям на экране; – возможность создания события с картографической основы; – отображения картографических слоев в зависимости от примененных фильтров; – возможность настройки шага картографической сети; – возможность настройки географической точки центра карты; – отображение количества непрочитанных сообщений; – возможность перехода к детальной карточке события из краткой карточки события при выборе события на картографической основе - 3 Информирование – ведение справочника способов оповещения (веб-интерфейс, мессенджер); – формирование сценария выполнения оповещения (настройка условий, способа, параметров оповещения); – выполнение оповещений пользователей 4 Отчетность – формирование отчета и справки о событиях; – фильтрация событий для выгрузки в справку о событиях или в отчет о событиях 5 Администрирование – ведение ролей пользователей; – ведение учетных данных пользователей; – ведение справочника организаций; – ведение справочника групп системы мгновенного обмена сообщениями; – выполнение исходящего звонка на контактный телефонный номер организации; – формирование матрицы эскалации событий Архитектура Модуля СЦ представлена на рисунке 1. Рисунок 1. Архитектура Модуля СЦ - 3.3. Состав используемого ПО Модуля СЦ Программная архитектура Модуля СЦ разработана как трехуровневая клиент-серверная архитектура. Архитектура включает в себя следующие уровни: • уровень представления – презентационный уровень, обеспечивающий взаимодействие с пользователя с клиентскими приложениями с использованием веб-браузера («тонкий» клиент); • уровень приложений – реализован в виде сервисов, обеспечивает обработку запросов, поступающих от клиентских приложений, формирование ответов на запрос в доступном пользователю виде (формирование пользовательских интерфейсов); • уровень хранения данных – реализуется как сервер БД и обеспечивает хранение и целостность хранимых данных, создание резервных копий, ведение журнала транзакций, восстановление данных после сбоев. Программная архитектура Модуля СЦ включает в себя сервисы и интерфейсы, указанные в Таблице 3. Таблица 3. Программная архитектура Модуля СЦ Программный сервис/интерфейс Технологии реализации Уровень представления Интерфейс пользователя и администратора (front-end) Javascript Уровень приложений Сервис (GateWay) Kotlin Сервис геокодирования (geocoding-service) Kotlin Сервис уведомлений (notifiсation-service) Kotlin Сервис работы с файлами (file-service) Kotlin Сервис отчетности (report-service) Kotlin Сервис управления событиями (event-service) Kotlin Сервис информирования через мессенджер (messenger-notifier) Python Сервис внешних интеграций (integration-service) Сбор информации из внешних систем и сервисов Брокер сообщений Kafka Уровень хранения данных Файловое хранилище MinIO S3 СУБД Postgres Pro Enterprise - 3.4. Информационное взаимодействие программных сервисов и интерфейсов Модуля СЦ Объект автоматизации функционирует в распределенной информационной среде. Обмен данными осуществляется по защищенным каналам связи (в том числе ведомственным сетям передачи данных). Источники информации включают: · внешние автоматизированные системы (органов государственной власти); · внутренние базы данных (реестры объектов транспортной инфраструктуры, паспорта регионов и пр.); · оперативная информация от персонала, поступающая через автоматизированные рабочие места (АРМ) и мобильные устройства. 3.4.1. Взаимодействие Модуля СЦ со смежными подсистемами АСУ ТК Модуль СЦ входит в состав АСУ ТК и взаимодействует со следующими ее функциональными задачами и подсистемами: · Функциональной задачей «Формирование и ведение единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации» (ФЗ «Реестр объектов»); · Геоинформационной подсистемой АСУ ТК (П-ГИС); · Подсистемой ведения нормативно-справочной информации и метаданных (П-НСИ); · Подсистемой сбора данных и централизованное хранилище данных (П-СД); · Подсистемой информационного взаимодействия (П-ИВ). 3.4.2. Взаимодействие с внешними информационными системами Список внешних информационных систем, с которыми осуществляется взаимодействие Модуля СЦ: · ЕСИА; · мессенджер; · Яндекс Геокодер; · Информационная система «Централизованная система сбора информации систем-112»; · ПВК «Поиск-Море», АИС РПТ; · облачная АТС - 3.5. Требования к эксплуатации Применяемое в Системе программное обеспечение, программно-аппаратные и аппаратные комплексы должны соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации» - 4. ТРЕБОВАНИЯ К МОДУЛЮ СЦ - 4.3.1.2. Требования к общему порядку оказания услуг Техническая поддержка Модуля СЦ должна быть организована на трех уровнях: – первый и второй уровни технической поддержки организуется Заказчиком; – третий уровень технической поддержки организуется Подрядчиком. Перечень действий на каждом уровне технической поддержки указан в Таблице 5: Таблица 5 – Перечень действий на каждом уровне технической поддержки Уровень технической поддержки Доступные действия Условия передачи задачи на следующий уровень Первый уровень технической поддержки (далее – 1-й уровень) – принимает обращения (заявки) пользователей Модуля СЦ и работников Заказчика; – регистрирует обращения в Модуле СЦ регистрации обращений; – присваивает уникальный идентификационный номер, классифицирует обращения; – самостоятельно решает обращения, которые связаны с недостаточной квалификацией пользователей или настройками в рамках своей компетенции; – взаимодействует с пользователями Модуля СЦ при решении проблемы Передает обращение на второй уровень поддержки в случае невозможности решения на своем уровне Второй уровень технической поддержки (далее – 2-й уровень) – принимает обращения от 1-го уровня; – уточняет классификацию обращения в результате дополнительного анализа; – самостоятельно решает обращения в рамках своей компетенции; – осуществляет техническую и консультационную поддержку Модуля СЦ; – взаимодействует с сотрудниками 1-го и 3-го уровня и пользователями Модуля СЦ; – формирует заявки для 3-го уровня и контролирует исполнение Передает обращение на третий уровень поддержки в случае невозможности решения на своем уровне Третий уровень технической поддержки (далее – 3-й уровень) – принимает обращения от 2-го уровня; – обеспечивает выполнение требований, предъявляемых Контрактом и настоящим Техническим заданием к Услугам, оказываемым Подрядчиком Все поступающие обращения должны быть исполнены Подрядчиком - - Значение характеристики не может изменяться участником закупки - Для обеспечения взаимодействия с Заказчиком Подрядчик со своей стороны определяет ответственных лиц, уполномоченных в структуре Подрядчика за своевременное и качественное оказание Услуг в рамках настоящего ТЗ, а также контактную информацию ответственных лиц (телефон, электронную почту). Подрядчик должен предоставить Заказчику единый адрес электронной почты для приема обращений (заявок) в течение 3 (трех) рабочих дней после заключения Контракта. Указанный в настоящем пункте адрес электронной почты (способ направления обращений (заявок) применяется в случае сбоя в работе СРО Заказчика. Со своей стороны, Заказчик предоставляет Подрядчику перечень и контактную информацию (телефон, электронную почту) уполномоченных лиц для осуществления взаимодействия с указанием зон ответственности. О любых изменениях в контактной информации ответственных лиц Стороны должны уведомить друг друга в течение 1 (одного) рабочего дня с момента возникновения таких изменений посредством уведомления на электронную почту ответственных лиц и/или в письменной форме. В результате оказания услуг по настоящему ТЗ не должны быть изменены исходные коды, дистрибутивы и иные компоненты Модуля СЦ вне согласованных с Заказчиком изменений. Любые изменения исходных кодов, дистрибутивов и иных компонентов Модуля СЦ должны производиться только после согласования с Заказчиком уполномоченными лицами по электронной почте или иным заранее согласованным способом. Не должна быть ухудшена надежность и производительность Модуля СЦ. Оказание услуг по Контракту не должно нарушать требования к информационной безопасности, описанной в документации на Модуль СЦ - – выполнение требований по обеспечению в автоматизированном режиме с Национальной системой противодействия DDoS-атакам (НСПА) Центра мониторинга и управления сетью связи общего пользования ФГУП «ГРЧЦ» в рамках реализации мер по защите ГИС от атак, направленных на отказ в обслуживании; – детализированные требования к составу и содержанию работ по аттестации, а также к их результатам в соответствии с пунктами 13, 15 и 16 требований приказа ФСТЭК России от 29.04.2021 № 77 «Об утверждении Порядка организации и проведения работ по аттестации объектов информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну» - 4.5.5.1. Требования к безопасности исходного кода Процесс разработки исходного кода должен соответствовать требованиям законодательства, нормативным правовым актам Российской Федерации, приказу ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по безопасности значимых объектов критической информационной инфраструктуры Российской Федерации», а также учитывать отраслевые практики безопасной разработки. Подрядчик должен предоставить Заказчику Руководство по безопасной разработке программного обеспечения (далее – Руководство), применяемое при разработке исходного кода Модуля СЦ. Руководство должно содержать: · описание процесса безопасной разработки и ролевой модели, отражающей зоны ответственности сотрудников Подрядчика; · описание процессов моделирования, оценки и формирования мер предотвращения угроз, применяемых Подрядчиком; · описание методик, применяемых Подрядчиком при разработке исходного кода (правила написания кода); · описание методик, периодичности проведения и инструментария статического, динамического, композитного и фаззинг тестирования исходного кода, включающего критерии отбора релизных версий ПО, применяемые Подрядчиком в процессе разработки; · описание механизмов безопасности в процессе сборки и доставки (безопасность образов, безопасность секретов, безопасность окружения и сборочной среды), применяемые Подрядчиком; · утвержденные шаблоны отчетной документации (в том числе акты), в соответствии с которыми Заказчик принимает результаты проверок (артефакты сборочного процесса), проведенных Подрядчиком; · описание процедур отслеживания и исправления обнаруженных ошибок и уязвимостей программного обеспечения; · описание способов и сроков доведения Подрядчиком до Заказчика информации об уязвимостях программного обеспечения, о компенсирующих мерах по защите информации или ограничениях по применению программного обеспечения, способов получения пользователями программного обеспечения его обновлений, проверки их целостности и подлинности - Подрядчик должен обеспечить реализацию и проведение внутренних проверок мер по разработке безопасного ПО, приведенных в Руководстве. Подрядчик должен провести анализ угроз безопасности информации программного обеспечения в соответствии с ГОСТ 58412-2019 «Защита информации. Разработка безопасного программного обеспечения. Угрозы безопасности информации при разработке программного обеспечения». Подрядчик должен провести испытания по выявлению уязвимостей в программном обеспечении Системы: · проведение статического анализа исходного кода программы; · проведение динамического анализа исходного кода программы; · проведение композитного анализа исходного кода и образов программы; · проведение фаззинг-тестирования программы, направленного на выявление в ней уязвимостей. Испытания по выявлению уязвимостей в программном обеспечении Системы должны быть проведены в рамках: · предварительных испытаний; · опытной эксплуатации; · приемочных испытаний - Оказание услуг в рамках данного технического задания осуществляется Подрядчиком по обращению (заявке) Заказчика, направляемой посредством СРО Заказчика. Регистрация обращений, поступивших непосредственно в Модуль СЦ регистрации обращений Заказчика, производится сотрудниками Заказчика, которые обеспечивают первый уровень технической поддержки Модуля СЦ. В случае назначения приоритета «Критический» или «Высокий», информация о назначении также дублируется оповещением ответственных представителей Подрядчика посредством звонка на предоставленные номера телефонов. Обращение (заявка) должна содержать следующую информацию: – контакты пользователя/организации; – приоритет обращения, соответствующий Приложению 2 к Регламенту; – время обнаружения; – наименование компонента АСУ ТК - Модуль СЦ; Информация может быть расширена по согласованию с Заказчиком. Обращения (заявки) сотрудников Заказчика должны приниматься Подрядчиком через веб-интерфейс СРО. В процессе обработки обращений (заявок) Подрядчик должен обеспечить выполнение следующих процедур: – прием обращений(заявок) от сотрудников Заказчика; – оказание информационно-консультационной поддержки в соответствии с требованиями настоящего Технического задания; – информирование сотрудников Заказчика о статусе обработки и результатах обработки обращений(заявок). Подрядчик осуществляет обязательную регистрацию и учет всех обращений и заявок, поступивших к Подрядчику от представителей Заказчика в рамках оказания настоящих услуг - Примечание: в случае приостановки работы по обращению или заявке (обращение или заявка находится в статусе «Приостановлено»), указываются причины, по которым работы по обращению или заявке приостановлены с указанием перечня действий/информации, запрошенных у инициатора обращения, а также даты, формы и адресата такого запроса. В случае отклонения обращения или заявки (заполняется в случае, если обращению или заявке присваивается статус «Отклонено»), указываются подробно причины такого отклонения, а также фиксируется дата и время перехода в статус «Отклонено». В случае, если обращение или заявка отклонены (отменены) самим Инициатором, то указывается дата и способ, которым от инициатора получено соответствующее уведомление. В случае невыполнения Подрядчиком регламентного времени реагирования или решения обращения (заявки) Заказчик вправе отозвать обращение и направить его Подрядчику повторно. При этом каждое отозванное обращение учитывается в Отчёте об оказанных услугах, как обращение с превышением времени реагирования или решения, но оплате не подлежит. В случае, если обращение (заявка) связано с некачественным выполнением Подрядчиком другой задачи, такое обращение решается в регламентное время, установленное Техническим заданием, при этом оплате такие обращения не подлежат, о чем указывается в Отчете об оказанных услугах в графе «Примечание» - По результатам анализа угроз безопасности информации программного обеспечения и испытаний по выявлению уязвимостей в программном обеспечении Системы должна быть предоставлена отчетная документация по формам, утвержденным в Руководстве, и артефакты сборочной среды, подтверждающие проведение испытаний по выявлению уязвимостей в программном обеспечении Систем. Уязвимости подлежат устранению в сроки, обозначенные Заказчиком. В случае обнаружения уязвимого компонента Подрядчик должен заменить/обновить библиотеки. В случае, если уязвимость не подлежит исправлению на программном уровне, Подрядчик должен разработать меры предотвращения угроз безопасности, в том числе правила безопасности для наложенных средств защиты, рекомендации по безопасной настройке конфигурации для устранения потенциальных уязвимостей и снижения рисков информационной безопасности. Уязвимости, найденные ФСБ России, ФСТЭК России, Минцифры России, Роскомнадзором в ходе исполнения Контракта, а также в течение гарантийного периода, должны быть устранены Подрядчиком за свой счет в сроки, согласованные с Заказчиком - 4.5.6. Требования к эргономике и технической эстетике Взаимодействие пользователей с Модулем СЦ должно осуществляться посредством визуального графического интерфейса. Ввод-вывод данных, прием управляющих команд и отображение результатов их исполнения должны выполняться в интерактивном режиме. Интерфейс должен быть рассчитан на преимущественное использование манипулятора типа «мышь», то есть управление Модулем СЦ должно осуществляться с помощью набора экранных меню, кнопок, значков и т. п. элементов. Клавиатурный режим ввода должен использоваться главным образом при заполнении и/или редактировании текстовых и числовых полей экранных форм. Все надписи экранных форм, а также сообщения, выдаваемые пользователю (кроме системных сообщений), должны быть на русском языке. Модуль СЦ должен обеспечивать проверку вводимых пользователем данных и предупреждать о некорректно введённых значениях - Экранные формы должны проектироваться с учетом требований унификации: – все экранные формы пользовательского интерфейса должны быть выполнены в едином графическом дизайне, с одинаковым расположением основных элементов управления и навигации; – для обозначения сходных операций должны использоваться сходные графические элементы, кнопки и другие управляющие (навигационные) элементы. Термины, используемые для обозначения типовых операций, а также последовательности действий пользователя при их выполнении должны быть унифицированы; – внешнее поведение сходных элементов интерфейса (реакция на наведение указателя «мыши», переключение фокуса, нажатие кнопки) должно реализовываться одинаково. Структура размещения информации и представление этой структуры в Модуле СЦ должны соответствовать следующим требованиям: – пункты меню в пользовательском веб-интерфейсе должны быть сгруппированы в соответствии с тематикой информации, функциональными задачами и технологией работы; – каждому пункту меню должна соответствовать только одна выполняемая функция; – при совершении пользователями ошибочных действий должны выдаваться сообщения об ошибках. Эскизы визуального оформления компонента «Интерактивная карта» представлены в Приложении А. - 4.3.1.3. Требования к регламенту оказания услуг Подрядчик должен руководствоваться Регламентом оказания услуг по технической поддержке Модуля СЦ. Регламент оказания услуг содержит следующую информацию: – порядок оказания услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Модуля СЦ; – порядок оказания услуги по решению инцидентов, связанных с работой ППО; – порядок оказания услуги адаптационного, конфигурационного и коррекционного сопровождения Модуля СЦ (в рамках действующих программных модулей и функциональностей); – порядок оказания услуги по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности. – Регламент содержит следующие формы заявок на оказание услуг: – форма заявки на оказание услуги по информационно-консультационной поддержке сотрудников Заказчика; – форма заявки на оказание услуги по решению инцидентов, связанных с работой ППО; – форма заявки на оказание услуг адаптационного, конфигурационного и коррекционного сопровождения Модуля СЦ (в рамках действующих программных модулей и функциональностей) (приоритет заявки определяется Заказчиком); – форма заявки на оказание услуги по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности - 4.3.2. Требования к режиму обеспечения функционирования Модуля СЦ Режим оказания услуг определен в Приложении Б к настоящему ТЗ. По согласованию с Заказчиком, в целях недопущения остановки функционирования Модуля СЦ в период интенсивной работы пользователей в Модуле СЦ, отдельные услуги могут оказываться по специальному графику (в нерабочее время Подрядчика) в соответствии с заявками Заказчика - 4.3.3. Требования к качеству оказываемых услуг Качество оказываемых услуг поддерживается Подрядчиком в соответствии с определяемыми данным ТЗ условиями и правилами и контролируется Заказчиком на постоянной основе, в том числе по соблюдению сроков исполнения и подтверждениям исполнения от инициаторов обращений и другим параметрам. По результатам выполнения работ по устранению инцидента должна быть устранена корневая причина инцидента с окончательным решением, устраняющим причину возникновения проблемы и исключающим вероятность повторного возникновения проблемы (инцидента). Время устранения корневых причин проблемы (инцидента) не должно составлять более 40 рабочих часов - 4.5.7. Требования по сохранности информации при авариях В случае возникновения аварии или сбоя в процессе выполнения пользовательских задач должно быть обеспечено восстановление баз данных до состояния на момент последней завершенной Модулем СЦ транзакции, и структуры файлового хранилища. Все аварийные ситуации должны обрабатываться программно с выдачей соответствующих сообщений, с корректной обработкой ситуации (завершение транзакций, закрытие файлов и т.п.), без потери обрабатываемой информации. В Модуле СЦ должны быть предусмотрены меры, обеспечивающие целостность данных в случае отказа программного обеспечения или аппаратных средств, исключая случаи физического уничтожения носителя или нарушения функциональности носителя, операционной системы или СУБД по вине их производителя либо обслуживающего персонала. Используемые аппаратные и системные платформы должны обеспечивать сохранность и целостность информации в Модуле СЦ при полном или частичном отключении электропитания, аварии сетей телекоммуникации, полном или частичном отказе технических средств Модуля СЦ. Технические решения должны обеспечивать сохранность информации в случае возникновения следующих событий (аварий, отказов и т.п.): – отказ аппаратного обеспечения на сервере; – отключение питания на сервере; – отказ аппаратного обеспечения на рабочей станции; – отключение питания на рабочей станции администратора; – отказ линий связи, в том числе при осуществлении обмена данными - 4.5.8. Требования к защите от влияния внешних воздействий Требования к защите от влияния внешних воздействий не предъявляются - 4.5.9. Требования к патентной чистоте и патентоспособности 4.5.9.1. Исключительные права на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, базы данных, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, принадлежат Российской Федерации в лице Заказчика. Право собственности на результаты работ, отчетные документы и материалы, полученные в ходе выполнения работ по Контракту, принадлежат Российской Федерации в лице Заказчика и считаются переданными с момента подписания Сторонами Акта сдачи-приемки выполненных работ. Разработанное программное обеспечение поставляется вместе с исходными кодами. 4.5.9.2. Все проектные и технические решения должны отвечать требованиям четвертой части Гражданского кодекса Российской Федерации. Результаты Работ должны быть свободными от возможности предъявления любых прав и притязаний третьих лиц, основанных на промышленной, интеллектуальной или другой собственности. 4.5.9.3 Результаты выполненных Работ не должны повлечь необходимость осуществления Заказчиком закупок программного обеспечения (как исключительных, так и неисключительных прав) для обеспечения функциональности Системы в соответствии с Техническим заданием. При выполнении работ Подрядчик должен использовать только объекты интеллектуальной собственности, права на которые приобретены (получены) и используются без нарушений прав на интеллектуальную собственность третьих лиц или предоставлены Заказчиком - 4.3.4. Требования к документированию результатов оказываемых услуг Для обеспечения контроля оказываемых услуг по поддержке Модуля СЦ со стороны Заказчика, по окончании каждого отчетного периода по контракту в соответствии с календарным планом, Подрядчик обязан предоставить Заказчику Отчет об оказанных услугах. Отчет должен содержать детальную информацию об оказанных услугах с указанием даты выполненных мероприятий и приложением обосновывающих документов (заявок, запросов, требований) или ссылкой на такие документы, если они содержатся в Модуле СЦ. Информация о выполненных мероприятиях по заявкам должна быть сформирована на основании соответствующих записей СРО по каждому этапу исполнения Контракта. В случае оказания услуги адаптационного, конфигурационного и коррекционного сопровождения Модуля СЦ, должны быть предоставлены документы, подтверждающие выполнение требований п. 29.3 приказа ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации». Фактическое время реагирования и время решения по всем обращениям, поступившим в СРО, формируется в СРО по итогам отчетного периода в разделе «Отчеты». Фактическое время реагирования и время решения по обращениям учитывает суммарное время, затраченное на реагирование и, соответственно, на работу по обращению с момента назначения обращения специалисту Подрядчика или группе исполнителей, ответственным за оказание услуг технической поддержки 3 уровня от начала до завершения работ Подрядчиком. При этом принимается суммарное время нахождения заявки в соответствующих статусах заявки СРО на стороне Подрядчика - 4.3.5. Требования к классификации обращений и заявок Обращения и заявки Заказчика классифицируются в соответствии с приоритетами и регламентными сроками, указанными в Приложении 2 к Регламенту. Регистрация обращений и заявок предусматривает создание новой записи в СРО с присвоением поступившему обращению или заявке (новой записи) уникального идентификатора. Запись в СРО должна содержать вопрос или проблему, которую требуется решить или оказать консультацию. Состав обязательной информации, которую должно содержать обращение или заявка, зафиксирован в Регламенте оказания Услуг. Если обращение или заявка автоматически зарегистрированы в СРО при отправке представителем Заказчика, Подрядчик проверяет корректность классификации обращения или заявки и может обратиться к Заказчику с просьбой корректировки, предоставив обоснования в соответствии с настоящей классификацией (Таблица 6) - 4.5.9.4. Подрядчик подтверждает, что обладает всеми правами на передачу Заказчику исключительных прав в соответствии с требованиями настоящего раздела Технического задания. В случае, если к Заказчику по вине Подрядчика будут предъявлены претензии в этой части, иски третьих лиц, связанные с нарушением их прав, Подрядчик принимает на себя такие претензии и иски и возмещает Заказчику все расходы и весь ущерб, понесенный в связи с ними. 4.5.9.5. Подрядчик обязан согласовать с Заказчиком необходимость использования при выполнении работ охраняемых результатов интеллектуальной деятельности, права на которые принадлежат Подрядчику или третьим лицам. 4.5.9.6. В случае, если при выполнении Работ используется готовое программное обеспечение (платформа, подсистема, СУБД и т.д.), которое становится частью (компонентом) Системы, Заказчику передаются полные исключительные права, или неисключительные права (путем заключения лицензионного/сублицензионного договора/соглашения) на такое программное обеспечение со следующими возможностями: – права передаются бессрочно (на весь срок действия исключительных прав); – территория действия Российская Федерация; – должно быть обеспечено право Российской Федерации (в лице Заказчика) передавать, дорабатывать, распространять, развивать результаты работ, созданные в процессе исполнения Контракта, а также перерабатывать такое программное обеспечение. Лицензионное (сублицензионное) соглашение (договор), Акт передачи прав, подписанные Подрядчиком, согласие правообладателя, оформленное в соответствии с положениями Гражданского кодекса Российской Федерации (в случае, если Подрядчик не является правообладателем такого программного обеспечения), инструкция по инсталляции, руководство администратора, руководство пользователя передаются Заказчику в сроки, установленные Техническим заданием для соответствующего функционала Системы - Лицензионное (сублицензионное) соглашение (договор) не может возлагать на Заказчика какие-либо обязанности (в т.ч. в части конфиденциальности, предоставления отчетности), не предусмотренные Контрактом. 4.5.9.7. Передача Заказчику исключительных прав, или простых (неисключительных) прав не может повлечь увеличение стоимости Контракта и/или изменение иных существенных условий Контракта. 4.5.9.8. Функциональность Модуля СЦ передается в объеме и в сроки, установленные Техническим заданием. 4.5.9.9. Нарушение условий настоящего раздела Технического задания, в т.ч. отсутствие соответствующего лицензионного (сублицензионного) соглашения (или договора), либо предоставление лицензионного (сублицензионного) соглашения (или договора), не соответствующего требованиям действующего законодательства Российской Федерации или требованиям Контракта, является нарушением существенных условий Контракта. 4.5.9.10. В случае, если в соответствии с пунктом 4.5.9.6 Заказчику передается исключительное право, такая передача осуществляется в порядке, установленном Гражданским кодексом Российской Федерации. 4.5.9.11. В случае, если при выполнении Работ положения пунктов 4.5.9.5-4.5.9.6 не применялись, Подрядчик в составе отчетной документации предоставляет об этом декларацию в свободной форме. Декларация должна содержать сведения о полном соответствии результата Работ требованиям Контракта, а также о неприменении при выполнении работ готового программного обеспечения (платформ, подсистем, СУБД и т.д.), которое стало частью (компонентом) Системы - Таблица 6. Категории обращений и заявок Категория Примеры Запрос на обслуживание Подготовка SQL запроса к СУБД для решения прикладной задачи и д.р. – запрос на любое действие, не являющееся запросом информации и несовершенный на основе происшествия, прямо или косвенно влияющего на работу Модуля СЦ Консультация «Где взять / куда обратиться...?», «Как сделать / выполнить…», «Как это работает…?» - запрос, имеющий своей целью получение информационной поддержки Инцидент Разбор ошибок/сбоев и подготовка материалов (корректировочных релизов, инструкций) для Заказчика для устранения ошибок/сбоев, которые приводят к частичному и полному нарушению работоспособности всех или отдельных функций ППО. Подготовка изменения и материалов, необходимых для проведения аварийно-восстановительных работ для возобновления работоспособности Модуля СЦ ЗНИ Подготовка изменений, связанных с изменением, улучшением/оптимизацией Модуля СЦ и выводом новой модифицированной функциональности в штатном режиме. Подготовка изменений, связанных с модификацией существующих и/или реализация новых интеграционных механизмов для получения/обработки данных внешних систем. Подготовка изменений графического интерфейса по требованиям Заказчика. Перечень статусов обращений (заявок) приведен в пункте 3.3. Регламента оказания Услуг. Назначение обращению (заявке) статуса «Закрыто» осуществляется Заказчиком только после получения от инициатора обращения (заявки) подтверждения о его исполнении или нахождения обращения (заявки) в статусе «Выполнено» и отсутствия повторных вопросов/запросов по данному обращению (заявки) в течение 5 рабочих дней. Категории и статусы обращений (заявок) могут быть скорректированы в процессе оказания услуг исключительно по согласованию с Заказчиком - 4.3.6. Требования к услугам технической поддержки 4.3.6.1. Требования к организации третьего уровня технической поддержки Основными задачами организации третьего уровня технической поддержки в рамках оказания услуг по технической поддержке Модуля СЦ являются организация эксплуатационной службы Подрядчика, проверка готовности технических и программных средств для обеспечения непрерывного функционирования ППО Модуля СЦ. Подрядчиком должны быть проведены организационно-штатные и подготовительные мероприятия (в т. ч. технические) в рамках организации технической поддержки Модуля СЦ. Подрядчик в течение 5 (пяти) рабочих дней с даты заключения Контракта должен: – определить и направить Заказчику документ «Перечень уполномоченных специалистов», содержащий контактную информацию (ФИО, должность, адрес рабочей электронной почты) лиц, ответственных за оказание услуг со стороны Подрядчика; – обеспечить подключение специалистов Подрядчика к Системе регистрации обращений (заявок) (СРО предоставляется Заказчиком) для оказания услуг; – согласовать с Заказчиком способ доступа Подрядчика к Модулю СЦ. Результат выполнения мероприятий фиксируется в Протоколе проверки результатов организационно-штатных и подготовительных мероприятий (см. Приложение Д к настоящему ТЗ) - 4.5.9.12. Передача Заказчику комплекта документов, материалов и сведений, предусмотренных нормативными правовыми актами Российской Федерации в сфере информационных технологий, защиты информации, правовой защиты интересов государства в области интеллектуальной собственности, включая документы, подтверждающие отказ авторов (разработчиков) от исключительных прав на передаваемые объекты интеллектуальной собственности в пользу Подрядчика, с проектами заявок на государственную регистрацию в установленном порядке прав Заказчика на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, базы данных, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, осуществляется Подрядчиком в составе отчетной документации, предусмотренной условиями Контракта. 4.5.9.13. По результатам выполнения работ по развитию системы должны быть подготовлены материалы для регистрации доработанной версии Системы (объекта учета) в НФАП в соответствии с требованиями постановления Правительства Российской Федерации от 30 января 2013?г. №?62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин» (с изменениями и дополнениями) в части обязательности размещения результатов работ в национальном фонде алгоритмов и программ для электронных вычислительных машин - 4.5.10. Требования по стандартизации и унификации К Модулю СЦ предъявляются следующие требования в части стандартизации и унификации: – работы по развитию Модуля СЦ должны производиться в соответствии с действующими стандартами и нормами Российской Федерации; – при создании и модернизации элементов Модуля СЦ следует руководствоваться действующими в Российской Федерации национальными стандартами и другими нормативно-техническими документами; – используемые оборудование и материалы, подлежащие обязательной сертификации, должны иметь соответствующие сертификаты; – ПО Модуля СЦ должно проектироваться и разрабатываться с учётом обеспечения требований унификации; – применяемые при создании Модуля СЦ технические (форматы данных, протоколы передачи и прочие) и организационные (регламенты, требования, инструкции) решения должны быть доступны и документированы в виде, достаточном для независимой (без обращения к Подрядчику) реализации третьими сторонами; – термины, обозначения и наименования, используемые в ПО, должны быть стандартизованы и унифицированы, выполнены на русском языке; – взаимодействие элементов и их внешнее поведение должно быть реализовано одинаково и производиться по единым правилам - 4.3.6.2. Требования к услугам информационно-консультационной поддержки работников Заказчика и пользователей Модуля СЦ Услуги информационно-консультационной поддержки сотрудников Заказчика включают: – обработку обращений и заявок, поступивших от сотрудников Заказчика; – консультирование сотрудников Заказчика и пользователей Модуля СЦ; – актуализацию документации, и других материалов по работе с Модулем СЦ при необходимости. – консультирование и разработку рекомендаций по настройке Модуля СЦ (без изменения программного кода), включая изменение настроек функционирования; – консультации по вопросам использования, настройки и возможностям Модуля СЦ; – консультации по проведению превентивных мер для недопущения аварийных ситуаций в Модуле СЦ; – консультации по предварительной диагностике и локализации возникшей неисправности Модуля СЦ; – консультации по вопросам обеспечения информационной безопасности Модуля СЦ и настройки функций, обеспечивающих корректную работу программного обеспечения для совершения юридически значимых действий в Модуле СЦ; – другие вопросы, связанные с работой Модуля СЦ. 4.3.6.2.1. Требования к порядку оказания услуг информационно-консультационной поддержки работников Заказчика и пользователей Модуля СЦ Подрядчик выполняет консультирование сотрудников Заказчика и пользователей Модуля СЦ. Консультация может быть предоставлена по согласованным с представителем Заказчика каналам коммуникации с регистрацией результата консультации в СРО Подрядчиком. Детальный порядок оказания консультационных услуг определен в Регламенте оказания Услуг - 4.3.6.3. Требования к услугам по решению инцидентов, связанных с работой ППО Подрядчик устраняет неисправности Модуля СЦ, связанные с работой ППО, выявленные в рамках оказания услуг согласно настоящему Техническому заданию, при этом в зону ответственности Подрядчика не входит устранение неисправностей, выявленных на стороне Заказчика и на стороне третьих лиц (провайдера связи, поставщика электропитания и т.д.). Первичная диагностика выявленной неисправности проводится на 1 и 2 уровнях технической поддержки и не входит в зону ответственности Подрядчика. Если при проведении первичной диагностики и попытке устранить неисправности на 1 и 2 уровнях технической поддержки, данную неисправность устранить не удалось и в процессе диагностики было выявлено, что проблема связана с работоспособностью ППО, обращение (заявка) назначается сотруднику Подрядчика, ответственному за оказание услуг технической поддержки 3 уровня. Инцидентами вне зоны ответственности Подрядчика являются: – работоспособность функциональности, выходящая за рамки текущей реализации функций в Модуле СЦ и/или являющаяся расширением требований Заказчика к функциям Модуля СЦ; – проведение профилактических и плановых работ, согласованных с Заказчиком; – нарушение работоспособности функций Модуля СЦ, вызванное проведением работ на стороне Заказчика - 4.5.11. Требования к показателям назначения 4.5.11.1. Требования к показателям назначения мероприятий по развитию Модуля СЦ В рамках выполнения работ по развитию Модуля СЦ, предусмотренных ТЗ, показатель назначения «Количество пользователей» должен соответствовать значениям, приведенным в данном разделе. Пояснения по показателям, связанным с количеством пользователей, приведены в Таблице 8. Таблица 8. Определения показателей, связанных с количеством пользователей в Модуле СЦ № Показатель Определение Расчетное количество пользователей Количество пользователей, работу которых должен обеспечить Модуль СЦ к моменту сдачи работ по Контракту с учетом достижения всех показателей назначения Расчетное количество одновременно работающих пользователей Количество одновременно работающих пользователей, работу которых должен обеспечивать Модуль СЦ к моменту сдачи работ по Контракту с учетом достижения всех показателей назначения Значения показателей количества пользователей, достижение которых необходимо обеспечить, представлено в Таблице 9 - Таблица 9. Значения показателей количества пользователей № Показатель Значение 1. Расчетное количество пользователей 1 000 2. Расчетное среднее количество одновременно работающих пользователей 200 Развитие Модуля СЦ должно быть направлено на достижение следующего эффекта (показателя), подставленного в мероприятии 103.002 «Информационно-аналитическая система регулирования на транспорте (АСУ ТК)» ВПЦТ Минтранса России: Выполнение работ по развитию Модуля СЦ предусмотрено мероприятием по развитию АСУ ТК, приведенном в ВПЦТ Минтранса России на 2026-2028 гг: № 103.002 «АСУ ТК» в составе ИТ расхода 103.26.000005 «Развитие предусматривает реализацию ОКР и эффектов, приведенных в Таблице 10. Таблица 10. ОКР и эффекты, приведенные в ВПЦТ Минтранса России на 2026 г. № ОКР Дата ОКР Эффекты 1 Обеспечено информационное взаимодействие с Минобороны России о происшествиях на транспортных объектах 25.12.2026 Сокращено время сбора и передачи сведений для Минобороны России о ЧС и НС на транспорте с 120 до 10 минут 2 Обеспечена автоматизация формирования отчетов о нештатных ситуациях на транспорте, в том числе по данным внешних систем 25.12.2026 Сокращено время на подготовку отчетов о нештатных ситуациях на транспорте с 20 до 5 минут Реализация остальных ОКР не является предметом данного ТЗ и проводится в рамках отдельного технического задания. - 4.5.11.2. Требования к показателям назначения мероприятий по эксплуатации Модуля СЦ. Работы по эксплуатации Модуля СЦ не должны обеспечивать режимы функционирования Модуля СЦ, приведенные в разделе 4.5.2 данного ТЗ - Работы по устранению неисправности приостанавливаются (по согласованию с Заказчиком) в следующих случаях: – если Подрядчиком в результате диагностики выявлено, что неисправность находится в зоне ответственности Заказчика. Подрядчик информирует Заказчика о выявленной неисправности в зоне его ответственности по согласованным каналам связи; – требуется действие со стороны Заказчика – до момента выполнения данного действия Заказчика. Заказчик информируется о необходимых действиях по согласованным каналам связи; – отсутствие возможности связаться со специалистами Заказчика, участие которых необходимо для устранения неисправности; – требуется доставить оборудование на объект – до момента доставки и установки оборудования. В случаях, представленных выше, время приостановки работ не входит в учет продолжительности устранения неисправности. Учет времени устранения неисправности Подрядчиком считается с момента назначения Инцидента специалисту Подрядчика, ответственному за оказание услуг технической поддержки 3 уровня. Подтверждение необходимости приостановления работ находится в зоне ответственности Подрядчика. Приостановление сроков выполнения задач в соответствии с настоящим пунктом подтверждается Заказчиком по мотивированному обращению Подрядчика в СРО, основанному на данных диагностики или на иных фактических обстоятельствах - В случае непринятия Подрядчиком необходимых мер по информированию Заказчика (отсутствие надлежащего обращения от Подрядчика или отсутствие уведомления о необходимости осуществления каких-либо действий Заказчиком) не может являться основанием для приостановления работ по устранению неисправности. В отдельных случаях Подрядчику может потребоваться выполнение технологических работ для устранения причин неисправности или недопущения повторения их в будущем. Для обеспечения устранения неисправности Модуля СЦ Заказчиком проводится классификация в соответствии с приоритетами по степени срочности их устранения. Продолжительность устранения неисправности, а также периодичность информирования Подрядчиком Заказчика о ходе устранения неисправности, определены в Регламенте оказания услуг. При подаче обращения (заявки) наивысшего приоритета через СРО Заказчик должен дополнительно проинформировать службу поддержки Подрядчика о созданном обращении (заявки) по телефону уполномоченного сотрудника Подрядчика. При этом временем подачи обращения (заявки) считается время подачи обращения (заявки) через СРО - 4.3.6.3.1. Требования к порядку оказания услуги по решению инцидентов, связанных с работой ППО При поступлении от Заказчика обращения (заявки), являющегося неисправностью в работе Модуля СЦ (инцидентом), Исполнитель реагирует на инцидент в СРО в срок не более 30 минут с момента поступления. В случае необходимости, для решения инцидента ответственный специалист должен связаться с инициатором обращения (заявки) для уточнения условий воспроизведения проблемы или для получения дополнительных сведений. После получения необходимых сведений от инициатора обращения (заявки) ответственный специалист производит диагностику с целью выявления причины инцидента и возможных путей устранения. В случае, если инцидент невозможно решить без получения дополнительных сведений от инициатора, и не удается связаться с инициатором в течение пяти рабочих дней, обращение (заявка) отклоняется в связи с недостатком данных для его решения, Заказчику направляется уведомление об отклонении обращения (заявки). Время, в течение которого невозможно связаться с инициатором, вычитается из общего времени обработки обращения (заявки). Все попытки связаться с инициатором должны фиксироваться с указанием даты и времени попытки, используемого способа связи (номер телефона, адрес электронной почты) и результата попытки (не удалось дозвониться, абонент недоступен, и т.д.) - Факт и время решения инцидента должны быть зафиксированы и отражены в СРО. В случае, если причиной сбоя в работе Модуля СЦ является выход из строя аппаратного обеспечения или неработоспособность смежной информационной системы, время работы над инцидентом приостанавливается до момента устранения неисправности. В ходе решения инцидентов могут быть выявлены дефекты ППО Модуля СЦ. В случае обнаружения дефектов ППО, Подрядчик информирует об этом Заказчика. Исполнитель может быть привлечен к проверке результата устранения дефекта по инициативе Заказчика. Приоритеты инцидентов приведены в Приложении Б к ТЗ. Детальный порядок оказания услуги по решению инцидентов, связанных с работой ППО Модуля СЦ определен в Регламенте оказания Услуг - 4.3.6.4. Требования к услугам адаптационного, конфигурационного и коррекционного сопровождения и доработки Модуля СЦ (в рамках действующих программных модулей и функциональностей) Услуги адаптационного, конфигурационного и коррекционного сопровождения и доработки Модуля СЦ включают: – управление изменениями и адаптация функций Модуля СЦ; – изменение настроек функционирования Модуля СЦ; – внесение изменений и/или модификаций Модуля СЦ (в рамках действующих программных модулей и функциональностей), направленных на улучшение их работоспособности и функциональных возможностей; – подготовка и передача Заказчику SQL запросов в СУБД для получения агрегированной информации из Модуля СЦ, которую невозможно получить с использованием графического пользовательского интерфейса; – адаптация модулей интеграций со смежными информационными системами - 4.3.6.4.1. Требования к проведению изменений Основанием для внесения изменений является запрос от Заказчика. Все активности по внесению изменений должны быть согласованы с Заказчиком, а действия Подрядчика при оказании данной услуги должны быть зафиксированы. В рамках данного Технического задания изменениями считаются локальные доработки функционала Модуля СЦ, которые не должны приводить к необходимости выполнения дополнительных аттестационных испытаний или переаттестации АСУ ТК в соответствии с п. 33 приказа от 29.04.2021 № 77 «Об утверждении Порядка организации и проведения работ по аттестации объектов информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну». При необходимости внесения изменений в Модуль СЦ, не связанных с критичным инцидентом, существенно нарушающим работоспособность Модуля СЦ, Заказчик направляет Подрядчику обращение (заявку), в котором излагает суть изменения, которое требуется внести в Модуль СЦ. Исполнитель, в течение 3 (трех) рабочих дней с момента поступления соответствующего обращения (заявки), оценивает техническую возможность реализации запрашиваемого изменения и варианты реализации. По итогу проведения оценки Подрядчик направляет Заказчику заключение о возможности реализации данного изменения с описанием возможных вариантов реализации и согласует с Заказчиком проведение данного изменения - При проведении работ по изменению и адаптации Подрядчик должен: – обеспечить выполнение требований безопасной разработки программного обеспечения; – обеспечить предварительное проектирование технических решений и согласование с Заказчиком проекта реализации изменения; – использовать семантическое версионирование (SemVer) в работе, передать Заказчику все артефакты разработки (исходный код и сторонние библиотеки, конфигурации, сборочные и собранные образы и др.); – подготовить полноценное описание функционала, включенного в релиз, с необходимыми схемами и пояснениями к обновлению на стендах Заказчика; – обеспечить тестирование разработанного функционала на стендах Заказчика силами Подрядчика; – решение о переносе измененного ППО на продуктивный стенд принимается Заказчиком по итогу результатов проведенного тестирования; – обеспечить техническое сопровождение процедуры тестирования ППО и переноса измененного ППО на продуктивный стенд Заказчика; – обеспечить экстренное внесение соответствующих изменений в случае выявления некорректной работы продуктивного стенда Заказчика после проведения обновления по итогам разработанного изменения в кратчайшие сроки; – актуализировать при необходимости комплект эксплуатационной документации: o руководство пользователя; o руководство администратора; o иные документы (при необходимости). Результат выполнения изменений должен быть отражен в Отчете по оказанию услуг. Типы и приоритеты изменений могут быть скорректированы в процессе оказания услуг исключительно по согласованию с Заказчиком - 4.3.6.4.2. Требования к изменению настроек функционирования Изменение настроек функционирования может проводиться в рамках допустимых пределов изменения функционирования, заложенных в архитектуру Модуля СЦ. Изменение настроек функционирования включает в себя изменение данных и справочников, изменение форм документов, формируемых Модулем СЦ, изменение и настройку форматов и версий передачи данных в смежные системы. Доработка программного кода Модуля СЦ может допускаться (в случае необходимости) при выполнении работ по адаптации функций Модуля СЦ в части изменения формата передачи данных в смежные информационные системы при условии соблюдения требований пункта 29.3 приказа ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации» - 4.3.6.5. Требования к услугам по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности По запросу Заказчика Подрядчик должен провести работу по приведению ППО в соответствие с требованиями по обеспечению информационной безопасности. Критичность уязвимости оценивается в соответствии в соответствии с Методическим документом ФСТЭК России «Методика оценки уровня критичности уязвимостей программных, программно-аппаратных средств» (утвержден ФСТЭК России 30.06.2025), а также с учетом ГОСТ 56545-2015 и международными стандартами (CVSS 3.0 и выше), и задает необходимый срок устранения. В процессе проведения Заказчиком обследования Модуля СЦ и выявления уязвимостей в ППО, связанных с исходным кодом Модуля СЦ и/или используемыми компонентами (библиотеками), Заказчик направляет Подрядчику обращение (заявку) на устранение, с указанием критичности и срочности принятия мер по устранению в СРО. - Подрядчик при оказании услуг по обновлению или устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности должен: – провести анализ уязвимостей и связанных с ними исходным кодом и/или используемыми компонентами (библиотеками); – выработать варианты устранения указанных уязвимостей и согласовать с Заказчиком их реализацию; – своевременно внести изменения в исходный код Модуля СЦ и/или используемые компоненты (библиотеки) и подготовить соответствующее обновление; – провести обновление Модуля СЦ в тестовом контуре Заказчика и проинформировать Заказчика о готовности проведения тестирования; – протестировать успешность обновления или устранения уязвимостей в ППО и корректность функционирования Модуля СЦ на тестовом контуре, совместно с Заказчиком; – при невозможности незамедлительного устранения уязвимости приоритетов «Критический» и «Высокий» Подрядчик обязан предоставить исчерпывающий список причин и согласовать план достаточных компенсирующих мер с ответственными сотрудниками Заказчика. Результат внесения изменений отображается в соответствующей записи в СРО и в составе Отчета об оказанных услугах - 4.3.6.5.1. Требования к порядку оказания услуг по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности Подрядчик в соответствии с приоритетами обращений и контрольными сроками исполнения (см. Приложение Б к ТЗ) оценивает техническую возможность и сроки устранения уязвимостей, и реализацию обновления Модуля СЦ. По итогу проведения оценки Подрядчик направляет в заявке СРО Заказчику заключение о возможности устранения уязвимостей и/или обновления в ППО и согласует с Заказчиком проведение данных работ - При проведении работ по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности необходимо выполнить следующее: – Заказчику сформировать заявку на устранение (обновление) в СРО с полным списком обнаруженных уязвимостей и планируемыми работами; – согласовать в рабочем порядке время начала и завершения работ, перечень работ, выполняемых в рамках обновления или устранения уязвимостей в ППО с Заказчиком; – оповестить Заказчика о начале проведения работ на тестовом контуре; – провести работы по обновлению или устранению уязвимостей в ППО на тестовом контуре Модуля СЦ в установленные сроки; – протестировать выполнение работ в тестовом контуре и проинформировать Заказчика о готовности переноса ППО на продуктивный контур; – силами Заказчика обновить продуктивный контур Модуля СЦ, в соответствии с планом устранения и выполненными работами; – совместно с Заказчиком проверить корректность функционирования Модуля СЦ и устранения уязвимостей в продуктивном контуре Модуля СЦ по результатам обновления; – при необходимости актуализировать документацию (описание архитектуры, анкеты постановки на мониторинг и иные документы). Любые изменения в части обновления или устранения уязвимостей в ППО на промышленном контуре Модуля СЦ должны применяться только в случае успешного проведения аналогичных работ на тестовом контуре. Детальный порядок оказания услуги по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности определен в Регламенте оказания Услуг - 4.4. Требования к видам обеспечения 4.4.1. Требования к лингвистическому обеспечению Документация на Модуль СЦ должна разрабатываться на русском языке. Взаимодействие пользователей с Модулем СЦ посредством графического интерфейса должно происходить на русском языке за исключением сообщений, зависящих от настроек системного программного обеспечения, установленного на рабочих местах пользователей. При разработке программных решений Модуля СЦ должно быть предусмотрено использование языков программирования высокого уровня, приведенных в Таблице 7. Таблица 7. Языки и средства разработки, специального программного обеспечения Модуля СЦ Категория Наименование Назначение Языки программирования Kotlin Разработка серверной логики и сервисов (backend) JavaScript / TypeScript Разработка клиентской части (frontend) Python Разработка скриптов интеграции, обработки данных и автоматизации Фреймворки и библиотеки Vue.JS Разработка пользовательских интерфейсов (веб-интерфейсы компонентов визуализации и отчетности) React Разработка пользовательских интерфейсов (при необходимости создания сложных интерактивных компонентов) Решения по лингвистическому обеспечению, включая перечень используемых языков программирования, должны быть согласованы с Заказчиком на этапе технического проектирования - 4.4.2. Требования к математическому обеспечению Требования к математическому обеспечению не предъявляются. 4.4.3. Требования к метрологическому обеспечению Требования к метрологическому обеспечению не предъявляются. 4.4.4. Требования к организационному обеспечению Требования к организационному обеспечению не предъявляются. 4.4.5. Требования к методическому обеспечению Задачи методического обеспечения Модуля СЦ должны быть обеспечены за счет использования технологических и методических документов касающихся вопросов функционирования транспортного комплекса и разработки и эксплуатации ПО. 4.4.6. Требования к информационному обеспечению Состав, структура и способы организации информационного обеспечения в Модуле СЦ должны быть определены на этапе технического проектирования. Факты информационного обмена с внешними системами должны фиксироваться в соответствующем журнале - 4.1. Требования к структуре Модуля СЦ В процессе работ по развитию Системы должны сохраниться основные требования к построению архитектуры Системы в соответствии с принципами трехуровневой архитектуры: 1. уровень хранения данных или уровень базы данных (сервер СУБД); 2. уровень сервера приложений (сервер аналитической обработки); 3. презентационный уровень, обеспечивающий взаимодействие с клиентскими приложениями. В состав Системы должны входить следующие основные компоненты: 4. сервер баз данных; 5. сервер приложений; 6. веб-сервер. Сервер баз данных должен обеспечивать хранение и целостность хранимых данных, создание резервных копий, ведение журнала транзакций, восстановление данных после сбоев. Сервер приложений должен обеспечивать обработку запросов, поступающих от клиентских приложений (через веб-сервер), формирование ответов на запрос в доступном пользователю виде (формирование пользовательских интерфейсов). Веб-сервер должен обеспечивать взаимодействие с оператором и внешними системами по HTTP / HTTPS протоколу в режиме «запрос-ответ» (получения запросов от пользователя и передачи ответа в виде соответствующей информации, обработанной серверами приложений). Взаимодействие Системы с пользователем должно отвечать требованиям модели «тонкого клиента» (т.е. представлять на стороне клиента (пользователя) лишь графический пользовательский интерфейс). Все составляющие Системы должны использовать единую методологию и отвечать единым принципам взаимодействия, надежности и управления. Перечень компонентов Модуля СЦ представлен в Таблице 4. Таблица 4. Перечень компонентов Модуля СЦ, в отношении которых выполняются работы по развитию № п.п. Наименование компонента Модуля СЦ Раздел ТЗ 1 Компонент регистрации событий 4.2.1. 2 Компонент отчетности 4.2.2 3 Компонент визуализации 4.2.3 4 «Интерактивная карта» (компонент создается) 4.2.4 5 Компонент администрирования 4.2.5 - 4.2. Требования к дорабатываемым функциям модуля СЦ 4.2.1. Развитие компонента регистрации событий (1 очередь) Должны быть выполнены следующие доработки: – обеспечение логирования действий пользователя, связанных с карточкой события; – доработка объектной модели в части создания новых типов сущностей (карточек) с учетом реализуемых интеграций с информационными ресурсами (силы и средства предупреждения и ликвидации ЧС и нештатных ситуаций на транспорте, ТС, ограничения воздушного пространства, неблагоприятные и опасные природные явления); – реализация механизма установления связи между сущностями в Модуле СЦ автоматизированным и ручным способами (события, природные явления, силы и средства предупреждения и ликвидации ЧС и нештатных ситуаций на транспорте, ограничения воздушного пространства, ОТИ, ТС и др.); – отображение в карточке установленных связей между сущностями. - 4.4.7. Требования к программному обеспечению Общесистемное ПО, используемое в составе Модуля СЦ, должно быть зарегистрировано в Едином реестре российских программ для электронных вычислительных машин и баз данных и соответствовать рекомендованным показателям эффективности и соответствующим им значениям индикаторов эффективности перехода подведомственных организаций на использование российского ПО, заданных Приказом Минцифры России от 18.01.2023 № 21 «Об утверждении методических рекомендаций по переходу на использование российского программного обеспечения, в том числе на значимых объектах критической информационной инфраструктуры Российской Федерации, и о реализации мер, направленных на ускоренный переход органов государственной власти и организаций на использование российского программного обеспечения в Российской Федерации». Применяемое в системе программное обеспечение должно соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации, постановления Правительства Российской Федерации от 23 декабря 2024 г. № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц» - Прикладное программное обеспечение должно отвечать следующим требованиям: – совместимость программных продуктов в части используемых технических средств, системного программного обеспечения и общесистемной инфраструктуры в пределах требований к техническому обеспечению, а также их информационная совместимость в пределах требований к информационному обмену; – обеспечение трехуровневой архитектуры с разделением на уровень хранения данных (сервер БД), уровень бизнес-логики (сервер приложений) и уровень представления ( - 4.4.7.1. Требования к инструментам разработки и процессу контроля версий программного обеспечения 4.4.7.1.1. Система контроля версий Для управления исходным кодом должна использоваться система контроля версий кода, развернутая в инфраструктуре Заказчика. 4.4.7.1.2. Правила именования веток Имя ветки должно соответствовать следующему формату: / / Категории веток: ? feature/ — разработка новой функциональности, а также рефакторинг или удаление существующей; ? fix/ — исправление ошибок; ? hotfix/ — срочные исправления, применяемые в обход стандартного процесса разработки; ? test/ — для проведения экспериментов, не влияющих на основную разработку. Идентификатор задачи: после категории указывается ссылка на задачу (issue) в системе контроля версий кода. Описание: добавляется краткое описание решаемой задачи в формате kebab-case (слова разделяются дефисами, например, add-user-auth). Примеры именования веток: ? feature/#123/add-payment-integration; ? fix/#45/correct-calculation-logic; ? hotfix/#67/urgent-database-connection-patch. 4.4.7.1.3. Правила именования коммитов Сообщение коммита должно соответствовать соглашению Conventional Commits и состоять из категории и описания: : ? fix — исправление ошибки. Примеры сообщений коммитов: ? feat: добавление формы регистрации пользователя; ? fix: исправление ошибки валидации email-адреса; ? refactor: оптимизация алгоритма сортировки данных; ? chore: обновление версий в файле dependencies. 4.4.7.1.4. Модель ветвления В процессе разработки используются следующие основные ветви: ? main / master — стабильная ветка, содержит только код, прошедший полное тестирование и развернутый в продуктивных контурах; ? dev — ветка для интеграции завершенных задач, предназначенная для сборки и тестирования в тестовых средах. Попадание кода в main осуществляется только через Merge Request (MR) из dev - 4.2.2. Развитие компонента отчетности (3 очередь) Должна быть обеспечена автоматизация процессов формирования отчетов о ЧС и нештатных ситуациях на транспорте, в т.ч. на основе данных из внешних систем. Включает следующие доработки: – разработка шаблонов отчетов в различных форматах (табличный, текстовый); – реализация выбора фотоматериалов для включения в справку; – форматирование содержимого справок с учетом правил русского языка в отношении окончаний слов (в зависимости от падежа, склонения, числа и рода); – автоматизированное формирование выводов к содержимому справки на основе настраиваемых критериев; – создание интерфейса выбора параметров (фильтрации) для формирования отчетов: o состав полей для включения в отчёт; o настройка диапазонов значений характеристик и дат; o порядок отображения полей; o настройка заголовка. – реализация способа подготовки отчётов в асинхронном режиме (очереди); – реализация интерфейса компонента формирования отчетности для отображения очереди формирования отчетов и статусов их подготовки; – экспорт отчётов в форматы xlsx, csv и справок в форматы pdf, docx. Необходимо разработать не менее 10 шаблонов отчетов и/или справок. Перечень, структура и содержание шаблонов должны быть согласованы с Заказчиком на этапе технического проектирования. - 4.2.3. Развитие компонента визуализации (2 очередь) В рамках развития компонента визуализации должны быть выполнены следующие доработки, обеспечивающие: – вывод перечней (списков) сил и средств предупреждения и ликвидации ЧС и нештатных ситуаций на транспорте с отображением мест их постоянного размещения (дислокации) на карте, включая: o отображение зон ответственности на карте; o возможность их фильтрации (по видам транспорта, регионам и пр.); o реализацию инструмента расчета расстояния (с использованием сети автомобильных и железных дорог) между местом события и местами дислокации сил и средств, а также вывода маршрутов на карте; – отображение зон (полигонов) с установленными ограничениями движения в воздушном пространстве на карте; – отображение термических точек; – реализация возможности отображения данных из паспорта региона, отображаемого в модуле iМинтранс (модуль АСУ ТК); – отображение краткой карточки сущностей и ОТИ (краткой информации и/или динамических характеристик объекта) при выборе объекта на карте с возможностью перехода в полную карточку сущности и ОТИ; – отображение данных от Росгидромета, предусматривающих: o отображение неблагоприятных и опасных природных явлений на карте (с заданным периодом обновления данных); o управление отображением явлений на карте, включая настройку состава отображаемых объектов, поиск, фильтрацию, с использованием соответствующей панели управления; o выведение краткой карточки явления при выборе объекта, с возможностью перехода в полную карточку объекта - – отображение на карте связанных сущностей и ОТИ; – реализация функции выбора темного и светлого стилей отображения элементов интерфейса, карточек сущностей, картографической основы и объектов, отображаемых на карте; – реализация механизма для выбора картографической основы в одном из распространенных форматов WMTS, TMS, MVT и др. Должна быть предусмотрена возможность настройки перечня картографических основ и параметров доступа к ним; – настройка базового набора дашбордов, содержащих преднастроенные виджеты о количестве событий в разрезе видов транспорта с возможностью перехода к исходным данным (карточкам событий, ОТИ и т.д.), с фильтрацией по параметрам. Параметры фильтрации должны быть определены на этапе технического проектирования. Должно быть обеспечено автоматическое и принудительное обновление данных, отображаемых на дашбордах - 4.4.7.1.5. Требования к используемым зависимостям (библиотекам) Все внешние зависимости проекта должны быть зафиксированы с указанием точных версий. Для контроля версий зависимостей в репозиторий обязательно должны быть включены следующие файлы: · Для JavaScript: package-lock.json или yarn.lock; · Для Python: requirements.txt (с зафиксированными версиями) или Pipfile.lock; · Для Go: go.mod и go.sum; Загрузка всех зависимостей должна производиться исключительно через внутренний прокси-репозиторий Заказчика, настроенный в соответствующем системе менеджере пакетов. Запрещается: · Использование плавающих версий (например, ^1.2.3, ~4.5.0, latest); · Использование библиотек, содержащих критические уязвимости, в том числе зарегистрированные в реестре CVE (Common Vulnerabilities and Exposures). 4.4.7.1.6. Требования к процессу непрерывной интеграции (CI) Сборка программного обеспечения, включая этапы компиляции, тестирования и анализа кода, должна выполняться исключительно в инфраструктуре непрерывной интеграции Заказчика. 4.4.7.1.7. Требования к хранению артефактов сборки Все артефакты сборки (результирующие пакеты, Docker-образы и т.д.) подлежат обязательному хранению в предназначенной для этого инфраструктуре Заказчика (артефакторий). Запрещается размещение финальных артефактов сборки на сторонних ресурсах - 4.4.8. Требования к техническому обеспечению Количество серверов, подключаемых и настраиваемых сервисов, их параметров, схемы соединений и настройки межсетевого взаимодействия должны быть согласованы с Заказчиком на этапе № 1 Техническое проектирование. Доступ к комплексу технических средств предоставляется Заказчиком по письменному запросу Подрядчика. Применяемые в Системе программно-аппаратные и аппаратные комплексы должны соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации», требованиям Постановления Правительства Российской Федерации от 23 декабря 2024 г. № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц». Модуль СЦ, работающий в составе АСУ ТК, развернут на вычислительных мощностях ГЦОД СИЦ Минтранса России - 4.5. Общие технические требования 4.5.1. Требования к численности и квалификации персонала и пользователей Модуля СЦ Программное обеспечение Модуля СЦ не должно требовать изменения штатной численности персонала Заказчика. Программное обеспечение Модуля СЦ не должно требовать наличия у пользователей дополнительной квалификации в сфере информационных технологий, кроме базовых знаний в обращении с персональным компьютером, базовых навыков работы в интернет-обозревателях и знаний о Модуле СЦ в объеме документов Руководство пользователя, Руководство администратора - 4.2.4. Создание компонента «Интерактивная карта» (2 очередь) В составе создаваемого компонента должны отображаться данные, доступные в компоненте визуализации. Требования к интерфейсу интерактивной карты: – интерактивная карта должна быть представлена в виде объемной карты с учетом макетов, представленных в Приложении А к ТЗ; – интерфейс должен корректно отображаться на экранах мониторов (разрешение Full HD 1920?1080), телевизоров (разрешение 4К 3840?2160), жидкокристаллических панелей для видеостены, используемой Заказчиком, с параметрами каждой панели: диагональ 55 дюймов, разрешение 1920x1080; – интерфейс должен корректно отображаться на планшетных устройствах с диагональю экрана 10-12 дюймов, конкретные требования должны быть уточнены на этапе технического проектирования; – должна быть обеспечена кластеризация и генерализация отображения объектов на карте при изменении масштаба; – должно быть обеспечено отображение основных характеристик объектов при выборе их на карте; – должно быть обеспечено управление отображением слоев на карте; – должна быть обеспечена настройка цветовой индикации отображаемых объектов транспортной инфраструктуры; – должно быть обеспечено отображение легенды карты, содержащей отображаемые объекты на карте; – должна быть обеспечена возможность одновременного отображения не менее 5 000 ОТИ и ТС на карте. - На интерактивной карте должны быть отображены подвижные объекты совместно с объектами транспортной инфраструктуры (ОТИ), включая следующие возможности: § отображение местоположения транспортных средств (воздушный, водный и автомобильный транспорт) на карте в режиме реального времени (с заданным периодом обновления данных); § отображение маршрутов движения всех ТС за выбранный период времени, в том числе с использованием эффектов анимации; § отображение маршрутов движения ТС, связанных с карточкой события: ТС, являющихся участниками события, и ТС, находящиеся в заданном радиусе от события; § управление отображением сущностей и ОТИ на карте, включая настройку состава отображаемых объектов, поиск, фильтрацию, с использованием соответствующей панели управления и наглядным представлением результатов; § автоматическое изменение вида отображения объектов (цветовая индикация) по заданным условиям (например, при достижении критических значений параметров, характеризующих функционирование объекта); Должна обеспечиваться производительность обновления изображения на экране в 30 кадров в секунду на тестовой конфигурации пользовательского устройства (модель Бештау AIO2402/B560, входящая в Реестр российской промышленной продукции под номером 10394100 или аналог) при одновременном отображении не менее 5 000 объектов и 200 уникальных моделей объектов. Макеты интерфейсов Модуля СЦ должны быть предварительно согласованы с Заказчиком и разработаны с учетом требований ГОСТ Р ИСО 9241-161-2016 «Элементы графического пользовательского интерфейса» - 4.5.2. Требования к режимам функционирования Модуля СЦ Модуль СЦ должен предусматривать наличие следующих режимов работы: – штатный; – регламентный (профилактический); – аварийный. Основным режимом функционирования является штатный. В штатном режиме все компоненты корректно и полностью выполняют свои функции. Перерывов в работе как Модуля СЦ в целом, так и одного, либо нескольких компонентов не предусмотрено. Режим регламентного (профилактического) обслуживания предназначен для проведения работ по обновлению и техническому обслуживанию компонентов Модуля СЦ, а также резервному копированию данных. При работе в данном режиме допускаются перерывы в работе Модуля СЦ с предварительным информированием пользователей. Состав процедур по регламентному обслуживанию Модуля СЦ и их периодичность определяются Подрядчиком в процессе выполнения работ по созданию Модуля СЦ. В режиме регламентного (профилактического) обслуживания Модуль СЦ может функционировать с частичным ограничением своих функциональных возможностей, либо без ограничения, но со снижением показателей надежности и производительности. Перевод в данный режим работы должен осуществляться сразу после начала выполнения любой операции, отнесенной к этому режиму, с последующим возвратом в штатный режим функционирования сразу после ее завершения. Перевод в указанный режим должен осуществляться при возникновении необходимости проведения работ по обновлению и техническому обслуживанию компонентов Модуля СЦ, а также резервному копированию данных с условием предварительного оповещения пользователей. Аварийный режим функционирования характеризуется отказом одной или нескольких подсистем, вызванных выходом из строя аппаратного и/или программного обеспечения, а также в случае временной неработоспособности каналов связи между серверами. - В аварийном режиме осуществляется поиск неисправностей и проведение работ по их устранению. Перевод в аварийный режим должен осуществляться при возникновении сбоев, аварий и прочих незапланированных воздействий, сразу после наступления одной или нескольких аварийных ситуаций, с последующим возвратом в штатный режим функционирования сразу после окончания восстановительных работ. ПО Модуля СЦ должно обладать надежностью, обеспечивающей работу пользователей в произвольном режиме и оперативное восстановление работоспособности при сбоях. В целях обеспечения надежного функционирования ПО должно предусматривать: – сохранение целостности данных при нештатном завершении работы компонентов Модуля СЦ; – сохранение работоспособности программного обеспечения при некорректных действиях пользователя; – резервное копирование базы данных Модуля СЦ. – время восстановления работоспособности Модуля СЦ после отказа не более 4 часов. – отказоустойчивость на уровне 99% при единовременной количестве не менее 200 пользовательских сессий в Модуле СЦ. Указанные характеристики приведены без учета характеристик надежности инфраструктуры и времени передачи информации по каналам связи. При возникновении сбоев в аппаратном обеспечении, включая аварийное отключение электропитания, Модуль СЦ должен автоматически восстанавливать свою работоспособность (не требовать перенастройки) после устранения сбоев и корректного перезапуска аппаратного обеспечения - 4.2.4.1. Требования к технической реализации компонента «Интерактивная карта» При реализации компонента «Интерактивная карта» должны учитываться требования, указанные ниже. 4.2.4.1.1. Требования к отображению элементов Повторяющихся элементы карты (ТС, ОТИ, события и пр.) должны отрисовываться с использованием аппаратного создания экземпляров объектов на пользовательском устройстве (WebGL/WebGPU)). Отрисовка каждого объекта отдельным запросом не допускается, должна обеспечиваться возможность одновременного отображения не менее 5 000 объектов без снижения производительности (30 кадров в секунду на тестовой конфигурации). 4.2.4.1.2. Уровни детализации объектов Для управления отображением сложных объектов должно быть создано не менее 3-х уровней детализации, отображаемых при изменении масштаба с возможностью автоматического переключения между уровнями. Все отображаемые объекты должны масштабироваться с учетом разрешения экрана пользователя с сохранением качества детализации. 4.2.4.1.3. Полигональная оптимизация и текстурирование При реализации компонента «Интерактивная карта» должна обеспечиваться технология рельефного тестурирования объектов. Не должны использоваться высокополигональные трехмерные модели. Все повторяющиеся элементы должны генерироваться единоразово и повторно использоваться при последующих отображениях. 4.2.4.1.4. Управление памятью Требуется реализовать потоковую загрузку на устройство пользователя элементов карты и текстур. Загрузка данных целиком при старте приложения не допускается. Необходимо реализовать механизм очистки памяти от элементов, которые находятся вне области видимости камеры в течение заданного времени. 4.2.4.1.5. Требования к взаимодействию пользователя с интерфейсом компонента «Интерактивная карта» Программная реализация механизмов управление камерой (масштабирование и навигация) должна быть выполнена с поддержкой технологии WebAssembly (WASM). Элементы управления должны являться неотъемлемой частью интерактивной карты. - 4.2.5. Развитие компонента администрирования (3 очередь) Должна быть выполнена доработка ролевой модели. Ролевая модель должна обеспечивать управление доступом к отдельным объектам Модуля СЦ и их элементам (атрибутам) с разграничением по видам транспорта, регионам и пр., в частности: – определение набора конкретных действий, доступных пользователям (выполняемых над объектом доступа, например, удаление записи, редактирование записи, формирование отчета и др.); – реализация возможности объединения пользователей в группы; – определение прав доступа для групп пользователей; – реализация интерфейса визуальной настройки прав доступа пользователей к объектам Модуля СЦ - Технические меры по обеспечению надежности должны предусматривать: – резервирование критически важных компонентов и данных Системы и отсутствие единой точки отказа; – использование программного резервирования (программной избыточности); – изменение конфигурации используемых средств и применение специализированного ПО, обеспечивающего высокую надёжность. Организационные меры по обеспечению надежности должны быть направлены на минимизацию ошибок пользователей (а также обслуживающего персонала при эксплуатации и проведении работ по обслуживанию), минимизацию времени ремонта или замены вышедших из строя компонентов за счёт: – обеспечения для обслуживающего персонала требуемого уровня квалификации; – регламентации и нормативного обеспечения выполнения работ обслуживающим персоналом; – своевременной диагностики неисправностей. Расчетное значение коэффициента доступности Модуля СЦ должно составлять не менее 0,95. - 4.5.3. Требования по диагностированию Модуля СЦ Диагностирование Модуля СЦ должно осуществляться путем анализа записей в системных журналах СУБД, операционных систем серверов, а также с помощью встроенных средств диагностирования общего программного обеспечения Модуля СЦ. Диагностированию подлежат: – сбои и нарушения функционирования технического обеспечения (серверов) Модуля СЦ; – сбои и нарушения функционирования системного программного обеспечения серверов, используемых для работы Модуля СЦ; – сбои и нарушения функционирования прикладного программного обеспечения серверов, используемых для работы Модуля СЦ; – случаи недоступности (отсутствия ответа) или некорректные ответы внешних систем; – сбои и нарушения функционирования СУБД; – сбои при выполнении регламентных операций резервного копирования. При возникновении аварийных ситуаций либо ошибок в программном обеспечении диагностические инструменты должны позволять сохранять набор информации, необходимой для идентификации и устранения проблемы. Модуль СЦ и ее компоненты должны обеспечивать возможность диагностики своей работоспособности с возможностью интеграции с модулем мониторинга АСУ ТК. Набор передаваемых журналов и метрик должен быть определен на этапе технического проектирования - 4.5.4. Требования к надежности Должно быть предусмотрено сохранение работоспособности Модуля СЦ при некорректных действиях пользователя и сохранение целостности данных при нештатном завершении работы Модуля СЦ (отказ рабочей станции, потеря сетевого доступа и т.п.). Модуль СЦ должен предоставлять механизмы обеспечения сохранности данных через применение процедур резервного копирования и восстановления, описанных в документации на Систему. Ключевые показатели надежности информационной системы — допустимое время на восстановление работоспособности Модуля СЦ (RTO - recovery time objective) и/или допустимый интервал времени потери изменений в данных при сбоях/отказах (RPO – recovery point objective) должны быть определены Подрядчиком и согласованы с Заказчиком на этапе технического проектирования - 4.2.6. Взаимосвязи с внешними автоматизированными системами (1 очередь) Способы взаимодействия с внешними информационными системами должны быть определены на этапе технического проектирования. Должны быть выполнены следующие доработки: – интеграции с информационными ресурсами в целях получения данных о движении подвижных ТС (воздушные суда, суда водного транспорта); – интеграция с информационным ресурсом в целях получения данных о событиях на железнодорожном транспорте. Реализация интеграций должна включать проектирование и реализацию интеграционных механизмов обмена данными с учетом доступных вариантов реализации, обеспечение защищенных способов взаимодействия, настройку отображения отдельных данных на карте (настройка слоев). Взаимодействия, имеющие каналы связи, выходящие за пределы контролируемой зоны взаимодействующих систем, считаются защищенными, если для их защиты используются программные и/или программно-аппаратные шифровальные (криптографические) средства, сертифицированные ФСБ России (далее – СКЗИ). Выбор СКЗИ, схемы подключения и требуемого класса криптостойкости должен производиться в соответствии с Техническими условиями на подключение к информационным ресурсам ФГБУ «СИЦ Минтранса России» и инструкциями по подключению пользователей к ресурсам инфраструктуры Головного центра обработки данных, утвержденных приказом директора ФБГУ «СИЦ Минтранса России» от 24.05.2024 № 21-ОД - 4.3. Требования к оказанию услуг по технической поддержке Модуля СЦ 4.3.1. Общие требования к оказанию Услуг Техническая поддержка Модуля СЦ должна осуществляться с учетом требований постановления Правительства Российской Федерации от 06.07.2015 N 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации». Подрядчик обязан выполнять требования законодательства в сфере защиты информации, требования по защите информации, информационной безопасности, указанные в локальных нормативных актах ФГБУ «СИЦ Минтранса России», регламентирующих условия информационного взаимодействия, защиты информации и подключения к информационным ресурсам ФГБУ «СИЦ Минтранса России», участвующих в информационном взаимодействии в рамках оказания услуг по технической поддержке АСУ ТК в 2026 году - 4.3.1.1. Требования к составу и содержанию услуг третьего уровня технической поддержки Оказание услуг по технической поддержке Системы осуществляется в рамках этапов в соответствии с календарным планом. Подрядчик в течение 5 рабочих дней с даты заключения Контракта должен предоставить со своей стороны, а Заказчик со своей стороны Матрицу ответственных за взаимодействия в соответствии с Приложением 1 к Регламенту оказания услуг по третьему уровню технической поддержки Модуля СЦ (далее – Регламент, Приложение В). Подрядчик в течение 10 рабочих дней с даты заключения Контракта должен провести мероприятия по организации третьего уровня технической поддержки в соответствии с Регламентом. Услуги по третьему уровню технической поддержки Модуля СЦ должны включать: – организацию Подрядчиком третьего уровня технической поддержки; – информационно-консультационную поддержку работников Заказчика; – решение инцидентов, связанных с работой ППО; – адаптационное, конфигурационное и коррекционное сопровождение Модуля СЦ (в рамках действующих программных модулей и функциональности); – устранение уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности - 4.5.5. Требования к информационной безопасности Работы по защите информации/информационной безопасности, не включенные в состав настоящего раздела, требуемые в соответствии с требованиями постановления Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации», а также нормативно правовых актов в области защиты персональных данных и обеспечения безопасности объектов критической информационной инфраструктуры, будут проведены в рамках исполнения отдельного контракта, заключенного по результатам отдельной закупочной процедуры (не является частью данного ТЗ), включающего: – определение актуальных угроз безопасности информации и актуализация модели угроз безопасности информации (при необходимости); – выполнение требований о согласовании технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России в установленном порядке; – выполнение требований по устранению Подрядчиком замечаний и недостатков, в случае их выявления при согласовании Заказчиком технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России; – выполнение требований к классу защищенности ГИС, уровню защищенности персональных данных и категории значимости объекта КИИ РФ, установленных для Головного центра обработки данных ФГБУ «СИЦ Минтранса России» (далее – ГЦОД); - – определение перечня объектов защиты информационной системы; – описание (актуализированных) требований к системе защиты информации, а также к мерам защиты информации информационной системы в зависимости от установленных классов защищенности, уровня защищенности персональных данных и категории значимости объектов КИИ РФ (приказы ФСТЭК России № 21, 117, 239); – выполнение требований к мерам по защите ГИС от атак, направленных на отказ в обслуживании, в соответствии с пунктами 30, 34, 59, 63 Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений, утвержденных приказом ФСТЭК России от 11.04.2025 № 117; – описание (актуализированных) требований по защите информации, подлежащих реализации в информационно телекоммуникационной инфраструктуре ГЦОД; – выполнение требований о применении сертифицированных средств защиты информации, включая их классы защиты и уровни доверия; – выполнение требований о запрете использования с 01.01.2025 органами (организациями) средств защиты информации странами происхождения, которых являются иностранные государства в соответствии с пунктом 6 Указа Президента Российской Федерации от 01.05.2022 № 250; – выполнение требований по обеспечению непрерывного взаимодействия с ГосСОПКА в установленном порядке; - 5. СОСТАВ И СОДЕРЖАНИЕ РАБОТ ПО РАЗВИТИЮ И ТЕХНИЧЕСКОЙ ПОДДЕРЖКЕ МОДУЛЯ СЦ (КАЛЕНДАРНЫЙ ПЛАН) - Сдача-приемка результатов выполненных работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная техническая документация, а также результаты работ предоставляются Заказчику в порядке, предусмотренном Контрактом и ТЗ, до размещения Подрядчиком в ЕИС документа о приемке. Документ о приемке размещается в ЕИС по каждому этапу в соответствии с условиями Контракта. Этапы выполнения работ по развитию Модуля СЦ приведены в Таблице 11. Таблица 11. Этапы выполнения работ по развитию Модуля СЦ. № этапа Наименование этапа Результат (отчетная документация) Срок исполнения этапа - - Значение характеристики не может изменяться участником закупки - 1 Техническое проектирование Сопроводительным письмом предоставляются Заказчику: · Технический проект, включая следующие документы: – Ведомость технического проекта; – Ведомость машинных носителей информации – Пояснительная записка; – Описание информационного обеспечения системы; – Описание автоматизируемых функций; – Схема функциональной структуры; – Описание организации информационной базы; – Описание программного обеспечения; · Макеты экранных форм компонента «Интерактивная карта»; · Руководство по безопасной разработке программного обеспечения; · Документ о приемке Начало: с даты заключения контракта Окончание: не позднее 31.07.2026 - 2 Услуги по технической поддержке Модуля СЦ (с даты заключения контракта по 10.09.2026) По окончании оказания Услуг сопроводительным письмом предоставляются Заказчику: – Отчет об оказанных Услугах по технической поддержке; – Актуальные на дату окончания оказания Услуг по данному этапу исходные коды прикладного ПО на электронном носителе (в случае внесения изменений); – Инструкция по сборке и развертыванию (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство пользователя (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство администратора (в случае внесения изменений); – Документ о приемке Начало: с даты заключения контракта Окончание: не позднее 10.09.2026 - 3 Разработка программного обеспечения (1 очередь, пп. 4.2.1, 4.2.6 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ; – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 1 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 1 очереди; – Руководство по резервному копированию; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 16.09.2026 - 4 Разработка программного обеспечения (2 очередь, пп. 4.2.3, 4.2.4 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ. – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 2 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 2 очереди; – Руководство по резервному копированию; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 25.09.2026 - 5 Разработка программного обеспечения (3 очередь, пп. 4.2.2, 4.2.5 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ; – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 3 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 3 очереди; – Руководство по резервному копированию; – Описание ролевой модели; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 09.10.2026 - 6 Опытная эксплуатация (1 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акт о завершении опытной эксплуатации 1 очереди; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке 17.09.2026 Окончание: не позднее 26.10.2026 - 7 Опытная эксплуатация (2 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акт о завершении опытной эксплуатации 2 очереди; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке 26.09.2026 Окончание: не позднее 26.10.2026 - 8 Опытная эксплуатация (3 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Акт о завершении опытной эксплуатации 3 очереди; – Документ о приемке Начало: с 10.10.2026 Окончание: не позднее 26.10.2026 - 9 Приемочные испытания Сопроводительным письмом предоставляются Заказчику: – Программа и методика приёмочных испытаний; – Протокол приемочных испытаний; – Исходные коды и дистрибутивы на электронном носителе (при условии внесения изменений, с учетом доработок по результатам опытной эксплуатации и проведенных испытаний); – Комплект рабочей документации на Модуль СЦ (при условии внесения изменений, с учетом доработок по результатам опытной эксплуатации и проведенных испытаний); – Акт приемки Системы в эксплуатацию; – Акт приемки-передачи исключительных прав на объект; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке; – Документы в соответствии с разделом 4.5.9 ТЗ; – Обеспечение гарантийных обязательств Начало: с 27.10.2026 Окончание: не позднее 10.11.2026 - 10 Услуги по технической поддержке Модуля СЦ (с 11.09.2026 по 15.12.2026) По окончании оказания Услуг сопроводительным письмом предоставляются Заказчику: – Отчет об оказанных Услугах по технической поддержке; – Актуальные на дату окончания оказания Услуг по данному этапу исходные коды прикладного ПО на электронном носителе (в случае внесения изменений); – Инструкция по сборке и развертыванию (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство пользователя (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство администратора (в случае внесения изменений); – Документ о приемке Начало: с 11.09.2026 Окончание: не позднее 15.12.2026 - Работы по развитию Системы (за исключением этапов проведения опытной эксплуатации и услуг по технической поддержке) могут быть выполнены досрочно. При досрочном выполнении работ (этапов работ) Подрядчик в письменной форме уведомляет Заказчика о готовности представить для приемки результаты проведения работ в соответствии с требованиями Контракта. Подрядчик также вправе досрочно приступать к работам в рамках очередного этапа при наличии технической, организационной готовности - при условии получения соответствующего согласования Заказчиком. Сдача-приемка результатов выполненных работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная, техническая документация, а также результаты Работ по каждому этапу предоставляется Заказчику в порядке, предусмотренном Контрактом и настоящим Техническим заданием, до размещения Подрядчиком в Единой информационной системе в сфере закупок документа о приемке. Документ о приемке размещается в ЕИС по каждому этапу в соответствии с условиями Контракта. Согласование документов осуществляется в электронном виде посредством переписки с адресов электронной почты Заказчика и Подрядчика, указанных в контракте. - 6. ПОРЯДОК РАЗРАБОТКИ МОДУЛЯ СЦ - Проектирование Модуля СЦ должно включать разработку следующих документов: – Ведомость технического проекта; – Ведомость машинных носителей информации – Пояснительная записка; – Описание информационного обеспечения системы; – Описание автоматизируемых функций; – Схема функциональной структуры; – Описание организации информационной базы; – Руководство по безопасной разработке программного обеспечения; – Описание программного обеспечения; – Макеты экранных форм компонента «Интерактивная карта». Структура документов должна соответствовать ГОСТ Р 59795-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов». Разработка Модуля СЦ должна включать в себя: – разработку программного обеспечения в части новых функций Модуля СЦ; – сборка исходного кода, развертывание и настройку доработанного программного обеспечения Модуля СЦ на вычислительных мощностях Заказчика (тестовый контур); – Комплект рабочей документации на Модуль СЦ; – разработку документа «Программа и методика предварительных испытаний»; – разработку документа «Программа и методика приемочных испытаний»; – разработку документа «Программа опытной эксплуатации». Структура документов должна соответствовать ГОСТ Р 59795-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов». В ходе выполнения работ формируется правоустанавливающая, отчетная, рабочая и техническая документация в соответствии с Контрактом и Календарным планом, приведенном в разделе 5. - - Значение характеристики не может изменяться участником закупки - 6.1. Сведения о гарантийном обслуживании Модуля СЦ Под гарантией понимается устранение Подрядчиком своими силами и за свой счет допущенных по его вине недостатков, выявленных после приемки выполненных Работ, как в работе самой Модуля СЦ, так и недостатков в отчетной документации. Если в период гарантийного срока обнаружатся недостатки, то Подрядчик обязан устранить их за свой счет, в сроки, установленные Заказчиком. Гарантийный срок в этом случае продлевается на период устранения недостатков. Срок гарантии: 1 год с даты приемки Заказчиком результатов исполнения Этапа № 9 контракта. Подрядчиком должны быть внесены соответствующие исправления в техническую и рабочую документацию (указанную в пунктах 5 и 6 настоящего ТЗ), связанные с устранением замечаний к работе Модуля СЦ или в случае выявления Заказчиком недостатков в такой документации в период гарантийного срока. Внесение изменений в документацию технического и рабочего проектирования осуществляется в соответствии с ГОСТ 2.503-2023 и ГОСТ Р 2.504-2021. - 7. ПОРЯДОК КОНТРОЛЯ И ПРИЕМКИ РЕЗУЛЬТАТОВ ВЫПОЛНЕНИЯ РАБОТ ПО РАЗВИТИЮ МОДУЛЯ СЦ - Испытания должны быть организованы и проведены в соответствии с ГОСТ Р 59792-2021 «Информационная технология. Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем». Должны быть проведены следующие виды испытаний: – предварительные испытания; – опытная эксплуатация; – приемочные испытания. Указанные виды испытаний проводятся в отношении не функциональных требований и функциональных возможностей, разрабатываемых в соответствии с настоящим ТЗ. Отдельные виды испытаний проводятся поэтапно в сроки, установленные Календарным планом. Предварительные испытания, опытная эксплуатация, приемочные испытания проводятся комиссией, создаваемой организационно-распорядительным документом Заказчика, который должен определять состав комиссии, порядок ее работы. Методы предварительных испытаний и порядок их проведения должны быть определены в документе «Программа и методика предварительных испытаний», который должен быть утвержден Заказчиком до начала предварительных испытаний. По результатам предварительных испытаний оформляется Протокол предварительных испытания и Акт о приемке в опытную эксплуатацию. Порядок проведения и методы испытаний во время опытной эксплуатации должны быть определены в документе «Программа опытной эксплуатации», который должен быть утвержден Заказчиком до начала опытной эксплуатации. Ход и результаты опытной эксплуатации отражаются в документе «Журнал опытной эксплуатации», и учитываются в ходе приемочных испытаний. По результатам опытной эксплуатации подписывается Акт о завершении опытной эксплуатации - - Значение характеристики не может изменяться участником закупки - До момента подключения внешних ИС, Подрядчиком могут быть использованы эмуляторы ИС для прохождения предварительных испытаний, опытной эксплуатации и приемочных испытаний. В рамках опытной эксплуатации должны быть проведены мероприятия по нагрузочному тестированию Модуля СЦ. Документ «Программа и методика приемочных испытаний» должен быть разработан с учетом недостатков, выявленных в ходе опытной эксплуатации, утвержден Заказчиком до начала приемочных испытаний, при этом проверки Модуля СЦ в части не устраненных недостатков, выявленных в процессе опытной эксплуатации, должны быть вынесены в отдельный раздел «Программы и методики приемочных испытаний». В процессе приемочных испытаний должно быть проверено устранение недостатков, полученных в ходе опытной эксплуатации. После завершения устранения всех замечаний, препятствующих приемке Системы в эксплуатацию, перечисленных в Протоколе приемочных испытаний, Подрядчик должен письменно уведомить Заказчика о том, что все замечания устранены, после чего приемочные испытания по решению Заказчика могут быть проведены повторно. Процедура приемочных испытаний проводится до подписания Протокола приемочных испытаний, не содержащего замечаний, препятствующих приемке Системы в эксплуатацию. Приемочные испытания Системы считаются завершенными успешно, если Протокол приемочных испытаний не содержит замечаний, препятствующих приемке Системы в эксплуатацию - 8. ТРЕБОВАНИЯ К СОСТАВУ И СОДЕРЖАНИЮ РАБОТ ПО ПОДГОТОВКЕ МОДУЛЯ СЦ К ВВОДУ В ЭКСПЛУАТАЦИЮ - По результатам проведения приемочных испытаний оформляется Протокол приемочных испытаний и Акт приемки в эксплуатацию. В случае, если взаимодействие с внешними системами не может быть проверено на средах постоянной эксплуатации взаимодействующих систем (по причине неготовности со стороны внешней системы или иным причинам), функции взаимодействия, разработанные в соответствии с требованиями ТЗ, должны быть проверены на тестовых данных с использованием программ-имитаторов взаимодействия. По результатам выполнения этапа приемочных испытаний должны быть подготовлены материалы для регистрации доработанной версии Модуля СЦ (объекта учета) в НФАП в соответствии с требованиями постановления Правительства Российской Федерации от 30 января 2013?г. №?62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин» (с изменениями и дополнениями) в части обязательности размещения результатов работ в национальном фонде алгоритмов и программ для электронных вычислительных машин. Сдача-приемка результатов выполнения Работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная, техническая документация, а также программное обеспечение предоставляется Заказчику в порядке, предусмотренном Контрактом и ТЗ до размещения Подрядчиком в Единой информационной системе в сфере закупок документа о приемке. Результаты проведения опытной эксплуатации, предварительных и приемочных испытаний должны быть зафиксированы в соответствующих протоколах и актах. Выявленные отклонения от настоящего ТЗ, оформляются как недостатки Модуля СЦ - - Значение характеристики не может изменяться участником закупки - Протоколы предварительных и приемочных испытаний должны содержать вывод о соответствии Модуля СЦ предъявляемым требованиям, а также сроки устранения замечаний и реализации рекомендаций, сформулированных комиссией в ходе предварительных и приемочных испытаний. Условием для передачи Модуля СЦ в промышленную эксплуатацию является устранение всех замечаний. Документация на Модуль СЦ и ее части (техническая и рабочая) должна содержать исчерпывающее описание принятых проектных решений в объеме, достаточном для ее дальнейшего развития и эксплуатации. Техническая и рабочая документация должна содержать описание разработанных результатов работ, в том числе программ для ЭВМ, прикладных программных интерфейсов, алгоритмов и протоколов информационного взаимодействия, технических требований, спецификаций и форматов обмена данными для взаимодействия с другими информационными системами, в объеме, достаточном для их установки, настройки, эксплуатации и развития в дальнейшем без привлечения Подрядчика. Исходные коды передаются в виде и составе, позволяющем провести: – сборку (компиляцию) Модуля СЦ в контролируемой Заказчиком среде; – установку полученной Модуля СЦ на специально подготовленную контролируемую Заказчиком инфраструктуру; – проверку функциональных возможностей Модуля СЦ; – оформление Модуля СЦ в качестве объекта национального фонда алгоритмов и программ для электронных вычислительных машин - 8.1. Требования, предъявляемые в соответствии с Приказом Минцифры России от 17.12.2020 № 715 «Об утверждении типовых условий контрактов на выполнение работ по созданию и (или) развитию (модернизации) государственных (муниципальных) и (или) иных информационных систем» Передача исходных кодов, разработанных в ходе выполнения работ, программ для электронных вычислительных машин (далее – программа для ЭВМ) должна сопровождаться передачей всех необходимых для сборки и запуска программы для ЭВМ библиотек зависимостей, программных сценариев (скриптов) для проведения установки (развертывания) программы для ЭВМ. Подрядчик в процессе сдачи-приемки работ по Контракту должен провести демонстрацию процесса и установки (развертывания) разработанных программ для ЭВМ. Документация на Модуль СЦ должна содержать описание принятых проектных решений в объеме, достаточном для ее дальнейшего развития и эксплуатации - 9. ТРЕБОВАНИЯ К ДОКУМЕНТИРОВАНИЮ - 9.1. Общие требования Документация на Модуль СЦ должна быть разработана в составе, указанном в разделах 5-8 данного ТЗ, и должна удовлетворять требованиям комплекса стандартов и руководящих документов на автоматизированные системы: – ГОСТ Р 2.105-2019 в части оформления текстовых документов; – ГОСТ 34.201-2020 в части наименования и обозначения документов. Документация на Модуль СЦ должны оформляться на листах формата А4. Допускается для размещения рисунков и таблиц использование листов формата А3 с подшивкой по короткой стороне листа. Документы объемом более 25 (двадцати пяти) листов должны содержать информационную часть, состоящую из аннотации и содержания. Исходные коды должны быть представлены в 1 (одном) экземпляре на электронном носителе, отчетные материалы должны быть представлены в 2 (двух) экземплярах на бумажном носителе (по одному экземпляру для Заказчика и Подрядчика) и в 1 (одном) экземпляре на электронном носителе в формате документов DOCX и PDF. При разработке документов на Модуль СЦ допускается отклонение от требований комплекса стандартов, описанных выше. Документам на Модуль СЦ должны в обязательном порядке присваиваться уникальные децимальные номера в соответствии с порядком, установленном в ГОСТ 34.201-2020. Документ «Программа и методика предварительных испытаний» должен включать приложения с формой протокола предварительных испытаний и формой акта приемки в опытную эксплуатацию. Документ «Программа опытной эксплуатации» должен включать приложение с формой журнала опытной эксплуатации. Документ «Программа и методика приемочных испытаний» должен включать приложения с формой протокола приемочных испытаний и формой акта приемки в эксплуатацию - - Значение характеристики не может изменяться участником закупки - 10. ИСТОЧНИКИ РАЗРАБОТКИ - 10.1. Список литературы Специальная литература для разработки ТЗ не использовалась. 10.2. Нормативно-методические документы Список используемых нормативно-методических документов представлен в разделе 1.6 технического задания. ? Приложение А Эскизы визуального оформления компонента «Интерактивная карта» - - Значение характеристики не может изменяться участником закупки - Приложение Б Параметры оказания услуг - Б.1. Базовые параметры оказания Услуг Базовые параметры оказания Услуг приведены ниже: – режимы оказания Услуг (таблица Б.1.1); – сроки предоставления отчетности (таблица Б.1.2). Таблица Б.1.1 - Режимы оказания Услуг № п/п Параметр Значение - - Значение характеристики не может изменяться участником закупки - 1 Режим работы Системы Круглосуточно (24х7) 2 Режим доступности информационно-консультационной поддержки пользователей Системы 2.1 Прием и регистрация обращений (заявок) в СРО Регистрация обращений (заявок) производится круглосуточно в режиме 24х7, без праздников и выходных дней. Обработка заявок первой линией поддержки осуществляется в рабочие дни с 9 до 18 часов 2.2 Консультирование сотрудников Заказчика и пользователей Системы в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 3 Режим доступности по решению инцидентов, связанных с работой ППО: 3.1 - приоритет «Критический» Круглосуточно (24х7) 3.2 - приоритет «Высокий» Круглосуточно (24х7) 3.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 3.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4 Режим доступности услуг по адаптации, конфигурации и коррекционному сопровождению Системы 4.1 - приоритет «Критический» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.2 - приоритет «Высокий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 5 Режим доступности по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности 5.1 - приоритет «Критический» Круглосуточно (24х7) 5.2 - приоритет «Высокий» Круглосуточно (24х7) 5.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 5.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) - Таблица Б.1.2. Сроки предоставления отчетности, с момента получения запроса № п/п Параметр Значение 1 Предоставление отчета об оказанных услугах за произвольный период 10 рабочих дней 2 Предоставление подробной информации по инциденту с приоритетом «Критический» 16 рабочих часов 3 Предоставление актуализированной документации 10 рабочих дней - Б.2. Приоритеты и регламентные сроки решения обращений (заявок) В зависимости от уровня сбоя в работе Системы обращению (заявке) присваивается один из следующих приоритетов, а также в зависимости от приоритета обращения (заявки) устанавливаются следующие контрольные сроки решения в соответствии с таблицей ниже (Таблица Б.2.1). Таблица Б.2.1 – Приоритеты и регламентные сроки решения обращений (заявок) № п/п Приоритет Максимальное время реагирования Время решения (срок выполнения) Описание приоритета По информационно-консультационной поддержке сотрудников Заказчика и пользователей Системы 1 - не более 1 часа не более 10 часов - По решению инцидентов, связанных с работой ППО: 1 Критический не более 30 минут не более 4 часов - полная недоступность ППО; - недоступность ключевых функций - ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО; - невозможность информационного обмена с ППО для ИС более 4 часов 2 Высокий не более 1 часа не более 8 часов - ошибки/сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; - снижение быстродействия СПО (время отклика ППО на операции превышает 30 секунд); - недоступность управления правами и ролями пользователей 3 Средний не более 4 часов не более 24 часов - невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым -недоступность функции формирования отчетов 4 Низкий не более 8 часов не более 40 часов - отклонение в работе ППО, не влияющее на корректную работу функций; - другие сбои и ошибки, затрагивающие основные функции ППО - По адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) 1 Критический не более 40 минут не более 8 часов - изменения, необходимые при проведении аварийно-восстановительных работ для возобновления работоспособности Системы; - изменения, связанные с критичными ошибками, блокирующими возможность оказания государственных услуг и/или чтение и внесение данных в Систему 2 Высокий не более 1 часа не более 40 часов - изменения, относящиеся к обеспечению работоспособности основной функциональности Системы, устраняют выявленные дефекты в работе Системы, оказывающие существенное влияние на работу пользователей в Системе; - изменения, затрагивающие три и более подсистемы/модуля Системы для адаптации 3 Средний не более 4 часов не более 72 часов - изменения, связанные с развитием/улучшением/оптимизацией Системы и выводом новой функциональности в штатном режиме для одного-двух модулей/подсистем; - изменения, связанные с развитием интеграционных механизмов Системы, например обновление существующих и/или реализация новых видов сведений СМЭВ, обновление существующих и/или реализация новых API, адаптация и/или изменение механизмов импорта и экспорта данных Системы и т.д. 4 Низкий не более 8 часов не более 160 часов - изменения, связанные с ошибками/корректировкой/изменением в отображении информации в пользовательском графическом интерфейсе Системы (графика, текст, органы управления, элементы интерфейса) - По устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности 1 Критический не более 30 минут не более 24 часов - критические уязвимости, влияющие на возможную полную недоступность ППО, ключевых функций Системы, ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО без возможности восстановления работоспособности Системы. - Критический уровень CVSS > 8.0 2 Высокий не более 1 часа не более 84 часов - критические уязвимости, влияющие на ошибки и сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО. - Высокий уровень CVSS 5.0 - 8.0 3 Средний не более 4 часов не более 120 часов - уязвимости, влияющие на невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым - Средний уровень CVSS 2.0 - 4.9 4 Низкий не более 8 часов не более 160 часов - уязвимости, влияющие на отклонение в работе ППО, не влияющее на корректную работу функций; - другие сбои и ошибки, затрагивающие основные функции ППО - Низкий уровень CVSS < 2.0 - Взаимодействие Заказчика и Подрядчика в части регистрации и контроля времени реагирования и решения обращения (заявки) осуществляется через СРО. Заказчик предоставляет Подрядчику доступ к СРО после заключения Контракта. Поступившие от разных пользователей заявки по поводу однотипных инцидентов или имеющие общую причину должны объединяться в одну заявку. Срок выполнения включает время диагностики инцидента, в ходе которого определяется причина инцидента (проблемы) и способ его устранения. Подрядчик должен обеспечить функционирование Модуля СЦ в соответствии с требованиями и параметрами, указанными в настоящем ТЗ и Регламенте оказании услуг. Основные параметры быстродействия типовых операций в Модуле СЦ указаны в таблице ниже (таблица Б.2.2). Таблица Б.2.2 - Параметры быстродействия Модуля СЦ № п/п Наименование параметра Значение (секунд) 1 Среднее время получения сообщения из очереди сообщений 10 2 Среднее время получения ответа от Системы 5 3 Среднее время открытия карточки реестра 5 - Приложение В Регламент оказания услуг - Термины и сокращения В настоящем регламенте используются следующие термины и сокращения на русском и английском языках: Термины/сокращения Полное наименование/описание БЗ (База знаний) База данных Системы регистрации обращений (заявок), созданная для сбора, хранения и поиска способов решения известных проблем в рамках Системы Жизненный цикл обращения (заявки) Совокупность статусов, по которым проходит обращение (заявка), и правила перехода обращения (заявки) из одного статуса в другой Заказчик ФГБУ «СИЦ Минтранса России» – Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» ЗНИ Запрос на изменение – тип заявки, предполагающий внесение изменений в прикладное программное обеспечение Системы ЗНО Запрос на обслуживание – тип заявки, предполагающий работы по предоставлению консультации, предоставление доступа к Системе или стандартизированные типовые изменения конфигураций Системы Инцидент Тип заявки, классифицируемый как нештатное событие в работе компонентов функциональных задач Системы, которое привело или может привести к нарушению или снижению качества функционирования Системы ИС Информационная система Исполнитель Организация, которая определяется по результатам конкурсных процедур Классификация Анализ и заполнение классификационных полей справочными значениями, определяющими последовательность действий и этапов жизненного цикла заявки, а также порядок рассмотрения заявок Консультация Разъяснения по алгоритму работы, требуемых настроек прикладного программного обеспечения и технологии обработки данных при работе с Системой, предоставление информации Маршрутизация Определение процесса движения обращения (заявки) в Системе управления заявками между уровнями технической поддержки и организационными структурами на уровнях поддержки путем назначения обращения (заявки) в соответствии с его классификацией и выставленным приоритетом - - Значение характеристики не может изменяться участником закупки - Обращение (заявка) Устное или письменное обращение пользователя АСУ ТК с вопросом, касающимся работоспособности АСУ ТК, по одному из определённых каналов связи: электронная почта, Система регистрации обращений (заявок) Пользователь Инициатор обращения (заявки) или пользователь Системы ППО Прикладное программное обеспечение Предмет обращения Справочник, классифицирующий типовые запросы в Системе регистрации обращений (заявок), характерные для Системы, выбранное значение определяет маршрутизацию обращения (заявки) (группу ответственных сотрудников) Приоритизация Значение, определяющее время, очередность решения обращений (заявок), ресурсы, привлекаемые для решения обращений (заявок), . Приоритет устанавливается в соответствии с масштабом выявленной проблемы, которая привела или может привести к нарушению или снижению качества функционирования Системы Релиз Выпуск версии прикладного программного обеспечения Системы, от разработки до тестирования и планового обновления Системы на продуктивной среде для установки изменений, связанных с развитием/улучшением/оптимизацией Системы Система, АСУ ТК, Информационно-аналитическая система регулирования на транспорте Информационно-аналитическая система, предназначенная для автоматизации и информационно-аналитического обеспечения процессов управления развитием транспортного комплекса Российской Федерации, обеспечения публичности деятельности органов государственного управления транспортным комплексом, а также обеспечения процессов оказания государственных услуг в электронном виде в сфере транспорта СМЭВ Система межведомственного электронного взаимодействия СПО Системное программное обеспечение СРО Система регистрации обращений (заявок) Статус обращения (заявки) Текущее состояние обращения (заявки) в жизненном цикле процесса оказания технической поддержки Системы СУБД Система управления базами данных - Уровень технической поддержки Организационно-структурная часть технической поддержки, имеющая определённые организационно-нормативными документами зоны ответственности, обязанности, а также временные нормативы, в течение которых эти обязательства должны выполняться либо эскалироваться на следующий уровень технической поддержки Услуги Услуги по технической поддержке Информационно-аналитической системы регулирования на транспорте АСУ ТК ФИО Фамилия, имя, отчество Эскалация Процедура повышения внимания к обращению (заявке) путем повышения его приоритета и/или передачи на следующий уровень технической поддержки, а также привлечение ролей, которые могут принимать решения без передачи на следующий уровень технической поддержки API Англ. Application Programming Interface — программный интерфейс приложения, интерфейс прикладного программирования — описание способов (набор классов, процедур, функций, структур или констант), которыми одна компьютерная программа может взаимодействовать с другой программой - CVSS Англ. Common Vulnerability Scoring System - открытый стандарт, используемый для расчета количественных оценок уязвимости в безопасности компьютерной системы, обычно с целью понять приоритет ее исправления. В современном инструментарии информационной безопасности используется версия 3.0 и выше с дополнительными метриками к базовым оценкам ID Англ. Identifier – идентификатор, уникальный признак объекта, позволяющий отличать его от других объектов, то есть, идентифицировать SLA Англ. Service Level Agreement - утвержденные условия по обработке обращения (заявки) с установленными метриками времени, которые определяют пороговые значения для эскалации в зависимости от статуса обращения (заявки) (например, время реакции – время от регистрации до осуществления первичной обработки, время решения – время от регистрации обращения (заявки) до его решения и т.д.) SQL Англ. Structured Query Language — «язык структурированных запросов», — декларативный язык программирования, применяемый для создания, модификации и управления данными в реляционной базе данных, управляемой соответствующей СУБД - 1 Общие сведения 1.1 Полное наименование Услуг Оказание услуг по технической поддержке Модуля СЦ АСУ ТК в 2026 году. 1.2 Предмет Регламента оказания услуг Требования Технического задания - 2 Общие положения 2.1 Цель и задачи оказания услуг Целью технической поддержки Системы является обеспечение ее стабильного и безопасного функционирования и эксплуатации, предупреждение, выявление и устранение сбоев в работе Системы и минимизация их неблагоприятного влияния. Для достижения поставленной цели требуется решение следующих задач: 1. Обеспечение информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы. 2. Поддержание параметров функционирования ППО Системы, удовлетворяющих требованиям производственных процессов, включая их непрерывность. 3. Обеспечение бесперебойного функционирования ППО и своевременное устранение сбоев и аварийных ситуаций в Системе. 4. Своевременное устранение уязвимостей при выявлении таковых, в соответствии с требованиями к обеспечению информационной безопасности. 5. Адаптация, конфигурирование, коррекция программного обеспечения в соответствии с изменениями нормативно-правовой базы и запросами уполномоченных сотрудников органов государственной власти, включая выполнение процедур тестирования и участие в обновлениях ППО на стендах Заказчика. 6. Обеспечение сохранения работоспособности ППО в изменяемой среде эксплуатации. 7. Ведение документации по настоящему контракту и инициирование актуализации документации на Систему по результатам обработки запросов Заказчика и внесения соответствующих изменений в ППО - 2.2 Общее описание процесса оказания сопровождения (технической поддержки) Системы Процесс оказания технической поддержки Системы включает: 1. Поступление обращений (заявок) от пользователей и их регистрацию. 2. Сопровождение обращений (заявок) в соответствии с их классификацией и приоритизацией, в том числе, с их последующей эскалацией. 3. Определение ролей и регламент их взаимодействия при осуществлении деятельности по процессу. 4. Решение обращений (заявок) в установленные настоящим Регламентом сроки. 5. Взаимодействие между 1-м, 2-м и 3-м уровнями технической поддержки, в том числе, с формированием заданий для сопровождения Системы. 6. Контроль качества выполняемых Исполнителем работ, состоящий из проверки сценария, приводящего к ошибке, зафиксированной в Инциденте, и/или к ошибке воспроизведения, а также тестирование внесенных изменений в рамках ЗНИ. 7. Обеспечение мониторинга и проведение анализа процесса обработки поступающих в техническую поддержку обращений (заявок). Техническая поддержка реализуется путем проведения ответственными сотрудниками соответствующей информационно-консультационной деятельности в соответствии с определенными ролями, а также выполнения Исполнителем конкретных действий по своевременному выявлению причин сбоев и аварийных ситуаций и их устранению, а также по адаптации, конфигурированию, корректировке Системы, включая выполнение процедур тестирования и участия в обновлениях Системы. Все роли подразделяются на уровни поддержки, взаимодействующие между собой в соответствии с блок-схемой процесса технической поддержки. Общая схема процесса рассмотрения обращений (заявок) в соответствии с видами технической поддержки представлена на рисунке 1. . Рисунок 1 - Общая схема процесса рассмотрения обращений (заявок) в соответствии с видами технической поддержки - 2.3 Каналы связи Должна быть предусмотрена омниканальность в части приема обращений (заявок). Получение обращений (заявок) технической поддержкой происходит по следующим каналам связи: – СРО; – электронная почта; – телефонная линия. Исполнитель обеспечивает прием обращений (заявок) от Заказчика и предоставляет информацию в рамках оказания услуг по техническому сопровождению Системы, руководствуясь матрицей взаимодействия, приведенной в Приложении 1 к настоящему Регламенту - 3 Порядок оказания Услуг 3.1 Типы обращений (заявок) Обращения и заявки Заказчика классифицируются в соответствии с приоритетами и регламентными сроками, указанными в Приложении 2 к настоящему Регламенту. Регистрация обращений и заявок предусматривает создание новой записи в СРО с присвоением поступившему обращению или заявке (новой записи) уникального идентификатора. Запись в СРО должна содержать вопрос или проблему, которую требуется решить или оказать консультацию. Если обращение или заявка автоматически зарегистрированы в СРО при отправке представителем Заказчика, Исполнитель проверяет корректность указанного типа обращения (заявки) и может обратиться к Заказчику с просьбой корректировки, предоставив обоснования в соответствии с настоящей классификацией (Таблица 1) - Таблица 1 - Типы обращений (заявок) Тип обращения (заявки) Описание Запрос на обслуживание Подготовка SQL запроса к СУБД для решения прикладной задачи и д р. – запрос на любое действие, не являющееся запросом информации и несовершенный на основе происшествия, прямо или косвенно влияющего на работу Системы Консультация (входит в тип обращения (заявки) «Запрос на обслуживание») «Где взять / куда обратиться...?», «Как сделать / выполнить…», «Как это работает…?» - запрос, имеющий своей целью получение информационной поддержки Инцидент Разбор ошибок/сбоев и подготовка материалов (корректировочных релизов, инструкций) для Заказчика для устранения ошибок/сбоев, которые приводят к частичному и полному нарушению работоспособности всех или отдельных функций ППО. Подготовка изменения и материалов, необходимых для проведения аварийно-восстановительных работ для возобновления работоспособности Системы. ЗНИ Подготовка изменений, связанных с изменением, улучшением/оптимизацией Системы и выводом новой модифицированной функциональности в штатном режиме. Подготовка изменений, связанных с модификацией существующих и/или реализация новых интеграционных механизмов для получения/обработки данных внешних систем. Подготовка изменений графического интерфейса по требованиям Заказчика - 3.2 Участники технической поддержки, осуществляющие сопровождение обращений (заявок) Техническая поддержка Системы должна быть организована на трех уровнях: 1. Первый и второй уровни технической поддержки организуется Заказчиком. 2. Третий уровень технической поддержки организуется Исполнителем. Зона ответственности каждого уровня технической поддержки указана в Таблице 2. Таблица 2 - Зона ответственности каждого уровня технической поддержки Участники технической поддержки Описание - Первый уровень технической поддержки (далее – 1-й уровень) Группа ответственных сотрудников 1-го уровня Заказчика, осуществляющая прием и первичную обработку обращений (заявок) (описание предмета обращения, первичная классификация и приоритизация, определение назначения, маршрутизация обращений (заявок) по назначению), руководствуется в своей работе настоящим Регламентом и БЗ, наполняемой 2-м уровнем поддержки, самостоятельно решает часть обращений (заявок), связанных с недостаточной квалификацией пользователей или настройками в рамках своей компетенции. В случае невозможности решения обращений (заявок) на 1-ом уровне ответственный сотрудник передает ее на 2-й уровень - Второй уровень технической поддержки (далее – 2-й уровень) Группа ответственных сотрудников 2-го уровня Заказчика по установленным компетенциям (информационная безопасность, сопровождение и эксплуатация информационно-аналитических систем, развитие информационно-аналитических систем, техническая поддержка информационно-аналитических систем) отвечает за поддержание работоспособности Системы, обработку обращений (заявок) и их решение в регламентные сроки в соответствии с установленными приоритетами. Осуществляет информационно-консультационную поддержку пользователей Системы в рамках своей компетенции. Оказывает экспертную помощь ответственным сотрудникам 1-го уровня в части формирования БЗ, содержащей ответы на часто задаваемые вопросы пользователей, с целью передачи знаний, навыков и инструментария на 1-й уровень для ускорения решения обращений (заявок). В случае невозможности решения обращения (заявки) на 2-ом уровне ответственный сотрудник передает его на 3-й уровень. При выявлении необходимости изменений в ППО Системы инициирует формирование обращения (заявки) и направляет его на группу ответственных сотрудников 3-го уровня по соответствующему классификатору (ЗНО, ЗНИ, и т.д.) - Третий уровень технической поддержки (далее – 3-й уровень) Группа ответственных сотрудников Исполнителя, отвечающая за устранение сбоев и аварий, проведение информационно-консультационной поддержки пользователей Системы, проведение адаптации и конфигурирования Системы в объемах действующих контрактов на оказание технической поддержки - 3.3 Перечень и описание статусов обращений (заявок) В Таблице 3 приведен перечень статусов обращений (заявок), действующий в СРО, и их описание. Таблица 3 - Перечень статусов обращений (заявок) и их описание Статус Описание Зарегистрирован Обращение (заявка) принято и зарегистрировано Направлен в группу Присваивается при назначении ответственными сотрудниками 1-го уровня группе ответственных сотрудников 2-го уровня по тематике обращения (заявки) после заполнения всей необходимой информации и полей обращения (заявки), а также при его передаче между группами 2-го уровня Передан в группу Присваивается при передаче обращения (заявки) ответственными сотрудниками 2-го уровня на группу ответственных сотрудников 3-го уровня Назначен Присваивается при назначении обращения (заявки) на ответственного сотрудника для его решения в рамках компетенции В работе Присваивается при приеме обращения (заявки) в работу ответственным сотрудником для его решения Решен Присваивается ответственным сотрудником, выполнившим работы по обращению (заявке) Закрыт Присваивается автоматически при решении запроса по обращению (заявке), а также отсутствии дополнительных запросов пользователя в соответствии с действующим SLA, или при подтверждении решения обращения (заявки) со стороны пользователя Запрос доп. информации Присваивается при необходимости запроса дополнительной информации и/или уточнения предмета обращения по обращению (заявке) у пользователя Ответ предоставлен Присваивается после ответа пользователем на запрос дополнительной информации Отклонен Присваивается, если обращение (заявка) не актуальна (по информации от пользователя), отсутствует техническая возможность решения обращения (заявки), предмет обращения не входит в компетенции технической поддержки, или существует влияние доработки на другие компоненты, что нарушает общий порядок работы Системы - Согласование Присваивается при необходимости согласования направления обращения (заявки) ответственным сотрудником Заказчика на 3-й уровень Анализ Присваивается при проведении анализа на предмет возможности внесения изменений, связанных с развитием/улучшением/оптимизацией Системы и выводом новой функциональности и оценке ресурсоемкости Тестирование Присваивается Исполнителем при завершении разработки и проведенном предварительном тестировании для последующего осуществления приемочного тестирования Специалистом 2-го уровня Релиз Присваивается ответственным сотрудником Заказчика при принятии решения о возможности вывода доработки в продуктивную среду Утверждение заказчиком Присваивается при согласовании группой профильных специалистов на 2-м уровне поддержки с пользователем технического задания для внесения изменений, связанных с развитием/улучшением/оптимизацией Системы и выводом новой функциональности Доработка Присваивается в случае несогласования Заказчиком работ, проведенных Исполнителем в рамках контрактных обязательств, по внесению изменений, связанных с развитием/улучшением/оптимизацией Системы и выводом новой функциональности в штатном режиме, и необходимости последующего направления Исполнителю для ее доработки Отложен Присваивается в случае невозможности выполнения запроса, изложенного в обращении (заявке), в связи с необходимостью запроса дополнительной информации у третьих сторон - 3.4 Порядок регистрации и сопровождения Заявок Порядок регистрации и сопровождения обращений (заявок) в рамках оказываемых услуг по технической поддержке Системы зависит от типа обращения (заявки): 1. Услуга по решению инцидентов, связанных с работой ППО – тип обращения (заявки) «Инцидент». 2. Услуга по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности – тип обращения (заявки) «Инцидент». 3. Услуга информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы – тип обращения (заявки) «Запрос на обслуживание» (в том числе, консультационный запрос). 4. Услуга адаптационного, конфигурационного и коррекционного сопровождения Системы (в рамках действующих программных модулей и функциональностей) – тип обращения (заявки) «Запрос на изменение». В случае недоступности СРО взаимодействие и информирование Исполнителем о ходе оказания услуги по обращению (заявке), изменению статусов обращений (заявок) осуществляется по согласованию с Заказчиком в соответствии с матрицей взаимодействия, представленной в Приложении 1 к настоящему Регламенту. - 3.4.1 Инцидент На рисунке 2 представлена функциональная схема регистрации и сопровождения обращений (заявок) типа «Инцидент». Рисунок 2 - Функциональная схема регистрации и сопровождения обращений (заявок) типа «Инцидент» 3.4.2 Запрос на обслуживание На рисунке 3 представлена функциональная схема регистрации и сопровождения обращения (заявки) типа «ЗНО». Рисунок 3 - Функциональная схема регистрации и сопровождения обращения (заявки) типа «ЗНО» 3.4.3 Запрос на изменение На рисунке 4 представлена функциональная схема регистрации и сопровождения обращений (заявок) типа «ЗНИ». Рисунок 4 - Функциональная схема регистрации и сопровождения обращений (заявок) типа «ЗНИ» - 3.5 Порядок классификации и приоритизации обращений (заявок) Классификация является начальной стадией процесса оказания технической поддержки, необходимой для идентификации обращения (заявки) и определения соответствующих действий для его обработки. Для проведения первичной классификации необходимо получить от пользователя и зафиксировать в описании обращения (заявки) подробные сведения о сути запроса, в том числе, для Инцидентов зафиксировать сценарий воспроизведения обнаруженной ошибки. Для проведения вторичной классификации необходимо провести анализ и диагностику для определения корневой причины и затронутой Инцидентом функциональной области (инфраструктура, сеть, ППО). В процессе классификации осуществляется первичная диагностика и оценка проблемы, описанной пользователем Системы в обращении (заявке), в части функционирования и/или удобства использования Системы. Корректная классификация позволяет увеличить скорость обработки обращения (заявки) и решения описанной в обращении (заявке) проблемы при минимальном привлечении ресурсов, в частности, за счет использования известных решений для типовых обращений (заявок), которые должны описываться в БЗ СРО. Классификация позволяет произвести первоначальное назначение обращения (заявки) на ответственного сотрудника и выставить приоритет с учетом приоритизации. Приоритизация применяется для определения критичности описанной в обращении (заявке) проблемы для функционирования ППО Системы. Приоритет рассмотрения обращения (заявки) определяется в процессе ее классификации на основании ряда параметров, вводимых при заполнении обращения (заявки). Приоритизация используется для того, чтобы при одновременном наличии нескольких обращений (заявок) в первую очередь рассматривалась обращения (заявки) с наивысшим приоритетом и не позднее установленных для данного приоритета сроков - Изменение приоритета уже зарегистрированного обращения (заявки) используется в случае появления новых обстоятельств, которые ведут к изменению влияния и/или срочности существующего обращения (заявки). При регистрации обращения (заявки) необходимо провести его приоритизацию. В процессе управления обращениями (заявками) каждому обращению (заявке) присваивается приоритет, принимающий одно из значений: Низкий, Средний, Высокий или Критический. В соответствии с приоритетом определяется время, очередность устранения, , ресурсы, привлекаемые для работ по обращению (заявке), а также может определяться порядок/процедура действий при работе с обращением (заявкой). Заказчиком в зависимости от уровня сбоя в работе Системы обращению (заявке) присваивается приоритет с указанием максимального времени реакции и решения в соответствии с требованиями, указанными в Приложении 2 к настоящему Регламенту - 4 Формы обращений (заявок) на оказание услуг по технической поддержке Системы, заполняемые в СРО 4.1. Форма обращения (заявки) на оказание услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы При подаче обращения (заявки) типа «ЗНО» в СРО указывается (Таблица 5): Таблица 5 – Описание атрибутов формы обращения (заявки) на оказание услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 5) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 5) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 5) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 5) Категория обращения: информационно-консультационная поддержка Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 5) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 5) Текст запроса на оказание услуги по информационно-консультационной поддержке сотрудников Заказчика Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 5) - На рисунке 5 приведена форма обращения (заявки) типа «ЗНО» в СРО. Рисунок 5 - Форма обращения (заявки) типа «ЗНО» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы, заполненную в свободной форме. - 4.2. Форма обращения (заявки) на оказание услуги по решению инцидентов, связанных с работой ППО При подаче обращения (заявки) типа «Инцидент» в СРО указывается (Таблица 6): Таблица 6 – Описание атрибутов формы обращения (заявки) на оказание услуги по решению инцидентов, связанных с работой ППО Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 6) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 6) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 6,) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 6) Категория обращения (заявки): инцидент Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 6) Приоритет изменения Время - одно из значений: Низкий, Средний, Высокий или Критический. Определяет, очередность решения обращения (заявки), ресурсы, привлекаемые для решения обращения (заявки), порядок/процедура действий при решении обращения (заявки) – поле СРО «Приоритет» (см. рисунок 6,) - Тип изменения Справочник, классифицирующий типовые запросы характерные для Системы – поле СРО «Предмет обращения» (см. рисунок 6) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 6) Полное описание инцидента, включая скриншоты и описание шагов, приведших к неисправности Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 6) Однократность/неоднократность Круг пользователей или компьютеров, затронутых данным инцидентом Действия, предпринятые для самостоятельного решения инцидента (при наличии) Версии используемого программного обеспечения на клиентской рабочей станции, где воспроизводится ошибка (операционная система, прикладное программное обеспечение) Дополнительная информация - На рисунке 6 приведена форма обращения (заявки) типа «Инцидент» в СРО. Рисунок 6 - Форма обращения (заявки) типа «Инцидент» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуги по решению инцидентов, связанных с работой ППО, заполненную в свободной форме - 4.3. Форма обращения (заявки) на оказание услуг по адаптационному конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) При подаче обращения (заявки) типа «ЗНИ» в СРО указывается (Таблица 7): Таблица 7 – Описание атрибутов формы обращения (заявки) на оказание услуг по адаптационному, конфигурационному и коррекционному сопровождению Системы Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 10) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 9) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 10) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 10) Категория обращения (заявки): запрос на изменение Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 7) Приоритет изменения Время, очередность решения обращения (заявки), ресурсы, привлекаемые для решения обращения (заявки), порядок/процедура действий при решении обращения (заявки) – поле СРО «Приоритет» (см. рисунок 7) Тип изменения Справочник, классифицирующий типовые запросы характерные для Системы – поле СРО «Предмет обращения» (см. рисунок 7) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 7) Текст запроса на оказание услуги по адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 7) - На рисунке 7 приведена форма обращения (заявки) типа «ЗНИ» в СРО. Рисунок 7 - Форма обращения (заявки) типа «ЗНИ» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуг по адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей), заполненную в свободной форме - 4.4. Форма обращения (заявки) на оказание услуги по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности При подаче обращения (заявки) типа «Инцидент» в СРО указывается (Таблица 8): Таблица 8 – Описание атрибутов формы обращения (заявки) на оказание услуг по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности - Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 8) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 8) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 8) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 8) Категория обращения (заявки): инцидент Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 8) Приоритет Время, очередность решения обращения (заявки), ресурсы, привлекаемые для решения обращения (заявки), порядок/процедура действий при решении обращения (заявки) – поле СРО «Приоритет» (см. рисунок 8) Тип изменения Справочник, классифицирующий типовые запросы характерные для Системы – поле СРО «Предмет обращения» (см. рисунок 8) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 8) Текст запроса на оказание услуги по обновлению или удалению уязвимых компонентов (библиотек) ППО в соответствии с требованиями к обеспечению информационной безопасности Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 8) - На рисунке 8 приведена форма обращения (заявки) типа «Инцидент» в СРО. Рисунок 8 - Форма обращения (заявки) типа «Инцидент» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуги по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности, заполненную в свободной форме - Приложение 1 к Регламенту Матрица ответственных за взаимодействия в рамках выполнения работ по техническому сопровождению Системы Таблица 1 – Ответственные за взаимодействия в рамках выполнения работ по техническому сопровождению Системы со стороны Исполнителя ФИО Должность Адрес электронной почты Телефон — — — Общий контакт - Приложение 2 к Регламенту Приоритеты и регламентные сроки решения обращений (заявок) Приоритеты и регламентные сроки решения обращений (заявок) приведены в таблице 1. Таблица 1 – Приоритеты и регламентные сроки решения обращений (заявок) № п/п Приоритет Максимальное время реагирования Время решения (срок выполнения) Описание приоритета - По информационно-консультационной поддержке сотрудников Заказчика и пользователей Системы 1 – не более 1 часа не более 10 часов – - По решению инцидентов, связанных с работой ППО 1 Критический не более 30 минут не более 4 часов – полная недоступность ППО; – недоступность ключевых функций; – ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО; – невозможность информационного обмена с ППО для ИС более 4 часов 2 Высокий не более 1 часа не более 8 часов – ошибки/сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; – снижение быстродействия СПО (время отклика ППО на операции превышает 30 секунд); – невозможность управления правами и ролями пользователей 3 Средний не более 4 часов не более 24 часов – невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым недоступность функции формирования отчетов 4 Низкий не более 8 часов не более 40 часов – отклонение в работе ППО, не влияющее на корректную работу функций; – другие сбои и ошибки, затрагивающие основные функции ППО - По адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) 1 Критический не более 40 минут не более 8 часов – изменения необходимые при проведении аварийно-восстановительных работ для возобновления работоспособности Системы; – изменения, связанные с критичными ошибками, блокирующими возможность оказания государственных услуг и/или чтение и внесение данных в Систему 2 Высокий не более 1 часа не более 40 часов – изменения относящиеся к обеспечению работоспособности основной функциональности Системы, устраняют выявленные дефекты в работе Системы, оказывающие существенное влияние на процесс оказания государственных услуг и работу пользователей в Системе; – изменения, затрагивающие три и более подсистемы/модуля Системы для адаптации 3 Средний не более 4 часов не более 72 часов – изменения, связанные с развитием/улучшением/оптимизацией Системы и выводом новой функциональности в штатном режиме для одного-двух модулей/подсистем; – изменения, связанные с развитием интеграционных механизмов Системы, например, обновление существующих и/или реализация новых видов сведений СМЭВ, обновление существующих и/или реализация новых API, адаптация и/или изменение механизмов импорта и экспорта данных Системы и т.д. 4 Низкий не более 8 часов не более 160 часов – изменения, связанные с ошибками/ корректировкой/изменение в отображении информации в пользовательском графическом интерфейсе Системы (графика, текст, органы управления, элементы интерфейса) - По устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности 1 Критический не более 30 минут не более 24 часов – критические уязвимости, влияющие на возможную полную недоступность ППО, ключевых функций Системы, ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО без возможности восстановления работоспособности Системы; – Критический уровень CVSS > 8.0 2 Высокий не более 1 часа не более 84 часов – критические уязвимости, влияющие на ошибки и сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; – Высокий уровень CVSS 5.0 - 8.0 3 Средний не более 4 часов не более 120 часов – уязвимости, влияющие на невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым; – Средний уровень CVSS 2.0 - 4.9 4 Низкий не более 8 часов не более 160 часов – уязвимости, влияющие на отклонение в работе ППО, не влияющее на корректную работу функций; – другие сбои и ошибки, затрагивающие основные функции ППО; – Низкий уровень CVSS < 2.0 - Приложение Г Форма Отчета об оказанных услугах Отчет об оказанных услугах за этап «наименование этапа» в период с «__» _________ по «__» _________. № п/п Наименование услуги Общее количество Номер ОРС Краткое Описание Время реагирования по ТЗ Время реагирования фактическое Время решения по ТЗ Время решения фактическое Результат соблюдения времени реагирования Результат соблюдения времени решения Примечание 1 Услуги по информационно-консультационной поддержке работников Заказчика 2 546782 Консультация по работе Модуля СЦ 1 2 10 часов 11 часов Нет Нет 567123 Консультация по схеме БД 1 1 10 часов 1 час Да Да 2 … … Заказчик Подрядчик /Должность/ /Должность/ ____________________ /Ф.И.О/ ___________________ /Ф.И.О/ М.П. М.П. «_____»_______________________202_г. «_____»_______________________202_г - Приложение 1 к Отчету об оказанных услугах Журнал обращений (заявок) на оказание услуги по информационно-консультационной поддержке пользователей Системы (шаблон) Наименование Исполнителя в этапе «наименование этапа» в период с ________________ по _______________ оказал(о) Услугу по поддержке пользователей Системы в объеме, указанном в Таблице 1 Таблица 1 - Журнал обращений (заявок) пользователей Системы № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. ИТОГО зарегистрировано: Всего обращений (заявок): ________ ИТОГО решено: Всего обращений (заявок): ________ - Приложение 2 к Отчету об оказанных услугах Журнал обращений (заявок) по решению инцидентов, связанных с работой ППО (шаблон) Наименование Исполнителя в этапе «наименование этапа» в период с ________________ по _______________ оказал(о) Услугу по решению инцидентов в объеме, указанном в Таблице 1. Таблица 1 - Журнал по решению инцидентов № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. ИТОГО зарегистрировано: Всего инцидентов: ________ ИТОГО решено: Всего инцидентов: ________ - Приложение 3 к Отчету об оказанных услугах Журнал обращений (заявок) выполнения адаптационного, конфигурационного и коррекционного сопровождения Системы (шаблон) Журнал выполнения адаптации, конфигурации и коррекции Системы сформирован за этап «наименование этапа» в период с «__» _________ по «__» ____________ и представлен в таблице ниже (Таблица 1). Таблица 1 - Журнал выполнения адаптации, конфигурации и коррекции сопровождения Системы № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. Количество выполненных заявок за этап: ________ - Приложение 4 к Отчету об оказанных услугах Журнал обращений (заявок) по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности (шаблон) Журнал обращений (заявок) по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности сформирован за этап «наименование этапа» в период с «__» _________ по «__» ____________ и представлен в таблице ниже (Таблица 1). Таблица 1 - Журнал выполнения заявок по устранению уязвимостей в ППО № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. Количество выполненных заявок за этап: ________ - Приложение Д Форма Протокола проверки результатов организационно-штатных и подготовительных мероприятий (шаблон) Протокол проверки результатов организационно-штатных и подготовительных мероприятий Настоящий Протокол содержит результаты проверки организационно-штатных и подготовительных мероприятий, проведенных Исполнителем (Таблица Д.1). Таблица Д.1. Протокол проверки результатов № Мероприятия Подготовительного этапа Результат проверки 1. Определить и направить Заказчику документ «Ответственные за взаимодействия в рамках выполнения работ по техническому сопровождению Системы со стороны Исполнителя». Документ содержит контактную информацию (ФИО, должность, адрес электронной рабочей почты, номер телефона) не менее чем о 2 лицах, ответственных за оказание услуг со стороны Подрядчика Выполнено/Не выполнено 2. Обеспечить подключение специалистов Подрядчика к Системе Выполнено/Не выполнено 3. Обеспечить подключение специалистов Подрядчика к СРО Выполнено/Не выполнено Заказчик Подрядчик /Должность/ /Должность/ ____________________ /Ф.И.О/ ___________________ /Ф.И.О/ М.П. М.П. «_____»_______________________202_г. «_____»_______________________202_г

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

ОПРЕДЕЛЕНИЯ, ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ - Автоматизированная система (АС) Система, состоящая из комплекса средств автоматизации, реализующего информационную технологию выполнения установленных функций, и персонала, обеспечивающего его функционирование (ГОСТ Р 59853-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения») АРМ Автоматизированное рабочее место АСУ ТК, Система Информационно-аналитическая система регулирования на транспорте АТС Автоматическая телефонная станция БД База данных ГИС Государственная информационная система ГОСТ Государственный стандарт ГЦОД СИЦ Минтранса России, ГЦОД Головной центр обработки данных ФГБУ «СИЦ Минтранса России» Дашборд Интерактивная аналитическая панель, графический интерфейс. ЕИС Единая информационная система в сфере закупок ЕСИА Единая система идентификации и аутентификации Заказчик Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» КИИ Критическая информационная инфраструктура Кластер Кла?стер (англ. cluster) – объединение нескольких однородных элементов, которое может рассматриваться как самостоятельная единица, обладающая определёнными свойствами Компонент Часть АС, выделенная по определенному признаку или совокупности признаков и рассматриваемая как единое целое (ГОСТ Р 59853-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения») Контракт Контракт на выполнение работ по развитию и оказанию услуг по технической поддержке Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК в 2026 году, заключаемый по результатам проведения конкурентной процедуры закупки в соответствии с требованиями Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» - - Значение характеристики не может изменяться участником закупки

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

ФГБУ «СИЦ Минтранса России» Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации», Заказчик Федеральный закон № 44-ФЗ Федеральный закон от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» ФЗ Функциональная задача ФЗ «Реестр объектов» Функциональная задача «Формирование и ведение единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации» ФСБ России Федеральная служба безопасности Российской Федерации ФСТЭК России Федеральная служба по техническому и экспортному контролю ЧС Чрезвычайная ситуация ЭВМ Электронно-вычислительная машина API От англ. Application Programming Interface – интерфейс прикладного программирования – совокупность инструментов и функций в виде интерфейса для взаимодействия с программой CSS От англ. Cascading Style Sheets — каскадные таблицы стилей FPS От англ. frame per second - количество кадров в секунду HTML От англ. HyperText Markup Language - стандартный язык разметки документов, создающий основу и структуру всех веб-страниц JSON От англ. JavaScript Object Notation – текстовый формат обмена данными, основанный на JavaScript WebAssembly (Wasm) Открытый стандарт, представляющий собой низкоуровневый бинарный формат инструкций, который позволяет выполнять код, написанный на языках C++, Rust или Go, в браузерах с производительностью, близкой к нативной

1. ОБЩИЕ СВЕДЕНИЯ - 1.2. Шифр темы или номер контракта Присваивается Заказчиком по результатам организации закупочных процедур. 1.2.1. Предмет контракта Выполнение работ по развитию Модуля СЦ. Код по ОКПД2: 62.01.11.000 – услуги по проектированию и разработке информационных технологий для прикладных задач и тестированию программного обеспечения. Оказание услуг по технической поддержке Модуля СЦ. Код по ОКПД2: 62.02.30.000 – услуги по технической поддержке информационных технологий. Выполнение работ по развитию Модуля СЦ предусмотрено с учетом ключевых результатов (ОКР) Ведомственной программы цифровой трансформации Минтранса России на 2026-2028 (далее - ВПЦТ Минтранса России) в составе мероприятия № 103.002 «АСУ ТК» ИТ расхода 103.26.000005 «Развитие Информационно-аналитической системы регулирования на транспорте (АСУ ТК)»: · «Обеспечено информационное взаимодействие с Минобороны о происшествиях на транспортных объектах»; · «Обеспечена автоматизация формирования отчетов о нештатных ситуациях на транспорте, в том числе по данным внешних систем». Выполнение работ по технической поддержке АСУ ТК предусмотрено ВПЦТ Минтранса России в составе мероприятия № 103.002 «АСУ ТК» ИТ расхода 103.26.000021 «Эксплуатация Информационно-аналитической системы регулирования на транспорте (АСУ ТК)» - - Значение характеристики не может изменяться участником закупки

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

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

1.5. Основания для выполнения работ Работы осуществляются на основании следующих документов: – постановление Правительства Российской Федерации от 30.12.2003 № 794 «О единой государственной системе предупреждения и ликвидации чрезвычайных ситуаций»; – постановление Правительства Российской Федерации от 08.11.2013 № 1007 «О силах и средствах единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций»; – распоряжение Правительства Российской Федерации от 27.11.2021 № 3363-р «О Транспортной стратегии Российской Федерации до 2030 года с прогнозом на период до 2035 года»; – Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 26.08.2025 №ЕФ-3; – Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 27.11.2025 №ЕФ-23;

– Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 19.02.2026 №ЕФ-1; – План мероприятий по профилактике случаев непроизводственного травматизма граждан на железнодорожном транспорте, являющийся приложением к постановлению коллегии Министерства транспорта Российской Федерации от 11.03.2026 № 2

1.6. Перечень документов, требования которых должны быть учтены при выполнении работ – Федеральный закон Российской Федерации от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации»; – Федеральный закон Российской Федерации от 27.07.2006 № 152-ФЗ «О персональных данных»; – Федеральный закон Российской Федерации от 06.04.2011 № 63-ФЗ «Об электронной подписи»; – Федеральный закон Российской Федерации от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации»; – Указ Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации»; – Указ Президента Российской Федерации от 01.05.2022 № 250 «О дополнительных мерах по обеспечению информационной безопасности Российской Федерации»; – Указ Президента Российской Федерации от 31.03.2010 № 403 «О создании комплексной системы обеспечения безопасности населения на транспорте»; – постановление Правительства Российской Федерации от 30.07.2004 № 395 «Об утверждении Положения о Министерстве транспорта Российской Федерации»; – постановление Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации»; – постановление Правительства Российской Федерации от 16.11.2015 № 1236 «Об установлении запрета на допуск программного обеспечения, происходящего из иностранных государств, для целей осуществления закупок для обеспечения государственных и муниципальных нужд»; – постановление Правительства Российской Федерации от 23.12.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 Федерального закона «Об электронной подписи»;

– постановление Правительства Российской Федерации от 08.06.2011 № 451 «Об инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг и исполнения государственных и муниципальных функций в электронной форме»; – постановление Правительства Российской Федерации от 30.01.2013 № 62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин»; – приказ ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации»; – приказ ФСТЭК России от 11.04.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений»; – приказ ФСБ России от 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.7. Сроки начала и окончания работ Начало работ: с даты заключения Контракта. Окончание работ: не позднее 15.12.2026. Работы выполняются в соответствии с этапами. Сроки выполнения этапов работ по развитию и технической поддержке Модуля СЦ определяются Календарным планом. Календарный план, приведен в разделе 5 настоящего ТЗ

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

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

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

1.1. Наименование Системы Полное наименование системы: Информационно-аналитическая система регулирования на транспорте. Условное обозначение системы: АСУ ТК. Полное наименование модуля: Модуль сбора, ведения и анализа информации о нештатных ситуациях на транспорте. Условное обозначение модуля: Модуль СЦ. Модуль СЦ создан в рамках контракта от 05.08.2024 № ОК/24_04 на выполнение работ по развитию АСУ ТК в части создания модуля «Сбора, ведения и анализа информации о нештатных ситуациях на транспорте». Развитие Модуля СЦ осуществлено в рамках контракта от 19.05.2025 № ОК/25_09 на выполнение работ по развитию Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК

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

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

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

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

3. ХАРАКТЕРИСТИКА ОБЪЕКТА АВТОМАТИЗАЦИИ - 3.1. Описание объекта автоматизации АСУ ТК Объектом автоматизации являются процессы основной и обеспечивающей деятельности, направленные на управление транспортным комплексом, в том числе, процессы информационного взаимодействия с другими организациями и субъектами транспортного комплекса. АСУ ТК относится к государственным информационным системам, а также к информационным системам персональных данных и значимым объектам критической информационной инфраструктуры Российской Федерации. АСУ ТК соответствует требованиям, предъявляемым к: – ГИС второго класса защищенности в соответствии с приказом ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах»; – ИС персональных данных при обеспечении третьего уровня защищенности персональных данных в соответствии с требованиями постановления Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»; – значимым объектам КИИ Российской Федерации второй категории значимости с постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении Правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений». Модуль СЦ является подсистемой АСУ ТК. Перечень платформенных решений и функциональных задач АСУ ТК представлен в Таблице 1 - - Значение характеристики не может изменяться участником закупки

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

8 Подсистема проектного архива АСУ ТК Подсистема проектного архива АСУ ТК предназначена для автоматизации деловых процессов должностных лиц Министерства транспорта Российской Федерации, подведомственных агентств и службы, в том числе, и процессов информационного взаимодействия внутреннего и внешнего характера 9 ФЗ «Реестр объектов» Функциональная задача предназначена для формирования и ведения единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации 10 ФЗ «СТП» Функциональная задача предназначена для организации информационно-аналитической поддержки процессов территориального планирования Российской Федерации в области федерального транспорта 11 ФЗ «МРТБ ПП» Функциональная задача предназначена для формирования и ведения межрегионального транспортного баланса пассажирских перевозок в дальнем (межрегиональном) сообщении 12 ФЗ «МДД» Функциональная задача предназначена для осуществления мониторинга дорожного движения 13 ФЗ «ТПР» Функциональная задача предназначена для формирования и ведения транспортного паспорта региона 14 ФЗ «Данные по грузообороту» Функциональная задача предназначена для обеспечения подсистем и пользователей АСУ ТК данными по грузообороту между Российской Федерацией и зарубежными странами 15 ФЗ «МЖТ» Функциональная задача предназначена для осуществления мониторинга железнодорожного транспорта 16 ФЗ «МГМП» Функциональная задача предназначена для осуществления мониторинга грузопотоков в морских портах с целью формирования единой цифровой среды мониторинга и планирования перевозок в/из портов Дальнего Востока

17 Модуль ГЭТ Модуль предназначен для получения, хранения данных инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по отдельно взятому предприятию-перевозчику. Формирования отчетов об инвентаризации с детальными данными по каждому разделу инвентаризации с маршрутизацией в муниципалитет / регион / Минтранс. Содержит агрегированные данные инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по всем перевозчикам, относящихся к данному муниципалитету. Формирует сводный отчет по муниципалитету по каждому разделу инвентаризации с маршрутизацией в регион / Минтранс. Формирует агрегированные данные инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по всем перевозчикам, относящиеся к данному региону и по всем муниципалитетам, относящимся к данному региону. Аналитические и статистические данные о состоянии ГЭТ региона. Содержит данные о видах транспорта, цифровых транспортных сервисах и платежных инструментах Региона. Формирует сводный отчет по каждому разделу инвентаризации с маршрутизацией в Минтранс. Формирует агрегированную статистику и аналитику по всем регионам страны в разрезе транспортных средств, маршрутов, пассажиропотоков, инфраструктуры ГЭТ. Данные о рейтинге регионов и перевозчиков на основании выбранных параметров, документооборот с участниками Системы: получение подписанных печатных форм, их утверждение, возврат на доработку. 18 Модуль iМинтранс Модуль создан для отчета по ключевым показателям транспортного комплекса России (Отраслевые и статистические показатели, исполнение бюджета, исполнение поручений, аналитика СМИ, происшествия по видам транспорта). 19 Модуль СЦ Модуль СЦ предназначен для оперативного мониторинга нештатных ситуаций транспортной отрасли, оповещения заинтересованных лиц и структур и предоставления данных о нештатных ситуациях

АСУ ТК осуществляет идентификацию и авторизацию посредством Единой системы идентификации и аутентификации (ЕСИА). Информационный обмен с внешними информационными системами осуществляется посредством СМЭВ 3 и СМЭВ 4. АСУ ТК развернута на вычислительных мощностях ГЦОД СИЦ Минтранса России

3.2. Описание и текущее состояние объекта автоматизации Модуля СЦ Объектом автоматизации является процесс организации мониторинга информации о НС и ЧС на транспорте. Предметом деятельности Учреждения являются следующие функции: – информационное обеспечение в области транспортной безопасности, защиты населения и территорий от чрезвычайных ситуаций природного и техногенного характера в транспортном комплексе; – подготовка справочных материалов при угрозе возникновения и возникновении чрезвычайных ситуаций и иных происшествий в транспортном комплексе; – взаимодействие и обмен оперативной информацией с органами управления Единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций; – организация оперативного мониторинга обстановки на объектах транспорта при угрозе и возникновении чрезвычайных ситуаций и иных происшествий. Перечень компонентов Модуля СЦ и выполняемые ими функции представлены в Таблице 2

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

3 Информирование – ведение справочника способов оповещения (веб-интерфейс, мессенджер); – формирование сценария выполнения оповещения (настройка условий, способа, параметров оповещения); – выполнение оповещений пользователей 4 Отчетность – формирование отчета и справки о событиях; – фильтрация событий для выгрузки в справку о событиях или в отчет о событиях 5 Администрирование – ведение ролей пользователей; – ведение учетных данных пользователей; – ведение справочника организаций; – ведение справочника групп системы мгновенного обмена сообщениями; – выполнение исходящего звонка на контактный телефонный номер организации; – формирование матрицы эскалации событий Архитектура Модуля СЦ представлена на рисунке 1. Рисунок 1. Архитектура Модуля СЦ

3.3. Состав используемого ПО Модуля СЦ Программная архитектура Модуля СЦ разработана как трехуровневая клиент-серверная архитектура. Архитектура включает в себя следующие уровни: • уровень представления – презентационный уровень, обеспечивающий взаимодействие с пользователя с клиентскими приложениями с использованием веб-браузера («тонкий» клиент); • уровень приложений – реализован в виде сервисов, обеспечивает обработку запросов, поступающих от клиентских приложений, формирование ответов на запрос в доступном пользователю виде (формирование пользовательских интерфейсов); • уровень хранения данных – реализуется как сервер БД и обеспечивает хранение и целостность хранимых данных, создание резервных копий, ведение журнала транзакций, восстановление данных после сбоев. Программная архитектура Модуля СЦ включает в себя сервисы и интерфейсы, указанные в Таблице 3. Таблица 3. Программная архитектура Модуля СЦ Программный сервис/интерфейс Технологии реализации Уровень представления Интерфейс пользователя и администратора (front-end) Javascript Уровень приложений Сервис (GateWay) Kotlin Сервис геокодирования (geocoding-service) Kotlin Сервис уведомлений (notifiсation-service) Kotlin Сервис работы с файлами (file-service) Kotlin Сервис отчетности (report-service) Kotlin Сервис управления событиями (event-service) Kotlin Сервис информирования через мессенджер (messenger-notifier) Python Сервис внешних интеграций (integration-service) Сбор информации из внешних систем и сервисов Брокер сообщений Kafka Уровень хранения данных Файловое хранилище MinIO S3 СУБД Postgres Pro Enterprise

3.4. Информационное взаимодействие программных сервисов и интерфейсов Модуля СЦ Объект автоматизации функционирует в распределенной информационной среде. Обмен данными осуществляется по защищенным каналам связи (в том числе ведомственным сетям передачи данных). Источники информации включают: · внешние автоматизированные системы (органов государственной власти); · внутренние базы данных (реестры объектов транспортной инфраструктуры, паспорта регионов и пр.); · оперативная информация от персонала, поступающая через автоматизированные рабочие места (АРМ) и мобильные устройства. 3.4.1. Взаимодействие Модуля СЦ со смежными подсистемами АСУ ТК Модуль СЦ входит в состав АСУ ТК и взаимодействует со следующими ее функциональными задачами и подсистемами: · Функциональной задачей «Формирование и ведение единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации» (ФЗ «Реестр объектов»); · Геоинформационной подсистемой АСУ ТК (П-ГИС); · Подсистемой ведения нормативно-справочной информации и метаданных (П-НСИ); · Подсистемой сбора данных и централизованное хранилище данных (П-СД); · Подсистемой информационного взаимодействия (П-ИВ). 3.4.2. Взаимодействие с внешними информационными системами Список внешних информационных систем, с которыми осуществляется взаимодействие Модуля СЦ: · ЕСИА; · мессенджер; · Яндекс Геокодер; · Информационная система «Централизованная система сбора информации систем-112»; · ПВК «Поиск-Море», АИС РПТ; · облачная АТС

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

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

Для обеспечения взаимодействия с Заказчиком Подрядчик со своей стороны определяет ответственных лиц, уполномоченных в структуре Подрядчика за своевременное и качественное оказание Услуг в рамках настоящего ТЗ, а также контактную информацию ответственных лиц (телефон, электронную почту). Подрядчик должен предоставить Заказчику единый адрес электронной почты для приема обращений (заявок) в течение 3 (трех) рабочих дней после заключения Контракта. Указанный в настоящем пункте адрес электронной почты (способ направления обращений (заявок) применяется в случае сбоя в работе СРО Заказчика. Со своей стороны, Заказчик предоставляет Подрядчику перечень и контактную информацию (телефон, электронную почту) уполномоченных лиц для осуществления взаимодействия с указанием зон ответственности. О любых изменениях в контактной информации ответственных лиц Стороны должны уведомить друг друга в течение 1 (одного) рабочего дня с момента возникновения таких изменений посредством уведомления на электронную почту ответственных лиц и/или в письменной форме. В результате оказания услуг по настоящему ТЗ не должны быть изменены исходные коды, дистрибутивы и иные компоненты Модуля СЦ вне согласованных с Заказчиком изменений. Любые изменения исходных кодов, дистрибутивов и иных компонентов Модуля СЦ должны производиться только после согласования с Заказчиком уполномоченными лицами по электронной почте или иным заранее согласованным способом. Не должна быть ухудшена надежность и производительность Модуля СЦ. Оказание услуг по Контракту не должно нарушать требования к информационной безопасности, описанной в документации на Модуль СЦ

– выполнение требований по обеспечению в автоматизированном режиме с Национальной системой противодействия DDoS-атакам (НСПА) Центра мониторинга и управления сетью связи общего пользования ФГУП «ГРЧЦ» в рамках реализации мер по защите ГИС от атак, направленных на отказ в обслуживании; – детализированные требования к составу и содержанию работ по аттестации, а также к их результатам в соответствии с пунктами 13, 15 и 16 требований приказа ФСТЭК России от 29.04.2021 № 77 «Об утверждении Порядка организации и проведения работ по аттестации объектов информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну»

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

Подрядчик должен обеспечить реализацию и проведение внутренних проверок мер по разработке безопасного ПО, приведенных в Руководстве. Подрядчик должен провести анализ угроз безопасности информации программного обеспечения в соответствии с ГОСТ 58412-2019 «Защита информации. Разработка безопасного программного обеспечения. Угрозы безопасности информации при разработке программного обеспечения». Подрядчик должен провести испытания по выявлению уязвимостей в программном обеспечении Системы: · проведение статического анализа исходного кода программы; · проведение динамического анализа исходного кода программы; · проведение композитного анализа исходного кода и образов программы; · проведение фаззинг-тестирования программы, направленного на выявление в ней уязвимостей. Испытания по выявлению уязвимостей в программном обеспечении Системы должны быть проведены в рамках: · предварительных испытаний; · опытной эксплуатации; · приемочных испытаний

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

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

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

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

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

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

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

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

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

4.5.8. Требования к защите от влияния внешних воздействий Требования к защите от влияния внешних воздействий не предъявляются

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

4.3.4. Требования к документированию результатов оказываемых услуг Для обеспечения контроля оказываемых услуг по поддержке Модуля СЦ со стороны Заказчика, по окончании каждого отчетного периода по контракту в соответствии с календарным планом, Подрядчик обязан предоставить Заказчику Отчет об оказанных услугах. Отчет должен содержать детальную информацию об оказанных услугах с указанием даты выполненных мероприятий и приложением обосновывающих документов (заявок, запросов, требований) или ссылкой на такие документы, если они содержатся в Модуле СЦ. Информация о выполненных мероприятиях по заявкам должна быть сформирована на основании соответствующих записей СРО по каждому этапу исполнения Контракта. В случае оказания услуги адаптационного, конфигурационного и коррекционного сопровождения Модуля СЦ, должны быть предоставлены документы, подтверждающие выполнение требований п. 29.3 приказа ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации». Фактическое время реагирования и время решения по всем обращениям, поступившим в СРО, формируется в СРО по итогам отчетного периода в разделе «Отчеты». Фактическое время реагирования и время решения по обращениям учитывает суммарное время, затраченное на реагирование и, соответственно, на работу по обращению с момента назначения обращения специалисту Подрядчика или группе исполнителей, ответственным за оказание услуг технической поддержки 3 уровня от начала до завершения работ Подрядчиком. При этом принимается суммарное время нахождения заявки в соответствующих статусах заявки СРО на стороне Подрядчика

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

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

Лицензионное (сублицензионное) соглашение (договор) не может возлагать на Заказчика какие-либо обязанности (в т.ч. в части конфиденциальности, предоставления отчетности), не предусмотренные Контрактом. 4.5.9.7. Передача Заказчику исключительных прав, или простых (неисключительных) прав не может повлечь увеличение стоимости Контракта и/или изменение иных существенных условий Контракта. 4.5.9.8. Функциональность Модуля СЦ передается в объеме и в сроки, установленные Техническим заданием. 4.5.9.9. Нарушение условий настоящего раздела Технического задания, в т.ч. отсутствие соответствующего лицензионного (сублицензионного) соглашения (или договора), либо предоставление лицензионного (сублицензионного) соглашения (или договора), не соответствующего требованиям действующего законодательства Российской Федерации или требованиям Контракта, является нарушением существенных условий Контракта. 4.5.9.10. В случае, если в соответствии с пунктом 4.5.9.6 Заказчику передается исключительное право, такая передача осуществляется в порядке, установленном Гражданским кодексом Российской Федерации. 4.5.9.11. В случае, если при выполнении Работ положения пунктов 4.5.9.5-4.5.9.6 не применялись, Подрядчик в составе отчетной документации предоставляет об этом декларацию в свободной форме. Декларация должна содержать сведения о полном соответствии результата Работ требованиям Контракта, а также о неприменении при выполнении работ готового программного обеспечения (платформ, подсистем, СУБД и т.д.), которое стало частью (компонентом) Системы

Таблица 6. Категории обращений и заявок Категория Примеры Запрос на обслуживание Подготовка SQL запроса к СУБД для решения прикладной задачи и д.р. – запрос на любое действие, не являющееся запросом информации и несовершенный на основе происшествия, прямо или косвенно влияющего на работу Модуля СЦ Консультация «Где взять / куда обратиться...?», «Как сделать / выполнить…», «Как это работает…?» - запрос, имеющий своей целью получение информационной поддержки Инцидент Разбор ошибок/сбоев и подготовка материалов (корректировочных релизов, инструкций) для Заказчика для устранения ошибок/сбоев, которые приводят к частичному и полному нарушению работоспособности всех или отдельных функций ППО. Подготовка изменения и материалов, необходимых для проведения аварийно-восстановительных работ для возобновления работоспособности Модуля СЦ ЗНИ Подготовка изменений, связанных с изменением, улучшением/оптимизацией Модуля СЦ и выводом новой модифицированной функциональности в штатном режиме. Подготовка изменений, связанных с модификацией существующих и/или реализация новых интеграционных механизмов для получения/обработки данных внешних систем. Подготовка изменений графического интерфейса по требованиям Заказчика. Перечень статусов обращений (заявок) приведен в пункте 3.3. Регламента оказания Услуг. Назначение обращению (заявке) статуса «Закрыто» осуществляется Заказчиком только после получения от инициатора обращения (заявки) подтверждения о его исполнении или нахождения обращения (заявки) в статусе «Выполнено» и отсутствия повторных вопросов/запросов по данному обращению (заявки) в течение 5 рабочих дней. Категории и статусы обращений (заявок) могут быть скорректированы в процессе оказания услуг исключительно по согласованию с Заказчиком

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

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

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

4.3.6.2. Требования к услугам информационно-консультационной поддержки работников Заказчика и пользователей Модуля СЦ Услуги информационно-консультационной поддержки сотрудников Заказчика включают: – обработку обращений и заявок, поступивших от сотрудников Заказчика; – консультирование сотрудников Заказчика и пользователей Модуля СЦ; – актуализацию документации, и других материалов по работе с Модулем СЦ при необходимости. – консультирование и разработку рекомендаций по настройке Модуля СЦ (без изменения программного кода), включая изменение настроек функционирования; – консультации по вопросам использования, настройки и возможностям Модуля СЦ; – консультации по проведению превентивных мер для недопущения аварийных ситуаций в Модуле СЦ; – консультации по предварительной диагностике и локализации возникшей неисправности Модуля СЦ; – консультации по вопросам обеспечения информационной безопасности Модуля СЦ и настройки функций, обеспечивающих корректную работу программного обеспечения для совершения юридически значимых действий в Модуле СЦ; – другие вопросы, связанные с работой Модуля СЦ. 4.3.6.2.1. Требования к порядку оказания услуг информационно-консультационной поддержки работников Заказчика и пользователей Модуля СЦ Подрядчик выполняет консультирование сотрудников Заказчика и пользователей Модуля СЦ. Консультация может быть предоставлена по согласованным с представителем Заказчика каналам коммуникации с регистрацией результата консультации в СРО Подрядчиком. Детальный порядок оказания консультационных услуг определен в Регламенте оказания Услуг

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

4.5.11. Требования к показателям назначения 4.5.11.1. Требования к показателям назначения мероприятий по развитию Модуля СЦ В рамках выполнения работ по развитию Модуля СЦ, предусмотренных ТЗ, показатель назначения «Количество пользователей» должен соответствовать значениям, приведенным в данном разделе. Пояснения по показателям, связанным с количеством пользователей, приведены в Таблице 8. Таблица 8. Определения показателей, связанных с количеством пользователей в Модуле СЦ № Показатель Определение Расчетное количество пользователей Количество пользователей, работу которых должен обеспечить Модуль СЦ к моменту сдачи работ по Контракту с учетом достижения всех показателей назначения Расчетное количество одновременно работающих пользователей Количество одновременно работающих пользователей, работу которых должен обеспечивать Модуль СЦ к моменту сдачи работ по Контракту с учетом достижения всех показателей назначения Значения показателей количества пользователей, достижение которых необходимо обеспечить, представлено в Таблице 9

Таблица 9. Значения показателей количества пользователей № Показатель Значение 1. Расчетное количество пользователей 1 000 2. Расчетное среднее количество одновременно работающих пользователей 200 Развитие Модуля СЦ должно быть направлено на достижение следующего эффекта (показателя), подставленного в мероприятии 103.002 «Информационно-аналитическая система регулирования на транспорте (АСУ ТК)» ВПЦТ Минтранса России: Выполнение работ по развитию Модуля СЦ предусмотрено мероприятием по развитию АСУ ТК, приведенном в ВПЦТ Минтранса России на 2026-2028 гг: № 103.002 «АСУ ТК» в составе ИТ расхода 103.26.000005 «Развитие предусматривает реализацию ОКР и эффектов, приведенных в Таблице 10. Таблица 10. ОКР и эффекты, приведенные в ВПЦТ Минтранса России на 2026 г. № ОКР Дата ОКР Эффекты 1 Обеспечено информационное взаимодействие с Минобороны России о происшествиях на транспортных объектах 25.12.2026 Сокращено время сбора и передачи сведений для Минобороны России о ЧС и НС на транспорте с 120 до 10 минут 2 Обеспечена автоматизация формирования отчетов о нештатных ситуациях на транспорте, в том числе по данным внешних систем 25.12.2026 Сокращено время на подготовку отчетов о нештатных ситуациях на транспорте с 20 до 5 минут Реализация остальных ОКР не является предметом данного ТЗ и проводится в рамках отдельного технического задания.

4.5.11.2. Требования к показателям назначения мероприятий по эксплуатации Модуля СЦ. Работы по эксплуатации Модуля СЦ не должны обеспечивать режимы функционирования Модуля СЦ, приведенные в разделе 4.5.2 данного ТЗ

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

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

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

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

4.3.6.4. Требования к услугам адаптационного, конфигурационного и коррекционного сопровождения и доработки Модуля СЦ (в рамках действующих программных модулей и функциональностей) Услуги адаптационного, конфигурационного и коррекционного сопровождения и доработки Модуля СЦ включают: – управление изменениями и адаптация функций Модуля СЦ; – изменение настроек функционирования Модуля СЦ; – внесение изменений и/или модификаций Модуля СЦ (в рамках действующих программных модулей и функциональностей), направленных на улучшение их работоспособности и функциональных возможностей; – подготовка и передача Заказчику SQL запросов в СУБД для получения агрегированной информации из Модуля СЦ, которую невозможно получить с использованием графического пользовательского интерфейса; – адаптация модулей интеграций со смежными информационными системами

4.3.6.4.1. Требования к проведению изменений Основанием для внесения изменений является запрос от Заказчика. Все активности по внесению изменений должны быть согласованы с Заказчиком, а действия Подрядчика при оказании данной услуги должны быть зафиксированы. В рамках данного Технического задания изменениями считаются локальные доработки функционала Модуля СЦ, которые не должны приводить к необходимости выполнения дополнительных аттестационных испытаний или переаттестации АСУ ТК в соответствии с п. 33 приказа от 29.04.2021 № 77 «Об утверждении Порядка организации и проведения работ по аттестации объектов информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну». При необходимости внесения изменений в Модуль СЦ, не связанных с критичным инцидентом, существенно нарушающим работоспособность Модуля СЦ, Заказчик направляет Подрядчику обращение (заявку), в котором излагает суть изменения, которое требуется внести в Модуль СЦ. Исполнитель, в течение 3 (трех) рабочих дней с момента поступления соответствующего обращения (заявки), оценивает техническую возможность реализации запрашиваемого изменения и варианты реализации. По итогу проведения оценки Подрядчик направляет Заказчику заключение о возможности реализации данного изменения с описанием возможных вариантов реализации и согласует с Заказчиком проведение данного изменения

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

4.3.6.4.2. Требования к изменению настроек функционирования Изменение настроек функционирования может проводиться в рамках допустимых пределов изменения функционирования, заложенных в архитектуру Модуля СЦ. Изменение настроек функционирования включает в себя изменение данных и справочников, изменение форм документов, формируемых Модулем СЦ, изменение и настройку форматов и версий передачи данных в смежные системы. Доработка программного кода Модуля СЦ может допускаться (в случае необходимости) при выполнении работ по адаптации функций Модуля СЦ в части изменения формата передачи данных в смежные информационные системы при условии соблюдения требований пункта 29.3 приказа ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации»

4.3.6.5. Требования к услугам по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности По запросу Заказчика Подрядчик должен провести работу по приведению ППО в соответствие с требованиями по обеспечению информационной безопасности. Критичность уязвимости оценивается в соответствии в соответствии с Методическим документом ФСТЭК России «Методика оценки уровня критичности уязвимостей программных, программно-аппаратных средств» (утвержден ФСТЭК России 30.06.2025), а также с учетом ГОСТ 56545-2015 и международными стандартами (CVSS 3.0 и выше), и задает необходимый срок устранения. В процессе проведения Заказчиком обследования Модуля СЦ и выявления уязвимостей в ППО, связанных с исходным кодом Модуля СЦ и/или используемыми компонентами (библиотеками), Заказчик направляет Подрядчику обращение (заявку) на устранение, с указанием критичности и срочности принятия мер по устранению в СРО.

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

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

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

4.4. Требования к видам обеспечения 4.4.1. Требования к лингвистическому обеспечению Документация на Модуль СЦ должна разрабатываться на русском языке. Взаимодействие пользователей с Модулем СЦ посредством графического интерфейса должно происходить на русском языке за исключением сообщений, зависящих от настроек системного программного обеспечения, установленного на рабочих местах пользователей. При разработке программных решений Модуля СЦ должно быть предусмотрено использование языков программирования высокого уровня, приведенных в Таблице 7. Таблица 7. Языки и средства разработки, специального программного обеспечения Модуля СЦ Категория Наименование Назначение Языки программирования Kotlin Разработка серверной логики и сервисов (backend) JavaScript / TypeScript Разработка клиентской части (frontend) Python Разработка скриптов интеграции, обработки данных и автоматизации Фреймворки и библиотеки Vue.JS Разработка пользовательских интерфейсов (веб-интерфейсы компонентов визуализации и отчетности) React Разработка пользовательских интерфейсов (при необходимости создания сложных интерактивных компонентов) Решения по лингвистическому обеспечению, включая перечень используемых языков программирования, должны быть согласованы с Заказчиком на этапе технического проектирования

4.4.2. Требования к математическому обеспечению Требования к математическому обеспечению не предъявляются. 4.4.3. Требования к метрологическому обеспечению Требования к метрологическому обеспечению не предъявляются. 4.4.4. Требования к организационному обеспечению Требования к организационному обеспечению не предъявляются. 4.4.5. Требования к методическому обеспечению Задачи методического обеспечения Модуля СЦ должны быть обеспечены за счет использования технологических и методических документов касающихся вопросов функционирования транспортного комплекса и разработки и эксплуатации ПО. 4.4.6. Требования к информационному обеспечению Состав, структура и способы организации информационного обеспечения в Модуле СЦ должны быть определены на этапе технического проектирования. Факты информационного обмена с внешними системами должны фиксироваться в соответствующем журнале

4.1. Требования к структуре Модуля СЦ В процессе работ по развитию Системы должны сохраниться основные требования к построению архитектуры Системы в соответствии с принципами трехуровневой архитектуры: 1. уровень хранения данных или уровень базы данных (сервер СУБД); 2. уровень сервера приложений (сервер аналитической обработки); 3. презентационный уровень, обеспечивающий взаимодействие с клиентскими приложениями. В состав Системы должны входить следующие основные компоненты: 4. сервер баз данных; 5. сервер приложений; 6. веб-сервер. Сервер баз данных должен обеспечивать хранение и целостность хранимых данных, создание резервных копий, ведение журнала транзакций, восстановление данных после сбоев. Сервер приложений должен обеспечивать обработку запросов, поступающих от клиентских приложений (через веб-сервер), формирование ответов на запрос в доступном пользователю виде (формирование пользовательских интерфейсов). Веб-сервер должен обеспечивать взаимодействие с оператором и внешними системами по HTTP / HTTPS протоколу в режиме «запрос-ответ» (получения запросов от пользователя и передачи ответа в виде соответствующей информации, обработанной серверами приложений). Взаимодействие Системы с пользователем должно отвечать требованиям модели «тонкого клиента» (т.е. представлять на стороне клиента (пользователя) лишь графический пользовательский интерфейс). Все составляющие Системы должны использовать единую методологию и отвечать единым принципам взаимодействия, надежности и управления. Перечень компонентов Модуля СЦ представлен в Таблице 4. Таблица 4. Перечень компонентов Модуля СЦ, в отношении которых выполняются работы по развитию № п.п. Наименование компонента Модуля СЦ Раздел ТЗ 1 Компонент регистрации событий 4.2.1. 2 Компонент отчетности 4.2.2 3 Компонент визуализации 4.2.3 4 «Интерактивная карта» (компонент создается) 4.2.4 5 Компонент администрирования 4.2.5

4.2. Требования к дорабатываемым функциям модуля СЦ 4.2.1. Развитие компонента регистрации событий (1 очередь) Должны быть выполнены следующие доработки: – обеспечение логирования действий пользователя, связанных с карточкой события; – доработка объектной модели в части создания новых типов сущностей (карточек) с учетом реализуемых интеграций с информационными ресурсами (силы и средства предупреждения и ликвидации ЧС и нештатных ситуаций на транспорте, ТС, ограничения воздушного пространства, неблагоприятные и опасные природные явления); – реализация механизма установления связи между сущностями в Модуле СЦ автоматизированным и ручным способами (события, природные явления, силы и средства предупреждения и ликвидации ЧС и нештатных ситуаций на транспорте, ограничения воздушного пространства, ОТИ, ТС и др.); – отображение в карточке установленных связей между сущностями.

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

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

4.4.7.1. Требования к инструментам разработки и процессу контроля версий программного обеспечения 4.4.7.1.1. Система контроля версий Для управления исходным кодом должна использоваться система контроля версий кода, развернутая в инфраструктуре Заказчика. 4.4.7.1.2. Правила именования веток Имя ветки должно соответствовать следующему формату: / / Категории веток: ? feature/ — разработка новой функциональности, а также рефакторинг или удаление существующей; ? fix/ — исправление ошибок; ? hotfix/ — срочные исправления, применяемые в обход стандартного процесса разработки; ? test/ — для проведения экспериментов, не влияющих на основную разработку. Идентификатор задачи: после категории указывается ссылка на задачу (issue) в системе контроля версий кода. Описание: добавляется краткое описание решаемой задачи в формате kebab-case (слова разделяются дефисами, например, add-user-auth). Примеры именования веток: ? feature/#123/add-payment-integration; ? fix/#45/correct-calculation-logic; ? hotfix/#67/urgent-database-connection-patch. 4.4.7.1.3. Правила именования коммитов Сообщение коммита должно соответствовать соглашению Conventional Commits и состоять из категории и описания: : ? fix — исправление ошибки. Примеры сообщений коммитов: ? feat: добавление формы регистрации пользователя; ? fix: исправление ошибки валидации email-адреса; ? refactor: оптимизация алгоритма сортировки данных; ? chore: обновление версий в файле dependencies. 4.4.7.1.4. Модель ветвления В процессе разработки используются следующие основные ветви: ? main / master — стабильная ветка, содержит только код, прошедший полное тестирование и развернутый в продуктивных контурах; ? dev — ветка для интеграции завершенных задач, предназначенная для сборки и тестирования в тестовых средах. Попадание кода в main осуществляется только через Merge Request (MR) из dev

4.2.2. Развитие компонента отчетности (3 очередь) Должна быть обеспечена автоматизация процессов формирования отчетов о ЧС и нештатных ситуациях на транспорте, в т.ч. на основе данных из внешних систем. Включает следующие доработки: – разработка шаблонов отчетов в различных форматах (табличный, текстовый); – реализация выбора фотоматериалов для включения в справку; – форматирование содержимого справок с учетом правил русского языка в отношении окончаний слов (в зависимости от падежа, склонения, числа и рода); – автоматизированное формирование выводов к содержимому справки на основе настраиваемых критериев; – создание интерфейса выбора параметров (фильтрации) для формирования отчетов: o состав полей для включения в отчёт; o настройка диапазонов значений характеристик и дат; o порядок отображения полей; o настройка заголовка. – реализация способа подготовки отчётов в асинхронном режиме (очереди); – реализация интерфейса компонента формирования отчетности для отображения очереди формирования отчетов и статусов их подготовки; – экспорт отчётов в форматы xlsx, csv и справок в форматы pdf, docx. Необходимо разработать не менее 10 шаблонов отчетов и/или справок. Перечень, структура и содержание шаблонов должны быть согласованы с Заказчиком на этапе технического проектирования.

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

– отображение на карте связанных сущностей и ОТИ; – реализация функции выбора темного и светлого стилей отображения элементов интерфейса, карточек сущностей, картографической основы и объектов, отображаемых на карте; – реализация механизма для выбора картографической основы в одном из распространенных форматов WMTS, TMS, MVT и др. Должна быть предусмотрена возможность настройки перечня картографических основ и параметров доступа к ним; – настройка базового набора дашбордов, содержащих преднастроенные виджеты о количестве событий в разрезе видов транспорта с возможностью перехода к исходным данным (карточкам событий, ОТИ и т.д.), с фильтрацией по параметрам. Параметры фильтрации должны быть определены на этапе технического проектирования. Должно быть обеспечено автоматическое и принудительное обновление данных, отображаемых на дашбордах

4.4.7.1.5. Требования к используемым зависимостям (библиотекам) Все внешние зависимости проекта должны быть зафиксированы с указанием точных версий. Для контроля версий зависимостей в репозиторий обязательно должны быть включены следующие файлы: · Для JavaScript: package-lock.json или yarn.lock; · Для Python: requirements.txt (с зафиксированными версиями) или Pipfile.lock; · Для Go: go.mod и go.sum; Загрузка всех зависимостей должна производиться исключительно через внутренний прокси-репозиторий Заказчика, настроенный в соответствующем системе менеджере пакетов. Запрещается: · Использование плавающих версий (например, ^1.2.3, ~4.5.0, latest); · Использование библиотек, содержащих критические уязвимости, в том числе зарегистрированные в реестре CVE (Common Vulnerabilities and Exposures). 4.4.7.1.6. Требования к процессу непрерывной интеграции (CI) Сборка программного обеспечения, включая этапы компиляции, тестирования и анализа кода, должна выполняться исключительно в инфраструктуре непрерывной интеграции Заказчика. 4.4.7.1.7. Требования к хранению артефактов сборки Все артефакты сборки (результирующие пакеты, Docker-образы и т.д.) подлежат обязательному хранению в предназначенной для этого инфраструктуре Заказчика (артефакторий). Запрещается размещение финальных артефактов сборки на сторонних ресурсах

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

4.5. Общие технические требования 4.5.1. Требования к численности и квалификации персонала и пользователей Модуля СЦ Программное обеспечение Модуля СЦ не должно требовать изменения штатной численности персонала Заказчика. Программное обеспечение Модуля СЦ не должно требовать наличия у пользователей дополнительной квалификации в сфере информационных технологий, кроме базовых знаний в обращении с персональным компьютером, базовых навыков работы в интернет-обозревателях и знаний о Модуле СЦ в объеме документов Руководство пользователя, Руководство администратора

4.2.4. Создание компонента «Интерактивная карта» (2 очередь) В составе создаваемого компонента должны отображаться данные, доступные в компоненте визуализации. Требования к интерфейсу интерактивной карты: – интерактивная карта должна быть представлена в виде объемной карты с учетом макетов, представленных в Приложении А к ТЗ; – интерфейс должен корректно отображаться на экранах мониторов (разрешение Full HD 1920?1080), телевизоров (разрешение 4К 3840?2160), жидкокристаллических панелей для видеостены, используемой Заказчиком, с параметрами каждой панели: диагональ 55 дюймов, разрешение 1920x1080; – интерфейс должен корректно отображаться на планшетных устройствах с диагональю экрана 10-12 дюймов, конкретные требования должны быть уточнены на этапе технического проектирования; – должна быть обеспечена кластеризация и генерализация отображения объектов на карте при изменении масштаба; – должно быть обеспечено отображение основных характеристик объектов при выборе их на карте; – должно быть обеспечено управление отображением слоев на карте; – должна быть обеспечена настройка цветовой индикации отображаемых объектов транспортной инфраструктуры; – должно быть обеспечено отображение легенды карты, содержащей отображаемые объекты на карте; – должна быть обеспечена возможность одновременного отображения не менее 5 000 ОТИ и ТС на карте.

На интерактивной карте должны быть отображены подвижные объекты совместно с объектами транспортной инфраструктуры (ОТИ), включая следующие возможности: § отображение местоположения транспортных средств (воздушный, водный и автомобильный транспорт) на карте в режиме реального времени (с заданным периодом обновления данных); § отображение маршрутов движения всех ТС за выбранный период времени, в том числе с использованием эффектов анимации; § отображение маршрутов движения ТС, связанных с карточкой события: ТС, являющихся участниками события, и ТС, находящиеся в заданном радиусе от события; § управление отображением сущностей и ОТИ на карте, включая настройку состава отображаемых объектов, поиск, фильтрацию, с использованием соответствующей панели управления и наглядным представлением результатов; § автоматическое изменение вида отображения объектов (цветовая индикация) по заданным условиям (например, при достижении критических значений параметров, характеризующих функционирование объекта); Должна обеспечиваться производительность обновления изображения на экране в 30 кадров в секунду на тестовой конфигурации пользовательского устройства (модель Бештау AIO2402/B560, входящая в Реестр российской промышленной продукции под номером 10394100 или аналог) при одновременном отображении не менее 5 000 объектов и 200 уникальных моделей объектов. Макеты интерфейсов Модуля СЦ должны быть предварительно согласованы с Заказчиком и разработаны с учетом требований ГОСТ Р ИСО 9241-161-2016 «Элементы графического пользовательского интерфейса»

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

В аварийном режиме осуществляется поиск неисправностей и проведение работ по их устранению. Перевод в аварийный режим должен осуществляться при возникновении сбоев, аварий и прочих незапланированных воздействий, сразу после наступления одной или нескольких аварийных ситуаций, с последующим возвратом в штатный режим функционирования сразу после окончания восстановительных работ. ПО Модуля СЦ должно обладать надежностью, обеспечивающей работу пользователей в произвольном режиме и оперативное восстановление работоспособности при сбоях. В целях обеспечения надежного функционирования ПО должно предусматривать: – сохранение целостности данных при нештатном завершении работы компонентов Модуля СЦ; – сохранение работоспособности программного обеспечения при некорректных действиях пользователя; – резервное копирование базы данных Модуля СЦ. – время восстановления работоспособности Модуля СЦ после отказа не более 4 часов. – отказоустойчивость на уровне 99% при единовременной количестве не менее 200 пользовательских сессий в Модуле СЦ. Указанные характеристики приведены без учета характеристик надежности инфраструктуры и времени передачи информации по каналам связи. При возникновении сбоев в аппаратном обеспечении, включая аварийное отключение электропитания, Модуль СЦ должен автоматически восстанавливать свою работоспособность (не требовать перенастройки) после устранения сбоев и корректного перезапуска аппаратного обеспечения

4.2.4.1. Требования к технической реализации компонента «Интерактивная карта» При реализации компонента «Интерактивная карта» должны учитываться требования, указанные ниже. 4.2.4.1.1. Требования к отображению элементов Повторяющихся элементы карты (ТС, ОТИ, события и пр.) должны отрисовываться с использованием аппаратного создания экземпляров объектов на пользовательском устройстве (WebGL/WebGPU)). Отрисовка каждого объекта отдельным запросом не допускается, должна обеспечиваться возможность одновременного отображения не менее 5 000 объектов без снижения производительности (30 кадров в секунду на тестовой конфигурации). 4.2.4.1.2. Уровни детализации объектов Для управления отображением сложных объектов должно быть создано не менее 3-х уровней детализации, отображаемых при изменении масштаба с возможностью автоматического переключения между уровнями. Все отображаемые объекты должны масштабироваться с учетом разрешения экрана пользователя с сохранением качества детализации. 4.2.4.1.3. Полигональная оптимизация и текстурирование При реализации компонента «Интерактивная карта» должна обеспечиваться технология рельефного тестурирования объектов. Не должны использоваться высокополигональные трехмерные модели. Все повторяющиеся элементы должны генерироваться единоразово и повторно использоваться при последующих отображениях. 4.2.4.1.4. Управление памятью Требуется реализовать потоковую загрузку на устройство пользователя элементов карты и текстур. Загрузка данных целиком при старте приложения не допускается. Необходимо реализовать механизм очистки памяти от элементов, которые находятся вне области видимости камеры в течение заданного времени. 4.2.4.1.5. Требования к взаимодействию пользователя с интерфейсом компонента «Интерактивная карта» Программная реализация механизмов управление камерой (масштабирование и навигация) должна быть выполнена с поддержкой технологии WebAssembly (WASM). Элементы управления должны являться неотъемлемой частью интерактивной карты.

4.2.5. Развитие компонента администрирования (3 очередь) Должна быть выполнена доработка ролевой модели. Ролевая модель должна обеспечивать управление доступом к отдельным объектам Модуля СЦ и их элементам (атрибутам) с разграничением по видам транспорта, регионам и пр., в частности: – определение набора конкретных действий, доступных пользователям (выполняемых над объектом доступа, например, удаление записи, редактирование записи, формирование отчета и др.); – реализация возможности объединения пользователей в группы; – определение прав доступа для групп пользователей; – реализация интерфейса визуальной настройки прав доступа пользователей к объектам Модуля СЦ

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

4.5.3. Требования по диагностированию Модуля СЦ Диагностирование Модуля СЦ должно осуществляться путем анализа записей в системных журналах СУБД, операционных систем серверов, а также с помощью встроенных средств диагностирования общего программного обеспечения Модуля СЦ. Диагностированию подлежат: – сбои и нарушения функционирования технического обеспечения (серверов) Модуля СЦ; – сбои и нарушения функционирования системного программного обеспечения серверов, используемых для работы Модуля СЦ; – сбои и нарушения функционирования прикладного программного обеспечения серверов, используемых для работы Модуля СЦ; – случаи недоступности (отсутствия ответа) или некорректные ответы внешних систем; – сбои и нарушения функционирования СУБД; – сбои при выполнении регламентных операций резервного копирования. При возникновении аварийных ситуаций либо ошибок в программном обеспечении диагностические инструменты должны позволять сохранять набор информации, необходимой для идентификации и устранения проблемы. Модуль СЦ и ее компоненты должны обеспечивать возможность диагностики своей работоспособности с возможностью интеграции с модулем мониторинга АСУ ТК. Набор передаваемых журналов и метрик должен быть определен на этапе технического проектирования

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

4.2.6. Взаимосвязи с внешними автоматизированными системами (1 очередь) Способы взаимодействия с внешними информационными системами должны быть определены на этапе технического проектирования. Должны быть выполнены следующие доработки: – интеграции с информационными ресурсами в целях получения данных о движении подвижных ТС (воздушные суда, суда водного транспорта); – интеграция с информационным ресурсом в целях получения данных о событиях на железнодорожном транспорте. Реализация интеграций должна включать проектирование и реализацию интеграционных механизмов обмена данными с учетом доступных вариантов реализации, обеспечение защищенных способов взаимодействия, настройку отображения отдельных данных на карте (настройка слоев). Взаимодействия, имеющие каналы связи, выходящие за пределы контролируемой зоны взаимодействующих систем, считаются защищенными, если для их защиты используются программные и/или программно-аппаратные шифровальные (криптографические) средства, сертифицированные ФСБ России (далее – СКЗИ). Выбор СКЗИ, схемы подключения и требуемого класса криптостойкости должен производиться в соответствии с Техническими условиями на подключение к информационным ресурсам ФГБУ «СИЦ Минтранса России» и инструкциями по подключению пользователей к ресурсам инфраструктуры Головного центра обработки данных, утвержденных приказом директора ФБГУ «СИЦ Минтранса России» от 24.05.2024 № 21-ОД

4.3. Требования к оказанию услуг по технической поддержке Модуля СЦ 4.3.1. Общие требования к оказанию Услуг Техническая поддержка Модуля СЦ должна осуществляться с учетом требований постановления Правительства Российской Федерации от 06.07.2015 N 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации». Подрядчик обязан выполнять требования законодательства в сфере защиты информации, требования по защите информации, информационной безопасности, указанные в локальных нормативных актах ФГБУ «СИЦ Минтранса России», регламентирующих условия информационного взаимодействия, защиты информации и подключения к информационным ресурсам ФГБУ «СИЦ Минтранса России», участвующих в информационном взаимодействии в рамках оказания услуг по технической поддержке АСУ ТК в 2026 году

4.3.1.1. Требования к составу и содержанию услуг третьего уровня технической поддержки Оказание услуг по технической поддержке Системы осуществляется в рамках этапов в соответствии с календарным планом. Подрядчик в течение 5 рабочих дней с даты заключения Контракта должен предоставить со своей стороны, а Заказчик со своей стороны Матрицу ответственных за взаимодействия в соответствии с Приложением 1 к Регламенту оказания услуг по третьему уровню технической поддержки Модуля СЦ (далее – Регламент, Приложение В). Подрядчик в течение 10 рабочих дней с даты заключения Контракта должен провести мероприятия по организации третьего уровня технической поддержки в соответствии с Регламентом. Услуги по третьему уровню технической поддержки Модуля СЦ должны включать: – организацию Подрядчиком третьего уровня технической поддержки; – информационно-консультационную поддержку работников Заказчика; – решение инцидентов, связанных с работой ППО; – адаптационное, конфигурационное и коррекционное сопровождение Модуля СЦ (в рамках действующих программных модулей и функциональности); – устранение уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности

4.5.5. Требования к информационной безопасности Работы по защите информации/информационной безопасности, не включенные в состав настоящего раздела, требуемые в соответствии с требованиями постановления Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации», а также нормативно правовых актов в области защиты персональных данных и обеспечения безопасности объектов критической информационной инфраструктуры, будут проведены в рамках исполнения отдельного контракта, заключенного по результатам отдельной закупочной процедуры (не является частью данного ТЗ), включающего: – определение актуальных угроз безопасности информации и актуализация модели угроз безопасности информации (при необходимости); – выполнение требований о согласовании технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России в установленном порядке; – выполнение требований по устранению Подрядчиком замечаний и недостатков, в случае их выявления при согласовании Заказчиком технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России; – выполнение требований к классу защищенности ГИС, уровню защищенности персональных данных и категории значимости объекта КИИ РФ, установленных для Головного центра обработки данных ФГБУ «СИЦ Минтранса России» (далее – ГЦОД);

– определение перечня объектов защиты информационной системы; – описание (актуализированных) требований к системе защиты информации, а также к мерам защиты информации информационной системы в зависимости от установленных классов защищенности, уровня защищенности персональных данных и категории значимости объектов КИИ РФ (приказы ФСТЭК России № 21, 117, 239); – выполнение требований к мерам по защите ГИС от атак, направленных на отказ в обслуживании, в соответствии с пунктами 30, 34, 59, 63 Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений, утвержденных приказом ФСТЭК России от 11.04.2025 № 117; – описание (актуализированных) требований по защите информации, подлежащих реализации в информационно телекоммуникационной инфраструктуре ГЦОД; – выполнение требований о применении сертифицированных средств защиты информации, включая их классы защиты и уровни доверия; – выполнение требований о запрете использования с 01.01.2025 органами (организациями) средств защиты информации странами происхождения, которых являются иностранные государства в соответствии с пунктом 6 Указа Президента Российской Федерации от 01.05.2022 № 250; – выполнение требований по обеспечению непрерывного взаимодействия с ГосСОПКА в установленном порядке;

5. СОСТАВ И СОДЕРЖАНИЕ РАБОТ ПО РАЗВИТИЮ И ТЕХНИЧЕСКОЙ ПОДДЕРЖКЕ МОДУЛЯ СЦ (КАЛЕНДАРНЫЙ ПЛАН) - Сдача-приемка результатов выполненных работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная техническая документация, а также результаты работ предоставляются Заказчику в порядке, предусмотренном Контрактом и ТЗ, до размещения Подрядчиком в ЕИС документа о приемке. Документ о приемке размещается в ЕИС по каждому этапу в соответствии с условиями Контракта. Этапы выполнения работ по развитию Модуля СЦ приведены в Таблице 11. Таблица 11. Этапы выполнения работ по развитию Модуля СЦ. № этапа Наименование этапа Результат (отчетная документация) Срок исполнения этапа - - Значение характеристики не может изменяться участником закупки

1 Техническое проектирование Сопроводительным письмом предоставляются Заказчику: · Технический проект, включая следующие документы: – Ведомость технического проекта; – Ведомость машинных носителей информации – Пояснительная записка; – Описание информационного обеспечения системы; – Описание автоматизируемых функций; – Схема функциональной структуры; – Описание организации информационной базы; – Описание программного обеспечения; · Макеты экранных форм компонента «Интерактивная карта»; · Руководство по безопасной разработке программного обеспечения; · Документ о приемке Начало: с даты заключения контракта Окончание: не позднее 31.07.2026

2 Услуги по технической поддержке Модуля СЦ (с даты заключения контракта по 10.09.2026) По окончании оказания Услуг сопроводительным письмом предоставляются Заказчику: – Отчет об оказанных Услугах по технической поддержке; – Актуальные на дату окончания оказания Услуг по данному этапу исходные коды прикладного ПО на электронном носителе (в случае внесения изменений); – Инструкция по сборке и развертыванию (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство пользователя (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство администратора (в случае внесения изменений); – Документ о приемке Начало: с даты заключения контракта Окончание: не позднее 10.09.2026

3 Разработка программного обеспечения (1 очередь, пп. 4.2.1, 4.2.6 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ; – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 1 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 1 очереди; – Руководство по резервному копированию; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 16.09.2026

4 Разработка программного обеспечения (2 очередь, пп. 4.2.3, 4.2.4 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ. – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 2 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 2 очереди; – Руководство по резервному копированию; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 25.09.2026

5 Разработка программного обеспечения (3 очередь, пп. 4.2.2, 4.2.5 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ; – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 3 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 3 очереди; – Руководство по резервному копированию; – Описание ролевой модели; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 09.10.2026

6 Опытная эксплуатация (1 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акт о завершении опытной эксплуатации 1 очереди; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке 17.09.2026 Окончание: не позднее 26.10.2026

7 Опытная эксплуатация (2 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акт о завершении опытной эксплуатации 2 очереди; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке 26.09.2026 Окончание: не позднее 26.10.2026

8 Опытная эксплуатация (3 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Акт о завершении опытной эксплуатации 3 очереди; – Документ о приемке Начало: с 10.10.2026 Окончание: не позднее 26.10.2026

9 Приемочные испытания Сопроводительным письмом предоставляются Заказчику: – Программа и методика приёмочных испытаний; – Протокол приемочных испытаний; – Исходные коды и дистрибутивы на электронном носителе (при условии внесения изменений, с учетом доработок по результатам опытной эксплуатации и проведенных испытаний); – Комплект рабочей документации на Модуль СЦ (при условии внесения изменений, с учетом доработок по результатам опытной эксплуатации и проведенных испытаний); – Акт приемки Системы в эксплуатацию; – Акт приемки-передачи исключительных прав на объект; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке; – Документы в соответствии с разделом 4.5.9 ТЗ; – Обеспечение гарантийных обязательств Начало: с 27.10.2026 Окончание: не позднее 10.11.2026

10 Услуги по технической поддержке Модуля СЦ (с 11.09.2026 по 15.12.2026) По окончании оказания Услуг сопроводительным письмом предоставляются Заказчику: – Отчет об оказанных Услугах по технической поддержке; – Актуальные на дату окончания оказания Услуг по данному этапу исходные коды прикладного ПО на электронном носителе (в случае внесения изменений); – Инструкция по сборке и развертыванию (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство пользователя (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство администратора (в случае внесения изменений); – Документ о приемке Начало: с 11.09.2026 Окончание: не позднее 15.12.2026

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

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

6.1. Сведения о гарантийном обслуживании Модуля СЦ Под гарантией понимается устранение Подрядчиком своими силами и за свой счет допущенных по его вине недостатков, выявленных после приемки выполненных Работ, как в работе самой Модуля СЦ, так и недостатков в отчетной документации. Если в период гарантийного срока обнаружатся недостатки, то Подрядчик обязан устранить их за свой счет, в сроки, установленные Заказчиком. Гарантийный срок в этом случае продлевается на период устранения недостатков. Срок гарантии: 1 год с даты приемки Заказчиком результатов исполнения Этапа № 9 контракта. Подрядчиком должны быть внесены соответствующие исправления в техническую и рабочую документацию (указанную в пунктах 5 и 6 настоящего ТЗ), связанные с устранением замечаний к работе Модуля СЦ или в случае выявления Заказчиком недостатков в такой документации в период гарантийного срока. Внесение изменений в документацию технического и рабочего проектирования осуществляется в соответствии с ГОСТ 2.503-2023 и ГОСТ Р 2.504-2021.

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

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

8. ТРЕБОВАНИЯ К СОСТАВУ И СОДЕРЖАНИЮ РАБОТ ПО ПОДГОТОВКЕ МОДУЛЯ СЦ К ВВОДУ В ЭКСПЛУАТАЦИЮ - По результатам проведения приемочных испытаний оформляется Протокол приемочных испытаний и Акт приемки в эксплуатацию. В случае, если взаимодействие с внешними системами не может быть проверено на средах постоянной эксплуатации взаимодействующих систем (по причине неготовности со стороны внешней системы или иным причинам), функции взаимодействия, разработанные в соответствии с требованиями ТЗ, должны быть проверены на тестовых данных с использованием программ-имитаторов взаимодействия. По результатам выполнения этапа приемочных испытаний должны быть подготовлены материалы для регистрации доработанной версии Модуля СЦ (объекта учета) в НФАП в соответствии с требованиями постановления Правительства Российской Федерации от 30 января 2013?г. №?62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин» (с изменениями и дополнениями) в части обязательности размещения результатов работ в национальном фонде алгоритмов и программ для электронных вычислительных машин. Сдача-приемка результатов выполнения Работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная, техническая документация, а также программное обеспечение предоставляется Заказчику в порядке, предусмотренном Контрактом и ТЗ до размещения Подрядчиком в Единой информационной системе в сфере закупок документа о приемке. Результаты проведения опытной эксплуатации, предварительных и приемочных испытаний должны быть зафиксированы в соответствующих протоколах и актах. Выявленные отклонения от настоящего ТЗ, оформляются как недостатки Модуля СЦ - - Значение характеристики не может изменяться участником закупки

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

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

9. ТРЕБОВАНИЯ К ДОКУМЕНТИРОВАНИЮ - 9.1. Общие требования Документация на Модуль СЦ должна быть разработана в составе, указанном в разделах 5-8 данного ТЗ, и должна удовлетворять требованиям комплекса стандартов и руководящих документов на автоматизированные системы: – ГОСТ Р 2.105-2019 в части оформления текстовых документов; – ГОСТ 34.201-2020 в части наименования и обозначения документов. Документация на Модуль СЦ должны оформляться на листах формата А4. Допускается для размещения рисунков и таблиц использование листов формата А3 с подшивкой по короткой стороне листа. Документы объемом более 25 (двадцати пяти) листов должны содержать информационную часть, состоящую из аннотации и содержания. Исходные коды должны быть представлены в 1 (одном) экземпляре на электронном носителе, отчетные материалы должны быть представлены в 2 (двух) экземплярах на бумажном носителе (по одному экземпляру для Заказчика и Подрядчика) и в 1 (одном) экземпляре на электронном носителе в формате документов DOCX и PDF. При разработке документов на Модуль СЦ допускается отклонение от требований комплекса стандартов, описанных выше. Документам на Модуль СЦ должны в обязательном порядке присваиваться уникальные децимальные номера в соответствии с порядком, установленном в ГОСТ 34.201-2020. Документ «Программа и методика предварительных испытаний» должен включать приложения с формой протокола предварительных испытаний и формой акта приемки в опытную эксплуатацию. Документ «Программа опытной эксплуатации» должен включать приложение с формой журнала опытной эксплуатации. Документ «Программа и методика приемочных испытаний» должен включать приложения с формой протокола приемочных испытаний и формой акта приемки в эксплуатацию - - Значение характеристики не может изменяться участником закупки

10. ИСТОЧНИКИ РАЗРАБОТКИ - 10.1. Список литературы Специальная литература для разработки ТЗ не использовалась. 10.2. Нормативно-методические документы Список используемых нормативно-методических документов представлен в разделе 1.6 технического задания. ? Приложение А Эскизы визуального оформления компонента «Интерактивная карта» - - Значение характеристики не может изменяться участником закупки

Приложение Б Параметры оказания услуг - Б.1. Базовые параметры оказания Услуг Базовые параметры оказания Услуг приведены ниже: – режимы оказания Услуг (таблица Б.1.1); – сроки предоставления отчетности (таблица Б.1.2). Таблица Б.1.1 - Режимы оказания Услуг № п/п Параметр Значение - - Значение характеристики не может изменяться участником закупки

1 Режим работы Системы Круглосуточно (24х7) 2 Режим доступности информационно-консультационной поддержки пользователей Системы 2.1 Прием и регистрация обращений (заявок) в СРО Регистрация обращений (заявок) производится круглосуточно в режиме 24х7, без праздников и выходных дней. Обработка заявок первой линией поддержки осуществляется в рабочие дни с 9 до 18 часов 2.2 Консультирование сотрудников Заказчика и пользователей Системы в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 3 Режим доступности по решению инцидентов, связанных с работой ППО: 3.1 - приоритет «Критический» Круглосуточно (24х7) 3.2 - приоритет «Высокий» Круглосуточно (24х7) 3.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 3.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4 Режим доступности услуг по адаптации, конфигурации и коррекционному сопровождению Системы 4.1 - приоритет «Критический» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.2 - приоритет «Высокий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 5 Режим доступности по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности 5.1 - приоритет «Критический» Круглосуточно (24х7) 5.2 - приоритет «Высокий» Круглосуточно (24х7) 5.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 5.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням)

Таблица Б.1.2. Сроки предоставления отчетности, с момента получения запроса № п/п Параметр Значение 1 Предоставление отчета об оказанных услугах за произвольный период 10 рабочих дней 2 Предоставление подробной информации по инциденту с приоритетом «Критический» 16 рабочих часов 3 Предоставление актуализированной документации 10 рабочих дней

Б.2. Приоритеты и регламентные сроки решения обращений (заявок) В зависимости от уровня сбоя в работе Системы обращению (заявке) присваивается один из следующих приоритетов, а также в зависимости от приоритета обращения (заявки) устанавливаются следующие контрольные сроки решения в соответствии с таблицей ниже (Таблица Б.2.1). Таблица Б.2.1 – Приоритеты и регламентные сроки решения обращений (заявок) № п/п Приоритет Максимальное время реагирования Время решения (срок выполнения) Описание приоритета По информационно-консультационной поддержке сотрудников Заказчика и пользователей Системы 1 - не более 1 часа не более 10 часов - По решению инцидентов, связанных с работой ППО: 1 Критический не более 30 минут не более 4 часов - полная недоступность ППО; - недоступность ключевых функций - ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО; - невозможность информационного обмена с ППО для ИС более 4 часов 2 Высокий не более 1 часа не более 8 часов - ошибки/сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; - снижение быстродействия СПО (время отклика ППО на операции превышает 30 секунд); - недоступность управления правами и ролями пользователей 3 Средний не более 4 часов не более 24 часов - невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым -недоступность функции формирования отчетов 4 Низкий не более 8 часов не более 40 часов - отклонение в работе ППО, не влияющее на корректную работу функций; - другие сбои и ошибки, затрагивающие основные функции ППО

По адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) 1 Критический не более 40 минут не более 8 часов - изменения, необходимые при проведении аварийно-восстановительных работ для возобновления работоспособности Системы; - изменения, связанные с критичными ошибками, блокирующими возможность оказания государственных услуг и/или чтение и внесение данных в Систему 2 Высокий не более 1 часа не более 40 часов - изменения, относящиеся к обеспечению работоспособности основной функциональности Системы, устраняют выявленные дефекты в работе Системы, оказывающие существенное влияние на работу пользователей в Системе; - изменения, затрагивающие три и более подсистемы/модуля Системы для адаптации 3 Средний не более 4 часов не более 72 часов - изменения, связанные с развитием/улучшением/оптимизацией Системы и выводом новой функциональности в штатном режиме для одного-двух модулей/подсистем; - изменения, связанные с развитием интеграционных механизмов Системы, например обновление существующих и/или реализация новых видов сведений СМЭВ, обновление существующих и/или реализация новых API, адаптация и/или изменение механизмов импорта и экспорта данных Системы и т.д. 4 Низкий не более 8 часов не более 160 часов - изменения, связанные с ошибками/корректировкой/изменением в отображении информации в пользовательском графическом интерфейсе Системы (графика, текст, органы управления, элементы интерфейса)

По устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности 1 Критический не более 30 минут не более 24 часов - критические уязвимости, влияющие на возможную полную недоступность ППО, ключевых функций Системы, ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО без возможности восстановления работоспособности Системы. - Критический уровень CVSS > 8.0 2 Высокий не более 1 часа не более 84 часов - критические уязвимости, влияющие на ошибки и сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО. - Высокий уровень CVSS 5.0 - 8.0 3 Средний не более 4 часов не более 120 часов - уязвимости, влияющие на невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым - Средний уровень CVSS 2.0 - 4.9 4 Низкий не более 8 часов не более 160 часов - уязвимости, влияющие на отклонение в работе ППО, не влияющее на корректную работу функций; - другие сбои и ошибки, затрагивающие основные функции ППО - Низкий уровень CVSS < 2.0

Взаимодействие Заказчика и Подрядчика в части регистрации и контроля времени реагирования и решения обращения (заявки) осуществляется через СРО. Заказчик предоставляет Подрядчику доступ к СРО после заключения Контракта. Поступившие от разных пользователей заявки по поводу однотипных инцидентов или имеющие общую причину должны объединяться в одну заявку. Срок выполнения включает время диагностики инцидента, в ходе которого определяется причина инцидента (проблемы) и способ его устранения. Подрядчик должен обеспечить функционирование Модуля СЦ в соответствии с требованиями и параметрами, указанными в настоящем ТЗ и Регламенте оказании услуг. Основные параметры быстродействия типовых операций в Модуле СЦ указаны в таблице ниже (таблица Б.2.2). Таблица Б.2.2 - Параметры быстродействия Модуля СЦ № п/п Наименование параметра Значение (секунд) 1 Среднее время получения сообщения из очереди сообщений 10 2 Среднее время получения ответа от Системы 5 3 Среднее время открытия карточки реестра 5

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

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

Уровень технической поддержки Организационно-структурная часть технической поддержки, имеющая определённые организационно-нормативными документами зоны ответственности, обязанности, а также временные нормативы, в течение которых эти обязательства должны выполняться либо эскалироваться на следующий уровень технической поддержки Услуги Услуги по технической поддержке Информационно-аналитической системы регулирования на транспорте АСУ ТК ФИО Фамилия, имя, отчество Эскалация Процедура повышения внимания к обращению (заявке) путем повышения его приоритета и/или передачи на следующий уровень технической поддержки, а также привлечение ролей, которые могут принимать решения без передачи на следующий уровень технической поддержки API Англ. Application Programming Interface — программный интерфейс приложения, интерфейс прикладного программирования — описание способов (набор классов, процедур, функций, структур или констант), которыми одна компьютерная программа может взаимодействовать с другой программой

CVSS Англ. Common Vulnerability Scoring System - открытый стандарт, используемый для расчета количественных оценок уязвимости в безопасности компьютерной системы, обычно с целью понять приоритет ее исправления. В современном инструментарии информационной безопасности используется версия 3.0 и выше с дополнительными метриками к базовым оценкам ID Англ. Identifier – идентификатор, уникальный признак объекта, позволяющий отличать его от других объектов, то есть, идентифицировать SLA Англ. Service Level Agreement - утвержденные условия по обработке обращения (заявки) с установленными метриками времени, которые определяют пороговые значения для эскалации в зависимости от статуса обращения (заявки) (например, время реакции – время от регистрации до осуществления первичной обработки, время решения – время от регистрации обращения (заявки) до его решения и т.д.) SQL Англ. Structured Query Language — «язык структурированных запросов», — декларативный язык программирования, применяемый для создания, модификации и управления данными в реляционной базе данных, управляемой соответствующей СУБД

1 Общие сведения 1.1 Полное наименование Услуг Оказание услуг по технической поддержке Модуля СЦ АСУ ТК в 2026 году. 1.2 Предмет Регламента оказания услуг Требования Технического задания

2 Общие положения 2.1 Цель и задачи оказания услуг Целью технической поддержки Системы является обеспечение ее стабильного и безопасного функционирования и эксплуатации, предупреждение, выявление и устранение сбоев в работе Системы и минимизация их неблагоприятного влияния. Для достижения поставленной цели требуется решение следующих задач: 1. Обеспечение информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы. 2. Поддержание параметров функционирования ППО Системы, удовлетворяющих требованиям производственных процессов, включая их непрерывность. 3. Обеспечение бесперебойного функционирования ППО и своевременное устранение сбоев и аварийных ситуаций в Системе. 4. Своевременное устранение уязвимостей при выявлении таковых, в соответствии с требованиями к обеспечению информационной безопасности. 5. Адаптация, конфигурирование, коррекция программного обеспечения в соответствии с изменениями нормативно-правовой базы и запросами уполномоченных сотрудников органов государственной власти, включая выполнение процедур тестирования и участие в обновлениях ППО на стендах Заказчика. 6. Обеспечение сохранения работоспособности ППО в изменяемой среде эксплуатации. 7. Ведение документации по настоящему контракту и инициирование актуализации документации на Систему по результатам обработки запросов Заказчика и внесения соответствующих изменений в ППО

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

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

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

Таблица 1 - Типы обращений (заявок) Тип обращения (заявки) Описание Запрос на обслуживание Подготовка SQL запроса к СУБД для решения прикладной задачи и д р. – запрос на любое действие, не являющееся запросом информации и несовершенный на основе происшествия, прямо или косвенно влияющего на работу Системы Консультация (входит в тип обращения (заявки) «Запрос на обслуживание») «Где взять / куда обратиться...?», «Как сделать / выполнить…», «Как это работает…?» - запрос, имеющий своей целью получение информационной поддержки Инцидент Разбор ошибок/сбоев и подготовка материалов (корректировочных релизов, инструкций) для Заказчика для устранения ошибок/сбоев, которые приводят к частичному и полному нарушению работоспособности всех или отдельных функций ППО. Подготовка изменения и материалов, необходимых для проведения аварийно-восстановительных работ для возобновления работоспособности Системы. ЗНИ Подготовка изменений, связанных с изменением, улучшением/оптимизацией Системы и выводом новой модифицированной функциональности в штатном режиме. Подготовка изменений, связанных с модификацией существующих и/или реализация новых интеграционных механизмов для получения/обработки данных внешних систем. Подготовка изменений графического интерфейса по требованиям Заказчика

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

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

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

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

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

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

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

3.4.1 Инцидент На рисунке 2 представлена функциональная схема регистрации и сопровождения обращений (заявок) типа «Инцидент». Рисунок 2 - Функциональная схема регистрации и сопровождения обращений (заявок) типа «Инцидент» 3.4.2 Запрос на обслуживание На рисунке 3 представлена функциональная схема регистрации и сопровождения обращения (заявки) типа «ЗНО». Рисунок 3 - Функциональная схема регистрации и сопровождения обращения (заявки) типа «ЗНО» 3.4.3 Запрос на изменение На рисунке 4 представлена функциональная схема регистрации и сопровождения обращений (заявок) типа «ЗНИ». Рисунок 4 - Функциональная схема регистрации и сопровождения обращений (заявок) типа «ЗНИ»

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

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

4 Формы обращений (заявок) на оказание услуг по технической поддержке Системы, заполняемые в СРО 4.1. Форма обращения (заявки) на оказание услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы При подаче обращения (заявки) типа «ЗНО» в СРО указывается (Таблица 5): Таблица 5 – Описание атрибутов формы обращения (заявки) на оказание услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 5) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 5) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 5) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 5) Категория обращения: информационно-консультационная поддержка Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 5) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 5) Текст запроса на оказание услуги по информационно-консультационной поддержке сотрудников Заказчика Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 5)

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

4.2. Форма обращения (заявки) на оказание услуги по решению инцидентов, связанных с работой ППО При подаче обращения (заявки) типа «Инцидент» в СРО указывается (Таблица 6): Таблица 6 – Описание атрибутов формы обращения (заявки) на оказание услуги по решению инцидентов, связанных с работой ППО Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 6) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 6) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 6,) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 6) Категория обращения (заявки): инцидент Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 6) Приоритет изменения Время - одно из значений: Низкий, Средний, Высокий или Критический. Определяет, очередность решения обращения (заявки), ресурсы, привлекаемые для решения обращения (заявки), порядок/процедура действий при решении обращения (заявки) – поле СРО «Приоритет» (см. рисунок 6,)

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

На рисунке 6 приведена форма обращения (заявки) типа «Инцидент» в СРО. Рисунок 6 - Форма обращения (заявки) типа «Инцидент» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуги по решению инцидентов, связанных с работой ППО, заполненную в свободной форме

4.3. Форма обращения (заявки) на оказание услуг по адаптационному конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) При подаче обращения (заявки) типа «ЗНИ» в СРО указывается (Таблица 7): Таблица 7 – Описание атрибутов формы обращения (заявки) на оказание услуг по адаптационному, конфигурационному и коррекционному сопровождению Системы Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 10) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 9) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 10) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 10) Категория обращения (заявки): запрос на изменение Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 7) Приоритет изменения Время, очередность решения обращения (заявки), ресурсы, привлекаемые для решения обращения (заявки), порядок/процедура действий при решении обращения (заявки) – поле СРО «Приоритет» (см. рисунок 7) Тип изменения Справочник, классифицирующий типовые запросы характерные для Системы – поле СРО «Предмет обращения» (см. рисунок 7) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 7) Текст запроса на оказание услуги по адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 7)

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

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

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

На рисунке 8 приведена форма обращения (заявки) типа «Инцидент» в СРО. Рисунок 8 - Форма обращения (заявки) типа «Инцидент» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуги по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности, заполненную в свободной форме

Приложение 1 к Регламенту Матрица ответственных за взаимодействия в рамках выполнения работ по техническому сопровождению Системы Таблица 1 – Ответственные за взаимодействия в рамках выполнения работ по техническому сопровождению Системы со стороны Исполнителя ФИО Должность Адрес электронной почты Телефон — — — Общий контакт

Приложение 2 к Регламенту Приоритеты и регламентные сроки решения обращений (заявок) Приоритеты и регламентные сроки решения обращений (заявок) приведены в таблице 1. Таблица 1 – Приоритеты и регламентные сроки решения обращений (заявок) № п/п Приоритет Максимальное время реагирования Время решения (срок выполнения) Описание приоритета

По информационно-консультационной поддержке сотрудников Заказчика и пользователей Системы 1 – не более 1 часа не более 10 часов –

По решению инцидентов, связанных с работой ППО 1 Критический не более 30 минут не более 4 часов – полная недоступность ППО; – недоступность ключевых функций; – ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО; – невозможность информационного обмена с ППО для ИС более 4 часов 2 Высокий не более 1 часа не более 8 часов – ошибки/сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; – снижение быстродействия СПО (время отклика ППО на операции превышает 30 секунд); – невозможность управления правами и ролями пользователей 3 Средний не более 4 часов не более 24 часов – невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым недоступность функции формирования отчетов 4 Низкий не более 8 часов не более 40 часов – отклонение в работе ППО, не влияющее на корректную работу функций; – другие сбои и ошибки, затрагивающие основные функции ППО

По адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) 1 Критический не более 40 минут не более 8 часов – изменения необходимые при проведении аварийно-восстановительных работ для возобновления работоспособности Системы; – изменения, связанные с критичными ошибками, блокирующими возможность оказания государственных услуг и/или чтение и внесение данных в Систему 2 Высокий не более 1 часа не более 40 часов – изменения относящиеся к обеспечению работоспособности основной функциональности Системы, устраняют выявленные дефекты в работе Системы, оказывающие существенное влияние на процесс оказания государственных услуг и работу пользователей в Системе; – изменения, затрагивающие три и более подсистемы/модуля Системы для адаптации 3 Средний не более 4 часов не более 72 часов – изменения, связанные с развитием/улучшением/оптимизацией Системы и выводом новой функциональности в штатном режиме для одного-двух модулей/подсистем; – изменения, связанные с развитием интеграционных механизмов Системы, например, обновление существующих и/или реализация новых видов сведений СМЭВ, обновление существующих и/или реализация новых API, адаптация и/или изменение механизмов импорта и экспорта данных Системы и т.д. 4 Низкий не более 8 часов не более 160 часов – изменения, связанные с ошибками/ корректировкой/изменение в отображении информации в пользовательском графическом интерфейсе Системы (графика, текст, органы управления, элементы интерфейса)

По устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности 1 Критический не более 30 минут не более 24 часов – критические уязвимости, влияющие на возможную полную недоступность ППО, ключевых функций Системы, ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО без возможности восстановления работоспособности Системы; – Критический уровень CVSS > 8.0 2 Высокий не более 1 часа не более 84 часов – критические уязвимости, влияющие на ошибки и сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; – Высокий уровень CVSS 5.0 - 8.0 3 Средний не более 4 часов не более 120 часов – уязвимости, влияющие на невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым; – Средний уровень CVSS 2.0 - 4.9 4 Низкий не более 8 часов не более 160 часов – уязвимости, влияющие на отклонение в работе ППО, не влияющее на корректную работу функций; – другие сбои и ошибки, затрагивающие основные функции ППО; – Низкий уровень CVSS < 2.0

Приложение Г Форма Отчета об оказанных услугах Отчет об оказанных услугах за этап «наименование этапа» в период с «__» _________ по «__» _________. № п/п Наименование услуги Общее количество Номер ОРС Краткое Описание Время реагирования по ТЗ Время реагирования фактическое Время решения по ТЗ Время решения фактическое Результат соблюдения времени реагирования Результат соблюдения времени решения Примечание 1 Услуги по информационно-консультационной поддержке работников Заказчика 2 546782 Консультация по работе Модуля СЦ 1 2 10 часов 11 часов Нет Нет 567123 Консультация по схеме БД 1 1 10 часов 1 час Да Да 2 … … Заказчик Подрядчик /Должность/ /Должность/ ____________________ /Ф.И.О/ ___________________ /Ф.И.О/ М.П. М.П. «_____»_______________________202_г. «_____»_______________________202_г

Приложение 1 к Отчету об оказанных услугах Журнал обращений (заявок) на оказание услуги по информационно-консультационной поддержке пользователей Системы (шаблон) Наименование Исполнителя в этапе «наименование этапа» в период с ________________ по _______________ оказал(о) Услугу по поддержке пользователей Системы в объеме, указанном в Таблице 1 Таблица 1 - Журнал обращений (заявок) пользователей Системы № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. ИТОГО зарегистрировано: Всего обращений (заявок): ________ ИТОГО решено: Всего обращений (заявок): ________

Приложение 2 к Отчету об оказанных услугах Журнал обращений (заявок) по решению инцидентов, связанных с работой ППО (шаблон) Наименование Исполнителя в этапе «наименование этапа» в период с ________________ по _______________ оказал(о) Услугу по решению инцидентов в объеме, указанном в Таблице 1. Таблица 1 - Журнал по решению инцидентов № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. ИТОГО зарегистрировано: Всего инцидентов: ________ ИТОГО решено: Всего инцидентов: ________

Приложение 3 к Отчету об оказанных услугах Журнал обращений (заявок) выполнения адаптационного, конфигурационного и коррекционного сопровождения Системы (шаблон) Журнал выполнения адаптации, конфигурации и коррекции Системы сформирован за этап «наименование этапа» в период с «__» _________ по «__» ____________ и представлен в таблице ниже (Таблица 1). Таблица 1 - Журнал выполнения адаптации, конфигурации и коррекции сопровождения Системы № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. Количество выполненных заявок за этап: ________

Приложение 4 к Отчету об оказанных услугах Журнал обращений (заявок) по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности (шаблон) Журнал обращений (заявок) по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности сформирован за этап «наименование этапа» в период с «__» _________ по «__» ____________ и представлен в таблице ниже (Таблица 1). Таблица 1 - Журнал выполнения заявок по устранению уязвимостей в ППО № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. Количество выполненных заявок за этап: ________

Приложение Д Форма Протокола проверки результатов организационно-штатных и подготовительных мероприятий (шаблон) Протокол проверки результатов организационно-штатных и подготовительных мероприятий Настоящий Протокол содержит результаты проверки организационно-штатных и подготовительных мероприятий, проведенных Исполнителем (Таблица Д.1). Таблица Д.1. Протокол проверки результатов № Мероприятия Подготовительного этапа Результат проверки 1. Определить и направить Заказчику документ «Ответственные за взаимодействия в рамках выполнения работ по техническому сопровождению Системы со стороны Исполнителя». Документ содержит контактную информацию (ФИО, должность, адрес электронной рабочей почты, номер телефона) не менее чем о 2 лицах, ответственных за оказание услуг со стороны Подрядчика Выполнено/Не выполнено 2. Обеспечить подключение специалистов Подрядчика к Системе Выполнено/Не выполнено 3. Обеспечить подключение специалистов Подрядчика к СРО Выполнено/Не выполнено Заказчик Подрядчик /Должность/ /Должность/ ____________________ /Ф.И.О/ ___________________ /Ф.И.О/ М.П. М.П. «_____»_______________________202_г. «_____»_______________________202_г

- 62.02.30.000 - Этап№10: Услуги по технической поддержке Модуля СЦ (с 11.09.2026 по 15.12.2026) ОКПД2: 62.02.30.000 ОПРЕДЕЛЕНИЯ, ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ Автоматизированная система (АС) Система, состоящая из комплекса средств автоматизации, реализующего информационную технологию выполнения установленных функций, и персонала, обеспечивающего его функционирование (ГОСТ Р 59853-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения») АРМ Автоматизированное рабочее место АСУ ТК, Система Информационно-аналитическая система регулирования на транспорте АТС Автоматическая телефонная станция БД База данных ГИС Государственная информационная система ГОСТ Государственный стандарт ГЦОД СИЦ Минтранса России, ГЦОД Головной центр обработки данных ФГБУ «СИЦ Минтранса России» Дашборд Интерактивная аналитическая панель, графический интерфейс. ЕИС Единая информационная система в сфере закупок ЕСИА Единая система идентификации и аутентификации Заказчик Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» КИИ Критическая информационная инфраструктура Кластер Кла?стер (англ. cluster) – объединение нескольких однородных элементов, которое может рассматриваться как самостоятельная единица, обладающая определёнными свойствами Компонент Часть АС, выделенная по определенному признаку или совокупности признаков и рассматриваемая как единое целое (ГОСТ Р 59853-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения») Контракт Контракт на выполнение работ по развитию и оказанию услуг по технической поддержке Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК в 2026 году, заключаемый по результатам проведения конкурентной процедуры закупки в соответствии с требованиями Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» ... 1. ОБЩИЕ СВЕДЕНИЯ – постановление Правительства Российской Федерации от 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 Федерального закона «Об электронной подписи»; ... 2. ЦЕЛИ И НАЗНАЧЕНИЕ ВЫПОЛНЕНИЯ РАБОТ 2.1. Назначение АСУ ТК АСУ ТК предназначена для автоматизации и информационно-аналитического обеспечения процессов управления развитием транспортного комплекса Российской Федерации, обеспечения публичности деятельности органов государственного управления транспортным комплексом. Основными целями АСУ ТК являются: – повышение эффективности процессов управления функционированием и развитием транспортного комплекса на основе создания единой информационной среды и комплекса информационно-аналитических услуг на уровне органов государственного управления ТК; – повышение уровня безопасности ТК на базе получения полной, достоверной и оперативной информации о происходящих изменениях, своевременного выявления негативных тенденций и для принятия соответствующих мер по их устранению и ликвидации последствий ... - Условная единица - 1,00 - 14 876 618,94 - 14 876 618,94

- Наименование характеристики Значение характеристики Единица измерения характеристики Инструкция по заполнению характеристик в заявке ОПРЕДЕЛЕНИЯ, ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ Автоматизированная система (АС) Система, состоящая из комплекса средств автоматизации, реализующего информационную технологию выполнения установленных функций, и персонала, обеспечивающего его функционирование (ГОСТ Р 59853-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения») АРМ Автоматизированное рабочее место АСУ ТК, Система Информационно-аналитическая система регулирования на транспорте АТС Автоматическая телефонная станция БД База данных ГИС Государственная информационная система ГОСТ Государственный стандарт ГЦОД СИЦ Минтранса России, ГЦОД Головной центр обработки данных ФГБУ «СИЦ Минтранса России» Дашборд Интерактивная аналитическая панель, графический интерфейс. ЕИС Единая информационная система в сфере закупок ЕСИА Единая система идентификации и аутентификации Заказчик Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» КИИ Критическая информационная инфраструктура Кластер Кла?стер (англ. cluster) – объединение нескольких однородных элементов, которое может рассматриваться как самостоятельная единица, обладающая определёнными свойствами Компонент Часть АС, выделенная по определенному признаку или совокупности признаков и рассматриваемая как единое целое (ГОСТ Р 59853-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения») Контракт Контракт на выполнение работ по развитию и оказанию услуг по технической поддержке Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК в 2026 году, заключаемый по результатам проведения конкурентной процедуры закупки в соответствии с требованиями Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» Значение характеристики не может изменяться участником закупки Модуль iМинтранс Модуль сбора данных и представления показателей деятельности Министерства транспорта Российской Федерации iМинтранс АСУ ТК Модуль СЦ Модуль сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК НС Нештатная ситуация НСИ Нормативно-справочная информация ОТИ Объект транспортной инфраструктуры П-ГИС Геоинформационная подсистема П-ИВ Подсистема информационного взаимодействия П-НСИ Подсистема ведения нормативно-справочной информации и метаданных ПО Программное обеспечение Подрядчик, Исполнитель Организация, с которой будет заключен контракт на выполнение работ по развитию Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК П-СД Подсистема сбора данных Работы Работы по развитию Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК СЗИ Средство защиты информации СМЭВ Система межведомственного электронного взаимодействия СУБД Система управления базами данных ТЗ Техническое задание (настоящий документ) ТС Транспортное средство ТК Транспортный комплекс Учреждение Учреждения в области информационной безопасности ФГБУ «СИЦ Минтранса России» Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации», Заказчик Федеральный закон № 44-ФЗ Федеральный закон от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» ФЗ Функциональная задача ФЗ «Реестр объектов» Функциональная задача «Формирование и ведение единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации» ФСБ России Федеральная служба безопасности Российской Федерации ФСТЭК России Федеральная служба по техническому и экспортному контролю ЧС Чрезвычайная ситуация ЭВМ Электронно-вычислительная машина API От англ. Application Programming Interface – интерфейс прикладного программирования – совокупность инструментов и функций в виде интерфейса для взаимодействия с программой CSS От англ. Cascading Style Sheets — каскадные таблицы стилей FPS От англ. frame per second - количество кадров в секунду HTML От англ. HyperText Markup Language - стандартный язык разметки документов, создающий основу и структуру всех веб-страниц JSON От англ. JavaScript Object Notation – текстовый формат обмена данными, основанный на JavaScript WebAssembly (Wasm) Открытый стандарт, представляющий собой низкоуровневый бинарный формат инструкций, который позволяет выполнять код, написанный на языках C++, Rust или Go, в браузерах с производительностью, близкой к нативной 1. ОБЩИЕ СВЕДЕНИЯ – постановление Правительства Российской Федерации от 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 Федерального закона «Об электронной подписи»; Значение характеристики не может изменяться участником закупки – постановление Правительства Российской Федерации от 08.06.2011 № 451 «Об инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг и исполнения государственных и муниципальных функций в электронной форме»; – постановление Правительства Российской Федерации от 30.01.2013 № 62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин»; – приказ ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации»; – приказ ФСТЭК России от 11.04.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений»; – приказ ФСБ России от 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.7. Сроки начала и окончания работ Начало работ: с даты заключения Контракта. Окончание работ: не позднее 15.12.2026. Работы выполняются в соответствии с этапами. Сроки выполнения этапов работ по развитию и технической поддержке Модуля СЦ определяются Календарным планом. Календарный план, приведен в разделе 5 настоящего ТЗ 1.8. Общие сведения об источниках и порядке финансирования работ Источником финансирования являются средства субсидии федерального бюджета Российской Федерации, предоставленной в соответствии с абзацем вторым пункта 1 статьи 78.1 Бюджетного кодекса Российской Федерации (код цели 08-01) 1.9. Порядок оформления и предъявления результатов работ Подрядчик должен передать Заказчику результаты работ в порядке, определенном Контрактом в сроки, установленные п. 5 настоящего ТЗ, в соответствии с Календарным планом 1.10. Место выполнения Работ Работы выполняются удаленно на комплексе технических средств Заказчика. Адрес размещения комплекса технических средств Заказчика: Московская обл., Богородский район, пос. Горбуша, Радиоцентр. Техническая возможность удаленного подключения обеспечивается Заказчиком (в части предоставления параметров доступа). Оплата телематических и иных услуг, технических и программных средств, необходимых Подрядчику для удаленного подключения и для выполнения требований по информационной безопасности, осуществляется Подрядчиком самостоятельно за свой счет 1.1. Наименование Системы Полное наименование системы: Информационно-аналитическая система регулирования на транспорте. Условное обозначение системы: АСУ ТК. Полное наименование модуля: Модуль сбора, ведения и анализа информации о нештатных ситуациях на транспорте. Условное обозначение модуля: Модуль СЦ. Модуль СЦ создан в рамках контракта от 05.08.2024 № ОК/24_04 на выполнение работ по развитию АСУ ТК в части создания модуля «Сбора, ведения и анализа информации о нештатных ситуациях на транспорте». Развитие Модуля СЦ осуществлено в рамках контракта от 19.05.2025 № ОК/25_09 на выполнение работ по развитию Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК 1.2. Шифр темы или номер контракта Присваивается Заказчиком по результатам организации закупочных процедур. 1.2.1. Предмет контракта Выполнение работ по развитию Модуля СЦ. Код по ОКПД2: 62.01.11.000 – услуги по проектированию и разработке информационных технологий для прикладных задач и тестированию программного обеспечения. Оказание услуг по технической поддержке Модуля СЦ. Код по ОКПД2: 62.02.30.000 – услуги по технической поддержке информационных технологий. Выполнение работ по развитию Модуля СЦ предусмотрено с учетом ключевых результатов (ОКР) Ведомственной программы цифровой трансформации Минтранса России на 2026-2028 (далее - ВПЦТ Минтранса России) в составе мероприятия № 103.002 «АСУ ТК» ИТ расхода 103.26.000005 «Развитие Информационно-аналитической системы регулирования на транспорте (АСУ ТК)»: · «Обеспечено информационное взаимодействие с Минобороны о происшествиях на транспортных объектах»; · «Обеспечена автоматизация формирования отчетов о нештатных ситуациях на транспорте, в том числе по данным внешних систем». Выполнение работ по технической поддержке АСУ ТК предусмотрено ВПЦТ Минтранса России в составе мероприятия № 103.002 «АСУ ТК» ИТ расхода 103.26.000021 «Эксплуатация Информационно-аналитической системы регулирования на транспорте (АСУ ТК)» 1.3. Заказчик Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» (ФГБУ «СИЦ Минтранса России»). Адрес: 107078, Москва, Садовая-Спасская ул., д.18, стр. 1. Оператором Системы является Заказчик - Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» (ФГБУ «СИЦ Минтранса России) 1.4. Подрядчик Определяется по результатам проведения конкурентной процедуры закупки в соответствии с требованиями Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (далее – Федеральный закон № 44-ФЗ) 1.5. Основания для выполнения работ Работы осуществляются на основании следующих документов: – постановление Правительства Российской Федерации от 30.12.2003 № 794 «О единой государственной системе предупреждения и ликвидации чрезвычайных ситуаций»; – постановление Правительства Российской Федерации от 08.11.2013 № 1007 «О силах и средствах единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций»; – распоряжение Правительства Российской Федерации от 27.11.2021 № 3363-р «О Транспортной стратегии Российской Федерации до 2030 года с прогнозом на период до 2035 года»; – Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 26.08.2025 №ЕФ-3; – Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 27.11.2025 №ЕФ-23; – Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 19.02.2026 №ЕФ-1; – План мероприятий по профилактике случаев непроизводственного травматизма граждан на железнодорожном транспорте, являющийся приложением к постановлению коллегии Министерства транспорта Российской Федерации от 11.03.2026 № 2 1.6. Перечень документов, требования которых должны быть учтены при выполнении работ – Федеральный закон Российской Федерации от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации»; – Федеральный закон Российской Федерации от 27.07.2006 № 152-ФЗ «О персональных данных»; – Федеральный закон Российской Федерации от 06.04.2011 № 63-ФЗ «Об электронной подписи»; – Федеральный закон Российской Федерации от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации»; – Указ Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации»; – Указ Президента Российской Федерации от 01.05.2022 № 250 «О дополнительных мерах по обеспечению информационной безопасности Российской Федерации»; – Указ Президента Российской Федерации от 31.03.2010 № 403 «О создании комплексной системы обеспечения безопасности населения на транспорте»; – постановление Правительства Российской Федерации от 30.07.2004 № 395 «Об утверждении Положения о Министерстве транспорта Российской Федерации»; – постановление Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации»; – постановление Правительства Российской Федерации от 16.11.2015 № 1236 «Об установлении запрета на допуск программного обеспечения, происходящего из иностранных государств, для целей осуществления закупок для обеспечения государственных и муниципальных нужд»; – постановление Правительства Российской Федерации от 23.12.2024 № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц»; 2. ЦЕЛИ И НАЗНАЧЕНИЕ ВЫПОЛНЕНИЯ РАБОТ 2.1. Назначение АСУ ТК АСУ ТК предназначена для автоматизации и информационно-аналитического обеспечения процессов управления развитием транспортного комплекса Российской Федерации, обеспечения публичности деятельности органов государственного управления транспортным комплексом. Основными целями АСУ ТК являются: – повышение эффективности процессов управления функционированием и развитием транспортного комплекса на основе создания единой информационной среды и комплекса информационно-аналитических услуг на уровне органов государственного управления ТК; – повышение уровня безопасности ТК на базе получения полной, достоверной и оперативной информации о происходящих изменениях, своевременного выявления негативных тенденций и для принятия соответствующих мер по их устранению и ликвидации последствий Значение характеристики не может изменяться участником закупки Основными задачами АСУ ТК являются: – автоматизация процессов прогнозирования развития транспортного комплекса и поддержки принятия управленческих решений; – автоматизация процессов мониторинга безопасности и устойчивости транспортного комплекса, управления в чрезвычайных и нештатных ситуациях; – автоматизация процессов управления программами и проектами развития и модернизации транспортного комплекса; – автоматизация процессов мониторинга состояния транспортного комплекса, в том числе с использованием набора ключевых показателей эффективности деятельности транспортного комплекса; – информационно-технологическая поддержка взаимодействия субъектов транспортного комплекса Российской Федерации, органов государственного управления и контроля, международных организаций на основе создания единой технологической среды взаимодействия и управления движением данных (и связанных с ними документов) в транспортном комплексе; – использование в процессах управления транспортным комплексом РФ современных технологий электронного документооборота и электронного обмена данными; – организация межведомственного электронного взаимодействия подразделений Министерства транспорта Российской Федерации, подведомственных агентств и службы с другими организациями 2.2. Назначение и цели развития и технической поддержки Модуля СЦ Назначение Модуля СЦ: – оперативный мониторинг нештатных и чрезвычайных ситуаций на транспорте ; – оповещение заинтересованных лиц и структур о нештатных и чрезвычайных ситуациях; – сбор, обработка и хранение данных о нештатных и чрезвычайных ситуациях. Целями развития Модуля СЦ являются: – расширение состава данных об оперативной обстановке на транспорте; – оптимизация процесса сбора данных об оперативной обстановке на транспорте; – повышение информированности пользователей за счет визуализация данных Модуля СЦ; – автоматизация процесса формирования отчетов о ЧС и нештатной ситуации на транспорте; – обеспечение информационного взаимодействия с заинтересованными организациями по вопросам ведения. Целями оказания услуг по технической поддержке являются: – обеспечение информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы; – поддержание параметров функционирования ППО Системы, удовлетворяющих требованиям производственных процессов, включая их непрерывность; – обеспечение бесперебойного функционирования ППО и своевременное устранение сбоев и аварийных ситуаций в Системе; – своевременное устранение уязвимостей при выявлении таковых, в соответствии с требованиями к обеспечению информационной безопасности; – адаптация, конфигурирование, коррекция программного обеспечения в соответствии с изменениями нормативно-правовой базы и запросами уполномоченных сотрудников органов государственной власти, включая выполнение процедур тестирования и участие в обновлениях ППО на стендах Заказчика; – обеспечение сохранения работоспособности ППО в изменяемой среде эксплуатации; – ведение документации по настоящему ТЗ, инициирование и актуализация документации на Систему по результатам обработки запросов Заказчика и внесении соответствующих изменений в ППО. Модуль СЦ применяется в деятельности Министерства транспорта Российской Федерации, подведомственных агентств и службы и другими организациями в соответствии с соглашениями об информационном обмене 3. ХАРАКТЕРИСТИКА ОБЪЕКТА АВТОМАТИЗАЦИИ 3.1. Описание объекта автоматизации АСУ ТК Объектом автоматизации являются процессы основной и обеспечивающей деятельности, направленные на управление транспортным комплексом, в том числе, процессы информационного взаимодействия с другими организациями и субъектами транспортного комплекса. АСУ ТК относится к государственным информационным системам, а также к информационным системам персональных данных и значимым объектам критической информационной инфраструктуры Российской Федерации. АСУ ТК соответствует требованиям, предъявляемым к: – ГИС второго класса защищенности в соответствии с приказом ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах»; – ИС персональных данных при обеспечении третьего уровня защищенности персональных данных в соответствии с требованиями постановления Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»; – значимым объектам КИИ Российской Федерации второй категории значимости с постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении Правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений». Модуль СЦ является подсистемой АСУ ТК. Перечень платформенных решений и функциональных задач АСУ ТК представлен в Таблице 1 Значение характеристики не может изменяться участником закупки Таблица 1 – Перечень платформенных решений и функциональных задач АСУ ТК № Наименование подсистемы/ функциональной задачи/ модуля Назначение 1 Подсистема сбора данных и централизованного хранилища данных Подсистема обеспечивает выполнение сбора данных в АСУ ТК, и в т. ч., в рамках функциональных задач «Формирование и ведение межрегионального транспортного баланса пассажирских перевозок в дальнем (межрегиональном) сообщении» и «Формирование и ведение транспортного паспорта региона» 2 Подсистема информационного взаимодействия Подсистема информационного предназначена для обеспечения информационного взаимодействия подсистем АСУ ТК, а также, взаимодействия АСУ ТК с АС федеральных органов исполнительной власти 3 Подсистема ведения нормативно-справочной информации и метаданных Подсистема предназначена для автоматизации функций формирования и актуализации справочников, классификаторов, реестров и регистров, необходимых для обеспечения информационной поддержки пользователей НСИ и интеграции подсистем АСУ ТК в части применения НСИ 4 Модуль СМЭВ Модуль взаимодействия со СМЭВ представляет собой набор сервисов взаимодействия: сервис синхронного взаимодействия и сервис отправки, осуществляющих дополнительную обработку сообщений, отправляемых в СМЭВ и принимаемых из СМЭВ 5 Геоинформационная подсистема Программное обеспечение геоинформационной подсистемы предназначено для обеспечения смежных подсистем АСУ ТК возможностью работы с картографической информацией, в том числе, отображения на электронных картах объектов транспортной инфраструктуры и получения информации о местоположении, характеристиках контролируемых транспортных объектов 6 Подсистема информационного портала АСУ ТК Подсистема информационного портала предназначена для отображения и входа в функциональные задачи АСУ ТК 7 Подсистема технического портала АСУ ТК Подсистема технического портала АСУ ТК предназначена для управления заявками пользователей и технологического документооборота заявок 8 Подсистема проектного архива АСУ ТК Подсистема проектного архива АСУ ТК предназначена для автоматизации деловых процессов должностных лиц Министерства транспорта Российской Федерации, подведомственных агентств и службы, в том числе, и процессов информационного взаимодействия внутреннего и внешнего характера 9 ФЗ «Реестр объектов» Функциональная задача предназначена для формирования и ведения единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации 10 ФЗ «СТП» Функциональная задача предназначена для организации информационно-аналитической поддержки процессов территориального планирования Российской Федерации в области федерального транспорта 11 ФЗ «МРТБ ПП» Функциональная задача предназначена для формирования и ведения межрегионального транспортного баланса пассажирских перевозок в дальнем (межрегиональном) сообщении 12 ФЗ «МДД» Функциональная задача предназначена для осуществления мониторинга дорожного движения 13 ФЗ «ТПР» Функциональная задача предназначена для формирования и ведения транспортного паспорта региона 14 ФЗ «Данные по грузообороту» Функциональная задача предназначена для обеспечения подсистем и пользователей АСУ ТК данными по грузообороту между Российской Федерацией и зарубежными странами 15 ФЗ «МЖТ» Функциональная задача предназначена для осуществления мониторинга железнодорожного транспорта 16 ФЗ «МГМП» Функциональная задача предназначена для осуществления мониторинга грузопотоков в морских портах с целью формирования единой цифровой среды мониторинга и планирования перевозок в/из портов Дальнего Востока 17 Модуль ГЭТ Модуль предназначен для получения, хранения данных инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по отдельно взятому предприятию-перевозчику. Формирования отчетов об инвентаризации с детальными данными по каждому разделу инвентаризации с маршрутизацией в муниципалитет / регион / Минтранс. Содержит агрегированные данные инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по всем перевозчикам, относящихся к данному муниципалитету. Формирует сводный отчет по муниципалитету по каждому разделу инвентаризации с маршрутизацией в регион / Минтранс. Формирует агрегированные данные инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по всем перевозчикам, относящиеся к данному региону и по всем муниципалитетам, относящимся к данному региону. Аналитические и статистические данные о состоянии ГЭТ региона. Содержит данные о видах транспорта, цифровых транспортных сервисах и платежных инструментах Региона. Формирует сводный отчет по каждому разделу инвентаризации с маршрутизацией в Минтранс. Формирует агрегированную статистику и аналитику по всем регионам страны в разрезе транспортных средств, маршрутов, пассажиропотоков, инфраструктуры ГЭТ. Данные о рейтинге регионов и перевозчиков на основании выбранных параметров, документооборот с участниками Системы: получение подписанных печатных форм, их утверждение, возврат на доработку. 18 Модуль iМинтранс Модуль создан для отчета по ключевым показателям транспортного комплекса России (Отраслевые и статистические показатели, исполнение бюджета, исполнение поручений, аналитика СМИ, происшествия по видам транспорта). 19 Модуль СЦ Модуль СЦ предназначен для оперативного мониторинга нештатных ситуаций транспортной отрасли, оповещения заинтересованных лиц и структур и предоставления данных о нештатных ситуациях АСУ ТК осуществляет идентификацию и авторизацию посредством Единой системы идентификации и аутентификации (ЕСИА). Информационный обмен с внешними информационными системами осуществляется посредством СМЭВ 3 и СМЭВ 4. АСУ ТК развернута на вычислительных мощностях ГЦОД СИЦ Минтранса России 3.2. Описание и текущее состояние объекта автоматизации Модуля СЦ Объектом автоматизации является процесс организации мониторинга информации о НС и ЧС на транспорте. Предметом деятельности Учреждения являются следующие функции: – информационное обеспечение в области транспортной безопасности, защиты населения и территорий от чрезвычайных ситуаций природного и техногенного характера в транспортном комплексе; – подготовка справочных материалов при угрозе возникновения и возникновении чрезвычайных ситуаций и иных происшествий в транспортном комплексе; – взаимодействие и обмен оперативной информацией с органами управления Единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций; – организация оперативного мониторинга обстановки на объектах транспорта при угрозе и возникновении чрезвычайных ситуаций и иных происшествий. Перечень компонентов Модуля СЦ и выполняемые ими функции представлены в Таблице 2 Таблица 2. Перечень компонентов Модуля СЦ и их функции № п/п Компонент Выполняемые функции 1 Регистрация событий – ведение карточки события; – удаление комментария; – динамическое отображение существующих событий в заданном радиусе и за заданный период; – возможность автоматической проверки вводимых данных в части количества пострадавших; – отображение карточки ОТИ, ТС в соответствии с ФЗ Реестр объектов; – сохранение и отображение версии карточки события; – привязка события к координатам по картографической основе; – указание признака выполнения действия по отработке события; – перевод статуса события; – закрытие карточки события; – публикация информации о событии в канале мессенджера; – возможность перехода из карточки события на картографическую основу для просмотра местоположения события 2 Визуализация – отображение событий на картографической основе в виде пиктограмм; – масштабирование карты; – отображение краткой карточки события при выборе события на картографической основе; – отображение списка событий; – отображение карточки события; – отображение журнала действий пользователя; – отображение дополнительной информации (текстовая информация и приложенные файлы); – отображение справки о событиях и отчета о событиях; – отображение фильтров и количества отфильтрованных объектов; – отображение результатов поиска; – отображение статистики по событиям на экране; – возможность создания события с картографической основы; – отображения картографических слоев в зависимости от примененных фильтров; – возможность настройки шага картографической сети; – возможность настройки географической точки центра карты; – отображение количества непрочитанных сообщений; – возможность перехода к детальной карточке события из краткой карточки события при выборе события на картографической основе 3 Информирование – ведение справочника способов оповещения (веб-интерфейс, мессенджер); – формирование сценария выполнения оповещения (настройка условий, способа, параметров оповещения); – выполнение оповещений пользователей 4 Отчетность – формирование отчета и справки о событиях; – фильтрация событий для выгрузки в справку о событиях или в отчет о событиях 5 Администрирование – ведение ролей пользователей; – ведение учетных данных пользователей; – ведение справочника организаций; – ведение справочника групп системы мгновенного обмена сообщениями; – выполнение исходящего звонка на контактный телефонный номер организации; – формирование матрицы эскалации событий Архитектура Модуля СЦ представлена на рисунке 1. Рисунок 1. Архитектура Модуля СЦ 3.3. Состав используемого ПО Модуля СЦ Программная архитектура Модуля СЦ разработана как трехуровневая клиент-серверная архитектура. Архитектура включает в себя следующие уровни: • уровень представления – презентационный уровень, обеспечивающий взаимодействие с пользователя с клиентскими приложениями с использованием веб-браузера («тонкий» клиент); • уровень приложений – реализован в виде сервисов, обеспечивает обработку запросов, поступающих от клиентских приложений, формирование ответов на запрос в доступном пользователю виде (формирование пользовательских интерфейсов); • уровень хранения данных – реализуется как сервер БД и обеспечивает хранение и целостность хранимых данных, создание резервных копий, ведение журнала транзакций, восстановление данных после сбоев. Программная архитектура Модуля СЦ включает в себя сервисы и интерфейсы, указанные в Таблице 3. Таблица 3. Программная архитектура Модуля СЦ Программный сервис/интерфейс Технологии реализации Уровень представления Интерфейс пользователя и администратора (front-end) Javascript Уровень приложений Сервис (GateWay) Kotlin Сервис геокодирования (geocoding-service) Kotlin Сервис уведомлений (notifiсation-service) Kotlin Сервис работы с файлами (file-service) Kotlin Сервис отчетности (report-service) Kotlin Сервис управления событиями (event-service) Kotlin Сервис информирования через мессенджер (messenger-notifier) Python Сервис внешних интеграций (integration-service) Сбор информации из внешних систем и сервисов Брокер сообщений Kafka Уровень хранения данных Файловое хранилище MinIO S3 СУБД Postgres Pro Enterprise 3.4. Информационное взаимодействие программных сервисов и интерфейсов Модуля СЦ Объект автоматизации функционирует в распределенной информационной среде. Обмен данными осуществляется по защищенным каналам связи (в том числе ведомственным сетям передачи данных). Источники информации включают: · внешние автоматизированные системы (органов государственной власти); · внутренние базы данных (реестры объектов транспортной инфраструктуры, паспорта регионов и пр.); · оперативная информация от персонала, поступающая через автоматизированные рабочие места (АРМ) и мобильные устройства. 3.4.1. Взаимодействие Модуля СЦ со смежными подсистемами АСУ ТК Модуль СЦ входит в состав АСУ ТК и взаимодействует со следующими ее функциональными задачами и подсистемами: · Функциональной задачей «Формирование и ведение единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации» (ФЗ «Реестр объектов»); · Геоинформационной подсистемой АСУ ТК (П-ГИС); · Подсистемой ведения нормативно-справочной информации и метаданных (П-НСИ); · Подсистемой сбора данных и централизованное хранилище данных (П-СД); · Подсистемой информационного взаимодействия (П-ИВ). 3.4.2. Взаимодействие с внешними информационными системами Список внешних информационных систем, с которыми осуществляется взаимодействие Модуля СЦ: · ЕСИА; · мессенджер; · Яндекс Геокодер; · Информационная система «Централизованная система сбора информации систем-112»; · ПВК «Поиск-Море», АИС РПТ; · облачная АТС 3.5. Требования к эксплуатации Применяемое в Системе программное обеспечение, программно-аппаратные и аппаратные комплексы должны соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации» 4. ТРЕБОВАНИЯ К МОДУЛЮ СЦ 4.3.1.3. Требования к регламенту оказания услуг Подрядчик должен руководствоваться Регламентом оказания услуг по технической поддержке Модуля СЦ. Регламент оказания услуг содержит следующую информацию: – порядок оказания услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Модуля СЦ; – порядок оказания услуги по решению инцидентов, связанных с работой ППО; – порядок оказания услуги адаптационного, конфигурационного и коррекционного сопровождения Модуля СЦ (в рамках действующих программных модулей и функциональностей); – порядок оказания услуги по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности. – Регламент содержит следующие формы заявок на оказание услуг: – форма заявки на оказание услуги по информационно-консультационной поддержке сотрудников Заказчика; – форма заявки на оказание услуги по решению инцидентов, связанных с работой ППО; – форма заявки на оказание услуг адаптационного, конфигурационного и коррекционного сопровождения Модуля СЦ (в рамках действующих программных модулей и функциональностей) (приоритет заявки определяется Заказчиком); – форма заявки на оказание услуги по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности Значение характеристики не может изменяться участником закупки 4.3.2. Требования к режиму обеспечения функционирования Модуля СЦ Режим оказания услуг определен в Приложении Б к настоящему ТЗ. По согласованию с Заказчиком, в целях недопущения остановки функционирования Модуля СЦ в период интенсивной работы пользователей в Модуле СЦ, отдельные услуги могут оказываться по специальному графику (в нерабочее время Подрядчика) в соответствии с заявками Заказчика 4.3.3. Требования к качеству оказываемых услуг Качество оказываемых услуг поддерживается Подрядчиком в соответствии с определяемыми данным ТЗ условиями и правилами и контролируется Заказчиком на постоянной основе, в том числе по соблюдению сроков исполнения и подтверждениям исполнения от инициаторов обращений и другим параметрам. По результатам выполнения работ по устранению инцидента должна быть устранена корневая причина инцидента с окончательным решением, устраняющим причину возникновения проблемы и исключающим вероятность повторного возникновения проблемы (инцидента). Время устранения корневых причин проблемы (инцидента) не должно составлять более 40 рабочих часов 4.5.7. Требования по сохранности информации при авариях В случае возникновения аварии или сбоя в процессе выполнения пользовательских задач должно быть обеспечено восстановление баз данных до состояния на момент последней завершенной Модулем СЦ транзакции, и структуры файлового хранилища. Все аварийные ситуации должны обрабатываться программно с выдачей соответствующих сообщений, с корректной обработкой ситуации (завершение транзакций, закрытие файлов и т.п.), без потери обрабатываемой информации. В Модуле СЦ должны быть предусмотрены меры, обеспечивающие целостность данных в случае отказа программного обеспечения или аппаратных средств, исключая случаи физического уничтожения носителя или нарушения функциональности носителя, операционной системы или СУБД по вине их производителя либо обслуживающего персонала. Используемые аппаратные и системные платформы должны обеспечивать сохранность и целостность информации в Модуле СЦ при полном или частичном отключении электропитания, аварии сетей телекоммуникации, полном или частичном отказе технических средств Модуля СЦ. Технические решения должны обеспечивать сохранность информации в случае возникновения следующих событий (аварий, отказов и т.п.): – отказ аппаратного обеспечения на сервере; – отключение питания на сервере; – отказ аппаратного обеспечения на рабочей станции; – отключение питания на рабочей станции администратора; – отказ линий связи, в том числе при осуществлении обмена данными 4.5.8. Требования к защите от влияния внешних воздействий Требования к защите от влияния внешних воздействий не предъявляются 4.5.9. Требования к патентной чистоте и патентоспособности 4.5.9.1. Исключительные права на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, базы данных, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, принадлежат Российской Федерации в лице Заказчика. Право собственности на результаты работ, отчетные документы и материалы, полученные в ходе выполнения работ по Контракту, принадлежат Российской Федерации в лице Заказчика и считаются переданными с момента подписания Сторонами Акта сдачи-приемки выполненных работ. Разработанное программное обеспечение поставляется вместе с исходными кодами. 4.5.9.2. Все проектные и технические решения должны отвечать требованиям четвертой части Гражданского кодекса Российской Федерации. Результаты Работ должны быть свободными от возможности предъявления любых прав и притязаний третьих лиц, основанных на промышленной, интеллектуальной или другой собственности. 4.5.9.3 Результаты выполненных Работ не должны повлечь необходимость осуществления Заказчиком закупок программного обеспечения (как исключительных, так и неисключительных прав) для обеспечения функциональности Системы в соответствии с Техническим заданием. При выполнении работ Подрядчик должен использовать только объекты интеллектуальной собственности, права на которые приобретены (получены) и используются без нарушений прав на интеллектуальную собственность третьих лиц или предоставлены Заказчиком 4.3.4. Требования к документированию результатов оказываемых услуг Для обеспечения контроля оказываемых услуг по поддержке Модуля СЦ со стороны Заказчика, по окончании каждого отчетного периода по контракту в соответствии с календарным планом, Подрядчик обязан предоставить Заказчику Отчет об оказанных услугах. Отчет должен содержать детальную информацию об оказанных услугах с указанием даты выполненных мероприятий и приложением обосновывающих документов (заявок, запросов, требований) или ссылкой на такие документы, если они содержатся в Модуле СЦ. Информация о выполненных мероприятиях по заявкам должна быть сформирована на основании соответствующих записей СРО по каждому этапу исполнения Контракта. В случае оказания услуги адаптационного, конфигурационного и коррекционного сопровождения Модуля СЦ, должны быть предоставлены документы, подтверждающие выполнение требований п. 29.3 приказа ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации». Фактическое время реагирования и время решения по всем обращениям, поступившим в СРО, формируется в СРО по итогам отчетного периода в разделе «Отчеты». Фактическое время реагирования и время решения по обращениям учитывает суммарное время, затраченное на реагирование и, соответственно, на работу по обращению с момента назначения обращения специалисту Подрядчика или группе исполнителей, ответственным за оказание услуг технической поддержки 3 уровня от начала до завершения работ Подрядчиком. При этом принимается суммарное время нахождения заявки в соответствующих статусах заявки СРО на стороне Подрядчика 4.3.5. Требования к классификации обращений и заявок Обращения и заявки Заказчика классифицируются в соответствии с приоритетами и регламентными сроками, указанными в Приложении 2 к Регламенту. Регистрация обращений и заявок предусматривает создание новой записи в СРО с присвоением поступившему обращению или заявке (новой записи) уникального идентификатора. Запись в СРО должна содержать вопрос или проблему, которую требуется решить или оказать консультацию. Состав обязательной информации, которую должно содержать обращение или заявка, зафиксирован в Регламенте оказания Услуг. Если обращение или заявка автоматически зарегистрированы в СРО при отправке представителем Заказчика, Подрядчик проверяет корректность классификации обращения или заявки и может обратиться к Заказчику с просьбой корректировки, предоставив обоснования в соответствии с настоящей классификацией (Таблица 6) 4.5.9.4. Подрядчик подтверждает, что обладает всеми правами на передачу Заказчику исключительных прав в соответствии с требованиями настоящего раздела Технического задания. В случае, если к Заказчику по вине Подрядчика будут предъявлены претензии в этой части, иски третьих лиц, связанные с нарушением их прав, Подрядчик принимает на себя такие претензии и иски и возмещает Заказчику все расходы и весь ущерб, понесенный в связи с ними. 4.5.9.5. Подрядчик обязан согласовать с Заказчиком необходимость использования при выполнении работ охраняемых результатов интеллектуальной деятельности, права на которые принадлежат Подрядчику или третьим лицам. 4.5.9.6. В случае, если при выполнении Работ используется готовое программное обеспечение (платформа, подсистема, СУБД и т.д.), которое становится частью (компонентом) Системы, Заказчику передаются полные исключительные права, или неисключительные права (путем заключения лицензионного/сублицензионного договора/соглашения) на такое программное обеспечение со следующими возможностями: – права передаются бессрочно (на весь срок действия исключительных прав); – территория действия Российская Федерация; – должно быть обеспечено право Российской Федерации (в лице Заказчика) передавать, дорабатывать, распространять, развивать результаты работ, созданные в процессе исполнения Контракта, а также перерабатывать такое программное обеспечение. Лицензионное (сублицензионное) соглашение (договор), Акт передачи прав, подписанные Подрядчиком, согласие правообладателя, оформленное в соответствии с положениями Гражданского кодекса Российской Федерации (в случае, если Подрядчик не является правообладателем такого программного обеспечения), инструкция по инсталляции, руководство администратора, руководство пользователя передаются Заказчику в сроки, установленные Техническим заданием для соответствующего функционала Системы Лицензионное (сублицензионное) соглашение (договор) не может возлагать на Заказчика какие-либо обязанности (в т.ч. в части конфиденциальности, предоставления отчетности), не предусмотренные Контрактом. 4.5.9.7. Передача Заказчику исключительных прав, или простых (неисключительных) прав не может повлечь увеличение стоимости Контракта и/или изменение иных существенных условий Контракта. 4.5.9.8. Функциональность Модуля СЦ передается в объеме и в сроки, установленные Техническим заданием. 4.5.9.9. Нарушение условий настоящего раздела Технического задания, в т.ч. отсутствие соответствующего лицензионного (сублицензионного) соглашения (или договора), либо предоставление лицензионного (сублицензионного) соглашения (или договора), не соответствующего требованиям действующего законодательства Российской Федерации или требованиям Контракта, является нарушением существенных условий Контракта. 4.5.9.10. В случае, если в соответствии с пунктом 4.5.9.6 Заказчику передается исключительное право, такая передача осуществляется в порядке, установленном Гражданским кодексом Российской Федерации. 4.5.9.11. В случае, если при выполнении Работ положения пунктов 4.5.9.5-4.5.9.6 не применялись, Подрядчик в составе отчетной документации предоставляет об этом декларацию в свободной форме. Декларация должна содержать сведения о полном соответствии результата Работ требованиям Контракта, а также о неприменении при выполнении работ готового программного обеспечения (платформ, подсистем, СУБД и т.д.), которое стало частью (компонентом) Системы Таблица 6. Категории обращений и заявок Категория Примеры Запрос на обслуживание Подготовка SQL запроса к СУБД для решения прикладной задачи и д.р. – запрос на любое действие, не являющееся запросом информации и несовершенный на основе происшествия, прямо или косвенно влияющего на работу Модуля СЦ Консультация «Где взять / куда обратиться...?», «Как сделать / выполнить…», «Как это работает…?» - запрос, имеющий своей целью получение информационной поддержки Инцидент Разбор ошибок/сбоев и подготовка материалов (корректировочных релизов, инструкций) для Заказчика для устранения ошибок/сбоев, которые приводят к частичному и полному нарушению работоспособности всех или отдельных функций ППО. Подготовка изменения и материалов, необходимых для проведения аварийно-восстановительных работ для возобновления работоспособности Модуля СЦ ЗНИ Подготовка изменений, связанных с изменением, улучшением/оптимизацией Модуля СЦ и выводом новой модифицированной функциональности в штатном режиме. Подготовка изменений, связанных с модификацией существующих и/или реализация новых интеграционных механизмов для получения/обработки данных внешних систем. Подготовка изменений графического интерфейса по требованиям Заказчика. Перечень статусов обращений (заявок) приведен в пункте 3.3. Регламента оказания Услуг. Назначение обращению (заявке) статуса «Закрыто» осуществляется Заказчиком только после получения от инициатора обращения (заявки) подтверждения о его исполнении или нахождения обращения (заявки) в статусе «Выполнено» и отсутствия повторных вопросов/запросов по данному обращению (заявки) в течение 5 рабочих дней. Категории и статусы обращений (заявок) могут быть скорректированы в процессе оказания услуг исключительно по согласованию с Заказчиком 4.3.6. Требования к услугам технической поддержки 4.3.6.1. Требования к организации третьего уровня технической поддержки Основными задачами организации третьего уровня технической поддержки в рамках оказания услуг по технической поддержке Модуля СЦ являются организация эксплуатационной службы Подрядчика, проверка готовности технических и программных средств для обеспечения непрерывного функционирования ППО Модуля СЦ. Подрядчиком должны быть проведены организационно-штатные и подготовительные мероприятия (в т. ч. технические) в рамках организации технической поддержки Модуля СЦ. Подрядчик в течение 5 (пяти) рабочих дней с даты заключения Контракта должен: – определить и направить Заказчику документ «Перечень уполномоченных специалистов», содержащий контактную информацию (ФИО, должность, адрес рабочей электронной почты) лиц, ответственных за оказание услуг со стороны Подрядчика; – обеспечить подключение специалистов Подрядчика к Системе регистрации обращений (заявок) (СРО предоставляется Заказчиком) для оказания услуг; – согласовать с Заказчиком способ доступа Подрядчика к Модулю СЦ. Результат выполнения мероприятий фиксируется в Протоколе проверки результатов организационно-штатных и подготовительных мероприятий (см. Приложение Д к настоящему ТЗ) 4.5.9.12. Передача Заказчику комплекта документов, материалов и сведений, предусмотренных нормативными правовыми актами Российской Федерации в сфере информационных технологий, защиты информации, правовой защиты интересов государства в области интеллектуальной собственности, включая документы, подтверждающие отказ авторов (разработчиков) от исключительных прав на передаваемые объекты интеллектуальной собственности в пользу Подрядчика, с проектами заявок на государственную регистрацию в установленном порядке прав Заказчика на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, базы данных, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, осуществляется Подрядчиком в составе отчетной документации, предусмотренной условиями Контракта. 4.5.9.13. По результатам выполнения работ по развитию системы должны быть подготовлены материалы для регистрации доработанной версии Системы (объекта учета) в НФАП в соответствии с требованиями постановления Правительства Российской Федерации от 30 января 2013?г. №?62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин» (с изменениями и дополнениями) в части обязательности размещения результатов работ в национальном фонде алгоритмов и программ для электронных вычислительных машин 4.5.10. Требования по стандартизации и унификации К Модулю СЦ предъявляются следующие требования в части стандартизации и унификации: – работы по развитию Модуля СЦ должны производиться в соответствии с действующими стандартами и нормами Российской Федерации; – при создании и модернизации элементов Модуля СЦ следует руководствоваться действующими в Российской Федерации национальными стандартами и другими нормативно-техническими документами; – используемые оборудование и материалы, подлежащие обязательной сертификации, должны иметь соответствующие сертификаты; – ПО Модуля СЦ должно проектироваться и разрабатываться с учётом обеспечения требований унификации; – применяемые при создании Модуля СЦ технические (форматы данных, протоколы передачи и прочие) и организационные (регламенты, требования, инструкции) решения должны быть доступны и документированы в виде, достаточном для независимой (без обращения к Подрядчику) реализации третьими сторонами; – термины, обозначения и наименования, используемые в ПО, должны быть стандартизованы и унифицированы, выполнены на русском языке; – взаимодействие элементов и их внешнее поведение должно быть реализовано одинаково и производиться по единым правилам 4.3.6.2. Требования к услугам информационно-консультационной поддержки работников Заказчика и пользователей Модуля СЦ Услуги информационно-консультационной поддержки сотрудников Заказчика включают: – обработку обращений и заявок, поступивших от сотрудников Заказчика; – консультирование сотрудников Заказчика и пользователей Модуля СЦ; – актуализацию документации, и других материалов по работе с Модулем СЦ при необходимости. – консультирование и разработку рекомендаций по настройке Модуля СЦ (без изменения программного кода), включая изменение настроек функционирования; – консультации по вопросам использования, настройки и возможностям Модуля СЦ; – консультации по проведению превентивных мер для недопущения аварийных ситуаций в Модуле СЦ; – консультации по предварительной диагностике и локализации возникшей неисправности Модуля СЦ; – консультации по вопросам обеспечения информационной безопасности Модуля СЦ и настройки функций, обеспечивающих корректную работу программного обеспечения для совершения юридически значимых действий в Модуле СЦ; – другие вопросы, связанные с работой Модуля СЦ. 4.3.6.2.1. Требования к порядку оказания услуг информационно-консультационной поддержки работников Заказчика и пользователей Модуля СЦ Подрядчик выполняет консультирование сотрудников Заказчика и пользователей Модуля СЦ. Консультация может быть предоставлена по согласованным с представителем Заказчика каналам коммуникации с регистрацией результата консультации в СРО Подрядчиком. Детальный порядок оказания консультационных услуг определен в Регламенте оказания Услуг 4.3.6.3. Требования к услугам по решению инцидентов, связанных с работой ППО Подрядчик устраняет неисправности Модуля СЦ, связанные с работой ППО, выявленные в рамках оказания услуг согласно настоящему Техническому заданию, при этом в зону ответственности Подрядчика не входит устранение неисправностей, выявленных на стороне Заказчика и на стороне третьих лиц (провайдера связи, поставщика электропитания и т.д.). Первичная диагностика выявленной неисправности проводится на 1 и 2 уровнях технической поддержки и не входит в зону ответственности Подрядчика. Если при проведении первичной диагностики и попытке устранить неисправности на 1 и 2 уровнях технической поддержки, данную неисправность устранить не удалось и в процессе диагностики было выявлено, что проблема связана с работоспособностью ППО, обращение (заявка) назначается сотруднику Подрядчика, ответственному за оказание услуг технической поддержки 3 уровня. Инцидентами вне зоны ответственности Подрядчика являются: – работоспособность функциональности, выходящая за рамки текущей реализации функций в Модуле СЦ и/или являющаяся расширением требований Заказчика к функциям Модуля СЦ; – проведение профилактических и плановых работ, согласованных с Заказчиком; – нарушение работоспособности функций Модуля СЦ, вызванное проведением работ на стороне Заказчика 4.5.11. Требования к показателям назначения 4.5.11.1. Требования к показателям назначения мероприятий по развитию Модуля СЦ В рамках выполнения работ по развитию Модуля СЦ, предусмотренных ТЗ, показатель назначения «Количество пользователей» должен соответствовать значениям, приведенным в данном разделе. Пояснения по показателям, связанным с количеством пользователей, приведены в Таблице 8. Таблица 8. Определения показателей, связанных с количеством пользователей в Модуле СЦ № Показатель Определение Расчетное количество пользователей Количество пользователей, работу которых должен обеспечить Модуль СЦ к моменту сдачи работ по Контракту с учетом достижения всех показателей назначения Расчетное количество одновременно работающих пользователей Количество одновременно работающих пользователей, работу которых должен обеспечивать Модуль СЦ к моменту сдачи работ по Контракту с учетом достижения всех показателей назначения Значения показателей количества пользователей, достижение которых необходимо обеспечить, представлено в Таблице 9 Таблица 9. Значения показателей количества пользователей № Показатель Значение 1. Расчетное количество пользователей 1 000 2. Расчетное среднее количество одновременно работающих пользователей 200 Развитие Модуля СЦ должно быть направлено на достижение следующего эффекта (показателя), подставленного в мероприятии 103.002 «Информационно-аналитическая система регулирования на транспорте (АСУ ТК)» ВПЦТ Минтранса России: Выполнение работ по развитию Модуля СЦ предусмотрено мероприятием по развитию АСУ ТК, приведенном в ВПЦТ Минтранса России на 2026-2028 гг: № 103.002 «АСУ ТК» в составе ИТ расхода 103.26.000005 «Развитие предусматривает реализацию ОКР и эффектов, приведенных в Таблице 10. Таблица 10. ОКР и эффекты, приведенные в ВПЦТ Минтранса России на 2026 г. № ОКР Дата ОКР Эффекты 1 Обеспечено информационное взаимодействие с Минобороны России о происшествиях на транспортных объектах 25.12.2026 Сокращено время сбора и передачи сведений для Минобороны России о ЧС и НС на транспорте с 120 до 10 минут 2 Обеспечена автоматизация формирования отчетов о нештатных ситуациях на транспорте, в том числе по данным внешних систем 25.12.2026 Сокращено время на подготовку отчетов о нештатных ситуациях на транспорте с 20 до 5 минут Реализация остальных ОКР не является предметом данного ТЗ и проводится в рамках отдельного технического задания. 4.5.11.2. Требования к показателям назначения мероприятий по эксплуатации Модуля СЦ. Работы по эксплуатации Модуля СЦ не должны обеспечивать режимы функционирования Модуля СЦ, приведенные в разделе 4.5.2 данного ТЗ Работы по устранению неисправности приостанавливаются (по согласованию с Заказчиком) в следующих случаях: – если Подрядчиком в результате диагностики выявлено, что неисправность находится в зоне ответственности Заказчика. Подрядчик информирует Заказчика о выявленной неисправности в зоне его ответственности по согласованным каналам связи; – требуется действие со стороны Заказчика – до момента выполнения данного действия Заказчика. Заказчик информируется о необходимых действиях по согласованным каналам связи; – отсутствие возможности связаться со специалистами Заказчика, участие которых необходимо для устранения неисправности; – требуется доставить оборудование на объект – до момента доставки и установки оборудования. В случаях, представленных выше, время приостановки работ не входит в учет продолжительности устранения неисправности. Учет времени устранения неисправности Подрядчиком считается с момента назначения Инцидента специалисту Подрядчика, ответственному за оказание услуг технической поддержки 3 уровня. Подтверждение необходимости приостановления работ находится в зоне ответственности Подрядчика. Приостановление сроков выполнения задач в соответствии с настоящим пунктом подтверждается Заказчиком по мотивированному обращению Подрядчика в СРО, основанному на данных диагностики или на иных фактических обстоятельствах В случае непринятия Подрядчиком необходимых мер по информированию Заказчика (отсутствие надлежащего обращения от Подрядчика или отсутствие уведомления о необходимости осуществления каких-либо действий Заказчиком) не может являться основанием для приостановления работ по устранению неисправности. В отдельных случаях Подрядчику может потребоваться выполнение технологических работ для устранения причин неисправности или недопущения повторения их в будущем. Для обеспечения устранения неисправности Модуля СЦ Заказчиком проводится классификация в соответствии с приоритетами по степени срочности их устранения. Продолжительность устранения неисправности, а также периодичность информирования Подрядчиком Заказчика о ходе устранения неисправности, определены в Регламенте оказания услуг. При подаче обращения (заявки) наивысшего приоритета через СРО Заказчик должен дополнительно проинформировать службу поддержки Подрядчика о созданном обращении (заявки) по телефону уполномоченного сотрудника Подрядчика. При этом временем подачи обращения (заявки) считается время подачи обращения (заявки) через СРО 4.3.6.3.1. Требования к порядку оказания услуги по решению инцидентов, связанных с работой ППО При поступлении от Заказчика обращения (заявки), являющегося неисправностью в работе Модуля СЦ (инцидентом), Исполнитель реагирует на инцидент в СРО в срок не более 30 минут с момента поступления. В случае необходимости, для решения инцидента ответственный специалист должен связаться с инициатором обращения (заявки) для уточнения условий воспроизведения проблемы или для получения дополнительных сведений. После получения необходимых сведений от инициатора обращения (заявки) ответственный специалист производит диагностику с целью выявления причины инцидента и возможных путей устранения. В случае, если инцидент невозможно решить без получения дополнительных сведений от инициатора, и не удается связаться с инициатором в течение пяти рабочих дней, обращение (заявка) отклоняется в связи с недостатком данных для его решения, Заказчику направляется уведомление об отклонении обращения (заявки). Время, в течение которого невозможно связаться с инициатором, вычитается из общего времени обработки обращения (заявки). Все попытки связаться с инициатором должны фиксироваться с указанием даты и времени попытки, используемого способа связи (номер телефона, адрес электронной почты) и результата попытки (не удалось дозвониться, абонент недоступен, и т.д.) Факт и время решения инцидента должны быть зафиксированы и отражены в СРО. В случае, если причиной сбоя в работе Модуля СЦ является выход из строя аппаратного обеспечения или неработоспособность смежной информационной системы, время работы над инцидентом приостанавливается до момента устранения неисправности. В ходе решения инцидентов могут быть выявлены дефекты ППО Модуля СЦ. В случае обнаружения дефектов ППО, Подрядчик информирует об этом Заказчика. Исполнитель может быть привлечен к проверке результата устранения дефекта по инициативе Заказчика. Приоритеты инцидентов приведены в Приложении Б к ТЗ. Детальный порядок оказания услуги по решению инцидентов, связанных с работой ППО Модуля СЦ определен в Регламенте оказания Услуг 4.3.6.4. Требования к услугам адаптационного, конфигурационного и коррекционного сопровождения и доработки Модуля СЦ (в рамках действующих программных модулей и функциональностей) Услуги адаптационного, конфигурационного и коррекционного сопровождения и доработки Модуля СЦ включают: – управление изменениями и адаптация функций Модуля СЦ; – изменение настроек функционирования Модуля СЦ; – внесение изменений и/или модификаций Модуля СЦ (в рамках действующих программных модулей и функциональностей), направленных на улучшение их работоспособности и функциональных возможностей; – подготовка и передача Заказчику SQL запросов в СУБД для получения агрегированной информации из Модуля СЦ, которую невозможно получить с использованием графического пользовательского интерфейса; – адаптация модулей интеграций со смежными информационными системами 4.3.6.4.1. Требования к проведению изменений Основанием для внесения изменений является запрос от Заказчика. Все активности по внесению изменений должны быть согласованы с Заказчиком, а действия Подрядчика при оказании данной услуги должны быть зафиксированы. В рамках данного Технического задания изменениями считаются локальные доработки функционала Модуля СЦ, которые не должны приводить к необходимости выполнения дополнительных аттестационных испытаний или переаттестации АСУ ТК в соответствии с п. 33 приказа от 29.04.2021 № 77 «Об утверждении Порядка организации и проведения работ по аттестации объектов информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну». При необходимости внесения изменений в Модуль СЦ, не связанных с критичным инцидентом, существенно нарушающим работоспособность Модуля СЦ, Заказчик направляет Подрядчику обращение (заявку), в котором излагает суть изменения, которое требуется внести в Модуль СЦ. Исполнитель, в течение 3 (трех) рабочих дней с момента поступления соответствующего обращения (заявки), оценивает техническую возможность реализации запрашиваемого изменения и варианты реализации. По итогу проведения оценки Подрядчик направляет Заказчику заключение о возможности реализации данного изменения с описанием возможных вариантов реализации и согласует с Заказчиком проведение данного изменения При проведении работ по изменению и адаптации Подрядчик должен: – обеспечить выполнение требований безопасной разработки программного обеспечения; – обеспечить предварительное проектирование технических решений и согласование с Заказчиком проекта реализации изменения; – использовать семантическое версионирование (SemVer) в работе, передать Заказчику все артефакты разработки (исходный код и сторонние библиотеки, конфигурации, сборочные и собранные образы и др.); – подготовить полноценное описание функционала, включенного в релиз, с необходимыми схемами и пояснениями к обновлению на стендах Заказчика; – обеспечить тестирование разработанного функционала на стендах Заказчика силами Подрядчика; – решение о переносе измененного ППО на продуктивный стенд принимается Заказчиком по итогу результатов проведенного тестирования; – обеспечить техническое сопровождение процедуры тестирования ППО и переноса измененного ППО на продуктивный стенд Заказчика; – обеспечить экстренное внесение соответствующих изменений в случае выявления некорректной работы продуктивного стенда Заказчика после проведения обновления по итогам разработанного изменения в кратчайшие сроки; – актуализировать при необходимости комплект эксплуатационной документации: o руководство пользователя; o руководство администратора; o иные документы (при необходимости). Результат выполнения изменений должен быть отражен в Отчете по оказанию услуг. Типы и приоритеты изменений могут быть скорректированы в процессе оказания услуг исключительно по согласованию с Заказчиком 4.3.6.4.2. Требования к изменению настроек функционирования Изменение настроек функционирования может проводиться в рамках допустимых пределов изменения функционирования, заложенных в архитектуру Модуля СЦ. Изменение настроек функционирования включает в себя изменение данных и справочников, изменение форм документов, формируемых Модулем СЦ, изменение и настройку форматов и версий передачи данных в смежные системы. Доработка программного кода Модуля СЦ может допускаться (в случае необходимости) при выполнении работ по адаптации функций Модуля СЦ в части изменения формата передачи данных в смежные информационные системы при условии соблюдения требований пункта 29.3 приказа ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации» 4.3.6.5. Требования к услугам по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности По запросу Заказчика Подрядчик должен провести работу по приведению ППО в соответствие с требованиями по обеспечению информационной безопасности. Критичность уязвимости оценивается в соответствии в соответствии с Методическим документом ФСТЭК России «Методика оценки уровня критичности уязвимостей программных, программно-аппаратных средств» (утвержден ФСТЭК России 30.06.2025), а также с учетом ГОСТ 56545-2015 и международными стандартами (CVSS 3.0 и выше), и задает необходимый срок устранения. В процессе проведения Заказчиком обследования Модуля СЦ и выявления уязвимостей в ППО, связанных с исходным кодом Модуля СЦ и/или используемыми компонентами (библиотеками), Заказчик направляет Подрядчику обращение (заявку) на устранение, с указанием критичности и срочности принятия мер по устранению в СРО. Подрядчик при оказании услуг по обновлению или устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности должен: – провести анализ уязвимостей и связанных с ними исходным кодом и/или используемыми компонентами (библиотеками); – выработать варианты устранения указанных уязвимостей и согласовать с Заказчиком их реализацию; – своевременно внести изменения в исходный код Модуля СЦ и/или используемые компоненты (библиотеки) и подготовить соответствующее обновление; – провести обновление Модуля СЦ в тестовом контуре Заказчика и проинформировать Заказчика о готовности проведения тестирования; – протестировать успешность обновления или устранения уязвимостей в ППО и корректность функционирования Модуля СЦ на тестовом контуре, совместно с Заказчиком; – при невозможности незамедлительного устранения уязвимости приоритетов «Критический» и «Высокий» Подрядчик обязан предоставить исчерпывающий список причин и согласовать план достаточных компенсирующих мер с ответственными сотрудниками Заказчика. Результат внесения изменений отображается в соответствующей записи в СРО и в составе Отчета об оказанных услугах 4.3.6.5.1. Требования к порядку оказания услуг по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности Подрядчик в соответствии с приоритетами обращений и контрольными сроками исполнения (см. Приложение Б к ТЗ) оценивает техническую возможность и сроки устранения уязвимостей, и реализацию обновления Модуля СЦ. По итогу проведения оценки Подрядчик направляет в заявке СРО Заказчику заключение о возможности устранения уязвимостей и/или обновления в ППО и согласует с Заказчиком проведение данных работ При проведении работ по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности необходимо выполнить следующее: – Заказчику сформировать заявку на устранение (обновление) в СРО с полным списком обнаруженных уязвимостей и планируемыми работами; – согласовать в рабочем порядке время начала и завершения работ, перечень работ, выполняемых в рамках обновления или устранения уязвимостей в ППО с Заказчиком; – оповестить Заказчика о начале проведения работ на тестовом контуре; – провести работы по обновлению или устранению уязвимостей в ППО на тестовом контуре Модуля СЦ в установленные сроки; – протестировать выполнение работ в тестовом контуре и проинформировать Заказчика о готовности переноса ППО на продуктивный контур; – силами Заказчика обновить продуктивный контур Модуля СЦ, в соответствии с планом устранения и выполненными работами; – совместно с Заказчиком проверить корректность функционирования Модуля СЦ и устранения уязвимостей в продуктивном контуре Модуля СЦ по результатам обновления; – при необходимости актуализировать документацию (описание архитектуры, анкеты постановки на мониторинг и иные документы). Любые изменения в части обновления или устранения уязвимостей в ППО на промышленном контуре Модуля СЦ должны применяться только в случае успешного проведения аналогичных работ на тестовом контуре. Детальный порядок оказания услуги по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности определен в Регламенте оказания Услуг 4.4. Требования к видам обеспечения 4.4.1. Требования к лингвистическому обеспечению Документация на Модуль СЦ должна разрабатываться на русском языке. Взаимодействие пользователей с Модулем СЦ посредством графического интерфейса должно происходить на русском языке за исключением сообщений, зависящих от настроек системного программного обеспечения, установленного на рабочих местах пользователей. При разработке программных решений Модуля СЦ должно быть предусмотрено использование языков программирования высокого уровня, приведенных в Таблице 7. Таблица 7. Языки и средства разработки, специального программного обеспечения Модуля СЦ Категория Наименование Назначение Языки программирования Kotlin Разработка серверной логики и сервисов (backend) JavaScript / TypeScript Разработка клиентской части (frontend) Python Разработка скриптов интеграции, обработки данных и автоматизации Фреймворки и библиотеки Vue.JS Разработка пользовательских интерфейсов (веб-интерфейсы компонентов визуализации и отчетности) React Разработка пользовательских интерфейсов (при необходимости создания сложных интерактивных компонентов) Решения по лингвистическому обеспечению, включая перечень используемых языков программирования, должны быть согласованы с Заказчиком на этапе технического проектирования 4.4.2. Требования к математическому обеспечению Требования к математическому обеспечению не предъявляются. 4.4.3. Требования к метрологическому обеспечению Требования к метрологическому обеспечению не предъявляются. 4.4.4. Требования к организационному обеспечению Требования к организационному обеспечению не предъявляются. 4.4.5. Требования к методическому обеспечению Задачи методического обеспечения Модуля СЦ должны быть обеспечены за счет использования технологических и методических документов касающихся вопросов функционирования транспортного комплекса и разработки и эксплуатации ПО. 4.4.6. Требования к информационному обеспечению Состав, структура и способы организации информационного обеспечения в Модуле СЦ должны быть определены на этапе технического проектирования. Факты информационного обмена с внешними системами должны фиксироваться в соответствующем журнале 4.1. Требования к структуре Модуля СЦ В процессе работ по развитию Системы должны сохраниться основные требования к построению архитектуры Системы в соответствии с принципами трехуровневой архитектуры: 1. уровень хранения данных или уровень базы данных (сервер СУБД); 2. уровень сервера приложений (сервер аналитической обработки); 3. презентационный уровень, обеспечивающий взаимодействие с клиентскими приложениями. В состав Системы должны входить следующие основные компоненты: 4. сервер баз данных; 5. сервер приложений; 6. веб-сервер. Сервер баз данных должен обеспечивать хранение и целостность хранимых данных, создание резервных копий, ведение журнала транзакций, восстановление данных после сбоев. Сервер приложений должен обеспечивать обработку запросов, поступающих от клиентских приложений (через веб-сервер), формирование ответов на запрос в доступном пользователю виде (формирование пользовательских интерфейсов). Веб-сервер должен обеспечивать взаимодействие с оператором и внешними системами по HTTP / HTTPS протоколу в режиме «запрос-ответ» (получения запросов от пользователя и передачи ответа в виде соответствующей информации, обработанной серверами приложений). Взаимодействие Системы с пользователем должно отвечать требованиям модели «тонкого клиента» (т.е. представлять на стороне клиента (пользователя) лишь графический пользовательский интерфейс). Все составляющие Системы должны использовать единую методологию и отвечать единым принципам взаимодействия, надежности и управления. Перечень компонентов Модуля СЦ представлен в Таблице 4. Таблица 4. Перечень компонентов Модуля СЦ, в отношении которых выполняются работы по развитию № п.п. Наименование компонента Модуля СЦ Раздел ТЗ 1 Компонент регистрации событий 4.2.1. 2 Компонент отчетности 4.2.2 3 Компонент визуализации 4.2.3 4 «Интерактивная карта» (компонент создается) 4.2.4 5 Компонент администрирования 4.2.5 4.2. Требования к дорабатываемым функциям модуля СЦ 4.2.1. Развитие компонента регистрации событий (1 очередь) Должны быть выполнены следующие доработки: – обеспечение логирования действий пользователя, связанных с карточкой события; – доработка объектной модели в части создания новых типов сущностей (карточек) с учетом реализуемых интеграций с информационными ресурсами (силы и средства предупреждения и ликвидации ЧС и нештатных ситуаций на транспорте, ТС, ограничения воздушного пространства, неблагоприятные и опасные природные явления); – реализация механизма установления связи между сущностями в Модуле СЦ автоматизированным и ручным способами (события, природные явления, силы и средства предупреждения и ликвидации ЧС и нештатных ситуаций на транспорте, ограничения воздушного пространства, ОТИ, ТС и др.); – отображение в карточке установленных связей между сущностями. 4.4.7. Требования к программному обеспечению Общесистемное ПО, используемое в составе Модуля СЦ, должно быть зарегистрировано в Едином реестре российских программ для электронных вычислительных машин и баз данных и соответствовать рекомендованным показателям эффективности и соответствующим им значениям индикаторов эффективности перехода подведомственных организаций на использование российского ПО, заданных Приказом Минцифры России от 18.01.2023 № 21 «Об утверждении методических рекомендаций по переходу на использование российского программного обеспечения, в том числе на значимых объектах критической информационной инфраструктуры Российской Федерации, и о реализации мер, направленных на ускоренный переход органов государственной власти и организаций на использование российского программного обеспечения в Российской Федерации». Применяемое в системе программное обеспечение должно соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации, постановления Правительства Российской Федерации от 23 декабря 2024 г. № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц» Прикладное программное обеспечение должно отвечать следующим требованиям: – совместимость программных продуктов в части используемых технических средств, системного программного обеспечения и общесистемной инфраструктуры в пределах требований к техническому обеспечению, а также их информационная совместимость в пределах требований к информационному обмену; – обеспечение трехуровневой архитектуры с разделением на уровень хранения данных (сервер БД), уровень бизнес-логики (сервер приложений) и уровень представления ( 4.4.7.1. Требования к инструментам разработки и процессу контроля версий программного обеспечения 4.4.7.1.1. Система контроля версий Для управления исходным кодом должна использоваться система контроля версий кода, развернутая в инфраструктуре Заказчика. 4.4.7.1.2. Правила именования веток Имя ветки должно соответствовать следующему формату: / / Категории веток: ? feature/ — разработка новой функциональности, а также рефакторинг или удаление существующей; ? fix/ — исправление ошибок; ? hotfix/ — срочные исправления, применяемые в обход стандартного процесса разработки; ? test/ — для проведения экспериментов, не влияющих на основную разработку. Идентификатор задачи: после категории указывается ссылка на задачу (issue) в системе контроля версий кода. Описание: добавляется краткое описание решаемой задачи в формате kebab-case (слова разделяются дефисами, например, add-user-auth). Примеры именования веток: ? feature/#123/add-payment-integration; ? fix/#45/correct-calculation-logic; ? hotfix/#67/urgent-database-connection-patch. 4.4.7.1.3. Правила именования коммитов Сообщение коммита должно соответствовать соглашению Conventional Commits и состоять из категории и описания: : ? fix — исправление ошибки. Примеры сообщений коммитов: ? feat: добавление формы регистрации пользователя; ? fix: исправление ошибки валидации email-адреса; ? refactor: оптимизация алгоритма сортировки данных; ? chore: обновление версий в файле dependencies. 4.4.7.1.4. Модель ветвления В процессе разработки используются следующие основные ветви: ? main / master — стабильная ветка, содержит только код, прошедший полное тестирование и развернутый в продуктивных контурах; ? dev — ветка для интеграции завершенных задач, предназначенная для сборки и тестирования в тестовых средах. Попадание кода в main осуществляется только через Merge Request (MR) из dev 4.2.2. Развитие компонента отчетности (3 очередь) Должна быть обеспечена автоматизация процессов формирования отчетов о ЧС и нештатных ситуациях на транспорте, в т.ч. на основе данных из внешних систем. Включает следующие доработки: – разработка шаблонов отчетов в различных форматах (табличный, текстовый); – реализация выбора фотоматериалов для включения в справку; – форматирование содержимого справок с учетом правил русского языка в отношении окончаний слов (в зависимости от падежа, склонения, числа и рода); – автоматизированное формирование выводов к содержимому справки на основе настраиваемых критериев; – создание интерфейса выбора параметров (фильтрации) для формирования отчетов: o состав полей для включения в отчёт; o настройка диапазонов значений характеристик и дат; o порядок отображения полей; o настройка заголовка. – реализация способа подготовки отчётов в асинхронном режиме (очереди); – реализация интерфейса компонента формирования отчетности для отображения очереди формирования отчетов и статусов их подготовки; – экспорт отчётов в форматы xlsx, csv и справок в форматы pdf, docx. Необходимо разработать не менее 10 шаблонов отчетов и/или справок. Перечень, структура и содержание шаблонов должны быть согласованы с Заказчиком на этапе технического проектирования. 4.2.3. Развитие компонента визуализации (2 очередь) В рамках развития компонента визуализации должны быть выполнены следующие доработки, обеспечивающие: – вывод перечней (списков) сил и средств предупреждения и ликвидации ЧС и нештатных ситуаций на транспорте с отображением мест их постоянного размещения (дислокации) на карте, включая: o отображение зон ответственности на карте; o возможность их фильтрации (по видам транспорта, регионам и пр.); o реализацию инструмента расчета расстояния (с использованием сети автомобильных и железных дорог) между местом события и местами дислокации сил и средств, а также вывода маршрутов на карте; – отображение зон (полигонов) с установленными ограничениями движения в воздушном пространстве на карте; – отображение термических точек; – реализация возможности отображения данных из паспорта региона, отображаемого в модуле iМинтранс (модуль АСУ ТК); – отображение краткой карточки сущностей и ОТИ (краткой информации и/или динамических характеристик объекта) при выборе объекта на карте с возможностью перехода в полную карточку сущности и ОТИ; – отображение данных от Росгидромета, предусматривающих: o отображение неблагоприятных и опасных природных явлений на карте (с заданным периодом обновления данных); o управление отображением явлений на карте, включая настройку состава отображаемых объектов, поиск, фильтрацию, с использованием соответствующей панели управления; o выведение краткой карточки явления при выборе объекта, с возможностью перехода в полную карточку объекта – отображение на карте связанных сущностей и ОТИ; – реализация функции выбора темного и светлого стилей отображения элементов интерфейса, карточек сущностей, картографической основы и объектов, отображаемых на карте; – реализация механизма для выбора картографической основы в одном из распространенных форматов WMTS, TMS, MVT и др. Должна быть предусмотрена возможность настройки перечня картографических основ и параметров доступа к ним; – настройка базового набора дашбордов, содержащих преднастроенные виджеты о количестве событий в разрезе видов транспорта с возможностью перехода к исходным данным (карточкам событий, ОТИ и т.д.), с фильтрацией по параметрам. Параметры фильтрации должны быть определены на этапе технического проектирования. Должно быть обеспечено автоматическое и принудительное обновление данных, отображаемых на дашбордах 4.4.7.1.5. Требования к используемым зависимостям (библиотекам) Все внешние зависимости проекта должны быть зафиксированы с указанием точных версий. Для контроля версий зависимостей в репозиторий обязательно должны быть включены следующие файлы: · Для JavaScript: package-lock.json или yarn.lock; · Для Python: requirements.txt (с зафиксированными версиями) или Pipfile.lock; · Для Go: go.mod и go.sum; Загрузка всех зависимостей должна производиться исключительно через внутренний прокси-репозиторий Заказчика, настроенный в соответствующем системе менеджере пакетов. Запрещается: · Использование плавающих версий (например, ^1.2.3, ~4.5.0, latest); · Использование библиотек, содержащих критические уязвимости, в том числе зарегистрированные в реестре CVE (Common Vulnerabilities and Exposures). 4.4.7.1.6. Требования к процессу непрерывной интеграции (CI) Сборка программного обеспечения, включая этапы компиляции, тестирования и анализа кода, должна выполняться исключительно в инфраструктуре непрерывной интеграции Заказчика. 4.4.7.1.7. Требования к хранению артефактов сборки Все артефакты сборки (результирующие пакеты, Docker-образы и т.д.) подлежат обязательному хранению в предназначенной для этого инфраструктуре Заказчика (артефакторий). Запрещается размещение финальных артефактов сборки на сторонних ресурсах 4.4.8. Требования к техническому обеспечению Количество серверов, подключаемых и настраиваемых сервисов, их параметров, схемы соединений и настройки межсетевого взаимодействия должны быть согласованы с Заказчиком на этапе № 1 Техническое проектирование. Доступ к комплексу технических средств предоставляется Заказчиком по письменному запросу Подрядчика. Применяемые в Системе программно-аппаратные и аппаратные комплексы должны соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации», требованиям Постановления Правительства Российской Федерации от 23 декабря 2024 г. № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц». Модуль СЦ, работающий в составе АСУ ТК, развернут на вычислительных мощностях ГЦОД СИЦ Минтранса России 4.5. Общие технические требования 4.5.1. Требования к численности и квалификации персонала и пользователей Модуля СЦ Программное обеспечение Модуля СЦ не должно требовать изменения штатной численности персонала Заказчика. Программное обеспечение Модуля СЦ не должно требовать наличия у пользователей дополнительной квалификации в сфере информационных технологий, кроме базовых знаний в обращении с персональным компьютером, базовых навыков работы в интернет-обозревателях и знаний о Модуле СЦ в объеме документов Руководство пользователя, Руководство администратора 4.2.4. Создание компонента «Интерактивная карта» (2 очередь) В составе создаваемого компонента должны отображаться данные, доступные в компоненте визуализации. Требования к интерфейсу интерактивной карты: – интерактивная карта должна быть представлена в виде объемной карты с учетом макетов, представленных в Приложении А к ТЗ; – интерфейс должен корректно отображаться на экранах мониторов (разрешение Full HD 1920?1080), телевизоров (разрешение 4К 3840?2160), жидкокристаллических панелей для видеостены, используемой Заказчиком, с параметрами каждой панели: диагональ 55 дюймов, разрешение 1920x1080; – интерфейс должен корректно отображаться на планшетных устройствах с диагональю экрана 10-12 дюймов, конкретные требования должны быть уточнены на этапе технического проектирования; – должна быть обеспечена кластеризация и генерализация отображения объектов на карте при изменении масштаба; – должно быть обеспечено отображение основных характеристик объектов при выборе их на карте; – должно быть обеспечено управление отображением слоев на карте; – должна быть обеспечена настройка цветовой индикации отображаемых объектов транспортной инфраструктуры; – должно быть обеспечено отображение легенды карты, содержащей отображаемые объекты на карте; – должна быть обеспечена возможность одновременного отображения не менее 5 000 ОТИ и ТС на карте. На интерактивной карте должны быть отображены подвижные объекты совместно с объектами транспортной инфраструктуры (ОТИ), включая следующие возможности: § отображение местоположения транспортных средств (воздушный, водный и автомобильный транспорт) на карте в режиме реального времени (с заданным периодом обновления данных); § отображение маршрутов движения всех ТС за выбранный период времени, в том числе с использованием эффектов анимации; § отображение маршрутов движения ТС, связанных с карточкой события: ТС, являющихся участниками события, и ТС, находящиеся в заданном радиусе от события; § управление отображением сущностей и ОТИ на карте, включая настройку состава отображаемых объектов, поиск, фильтрацию, с использованием соответствующей панели управления и наглядным представлением результатов; § автоматическое изменение вида отображения объектов (цветовая индикация) по заданным условиям (например, при достижении критических значений параметров, характеризующих функционирование объекта); Должна обеспечиваться производительность обновления изображения на экране в 30 кадров в секунду на тестовой конфигурации пользовательского устройства (модель Бештау AIO2402/B560, входящая в Реестр российской промышленной продукции под номером 10394100 или аналог) при одновременном отображении не менее 5 000 объектов и 200 уникальных моделей объектов. Макеты интерфейсов Модуля СЦ должны быть предварительно согласованы с Заказчиком и разработаны с учетом требований ГОСТ Р ИСО 9241-161-2016 «Элементы графического пользовательского интерфейса» 4.5.2. Требования к режимам функционирования Модуля СЦ Модуль СЦ должен предусматривать наличие следующих режимов работы: – штатный; – регламентный (профилактический); – аварийный. Основным режимом функционирования является штатный. В штатном режиме все компоненты корректно и полностью выполняют свои функции. Перерывов в работе как Модуля СЦ в целом, так и одного, либо нескольких компонентов не предусмотрено. Режим регламентного (профилактического) обслуживания предназначен для проведения работ по обновлению и техническому обслуживанию компонентов Модуля СЦ, а также резервному копированию данных. При работе в данном режиме допускаются перерывы в работе Модуля СЦ с предварительным информированием пользователей. Состав процедур по регламентному обслуживанию Модуля СЦ и их периодичность определяются Подрядчиком в процессе выполнения работ по созданию Модуля СЦ. В режиме регламентного (профилактического) обслуживания Модуль СЦ может функционировать с частичным ограничением своих функциональных возможностей, либо без ограничения, но со снижением показателей надежности и производительности. Перевод в данный режим работы должен осуществляться сразу после начала выполнения любой операции, отнесенной к этому режиму, с последующим возвратом в штатный режим функционирования сразу после ее завершения. Перевод в указанный режим должен осуществляться при возникновении необходимости проведения работ по обновлению и техническому обслуживанию компонентов Модуля СЦ, а также резервному копированию данных с условием предварительного оповещения пользователей. Аварийный режим функционирования характеризуется отказом одной или нескольких подсистем, вызванных выходом из строя аппаратного и/или программного обеспечения, а также в случае временной неработоспособности каналов связи между серверами. В аварийном режиме осуществляется поиск неисправностей и проведение работ по их устранению. Перевод в аварийный режим должен осуществляться при возникновении сбоев, аварий и прочих незапланированных воздействий, сразу после наступления одной или нескольких аварийных ситуаций, с последующим возвратом в штатный режим функционирования сразу после окончания восстановительных работ. ПО Модуля СЦ должно обладать надежностью, обеспечивающей работу пользователей в произвольном режиме и оперативное восстановление работоспособности при сбоях. В целях обеспечения надежного функционирования ПО должно предусматривать: – сохранение целостности данных при нештатном завершении работы компонентов Модуля СЦ; – сохранение работоспособности программного обеспечения при некорректных действиях пользователя; – резервное копирование базы данных Модуля СЦ. – время восстановления работоспособности Модуля СЦ после отказа не более 4 часов. – отказоустойчивость на уровне 99% при единовременной количестве не менее 200 пользовательских сессий в Модуле СЦ. Указанные характеристики приведены без учета характеристик надежности инфраструктуры и времени передачи информации по каналам связи. При возникновении сбоев в аппаратном обеспечении, включая аварийное отключение электропитания, Модуль СЦ должен автоматически восстанавливать свою работоспособность (не требовать перенастройки) после устранения сбоев и корректного перезапуска аппаратного обеспечения 4.2.4.1. Требования к технической реализации компонента «Интерактивная карта» При реализации компонента «Интерактивная карта» должны учитываться требования, указанные ниже. 4.2.4.1.1. Требования к отображению элементов Повторяющихся элементы карты (ТС, ОТИ, события и пр.) должны отрисовываться с использованием аппаратного создания экземпляров объектов на пользовательском устройстве (WebGL/WebGPU)). Отрисовка каждого объекта отдельным запросом не допускается, должна обеспечиваться возможность одновременного отображения не менее 5 000 объектов без снижения производительности (30 кадров в секунду на тестовой конфигурации). 4.2.4.1.2. Уровни детализации объектов Для управления отображением сложных объектов должно быть создано не менее 3-х уровней детализации, отображаемых при изменении масштаба с возможностью автоматического переключения между уровнями. Все отображаемые объекты должны масштабироваться с учетом разрешения экрана пользователя с сохранением качества детализации. 4.2.4.1.3. Полигональная оптимизация и текстурирование При реализации компонента «Интерактивная карта» должна обеспечиваться технология рельефного тестурирования объектов. Не должны использоваться высокополигональные трехмерные модели. Все повторяющиеся элементы должны генерироваться единоразово и повторно использоваться при последующих отображениях. 4.2.4.1.4. Управление памятью Требуется реализовать потоковую загрузку на устройство пользователя элементов карты и текстур. Загрузка данных целиком при старте приложения не допускается. Необходимо реализовать механизм очистки памяти от элементов, которые находятся вне области видимости камеры в течение заданного времени. 4.2.4.1.5. Требования к взаимодействию пользователя с интерфейсом компонента «Интерактивная карта» Программная реализация механизмов управление камерой (масштабирование и навигация) должна быть выполнена с поддержкой технологии WebAssembly (WASM). Элементы управления должны являться неотъемлемой частью интерактивной карты. 4.2.5. Развитие компонента администрирования (3 очередь) Должна быть выполнена доработка ролевой модели. Ролевая модель должна обеспечивать управление доступом к отдельным объектам Модуля СЦ и их элементам (атрибутам) с разграничением по видам транспорта, регионам и пр., в частности: – определение набора конкретных действий, доступных пользователям (выполняемых над объектом доступа, например, удаление записи, редактирование записи, формирование отчета и др.); – реализация возможности объединения пользователей в группы; – определение прав доступа для групп пользователей; – реализация интерфейса визуальной настройки прав доступа пользователей к объектам Модуля СЦ Технические меры по обеспечению надежности должны предусматривать: – резервирование критически важных компонентов и данных Системы и отсутствие единой точки отказа; – использование программного резервирования (программной избыточности); – изменение конфигурации используемых средств и применение специализированного ПО, обеспечивающего высокую надёжность. Организационные меры по обеспечению надежности должны быть направлены на минимизацию ошибок пользователей (а также обслуживающего персонала при эксплуатации и проведении работ по обслуживанию), минимизацию времени ремонта или замены вышедших из строя компонентов за счёт: – обеспечения для обслуживающего персонала требуемого уровня квалификации; – регламентации и нормативного обеспечения выполнения работ обслуживающим персоналом; – своевременной диагностики неисправностей. Расчетное значение коэффициента доступности Модуля СЦ должно составлять не менее 0,95. 4.5.3. Требования по диагностированию Модуля СЦ Диагностирование Модуля СЦ должно осуществляться путем анализа записей в системных журналах СУБД, операционных систем серверов, а также с помощью встроенных средств диагностирования общего программного обеспечения Модуля СЦ. Диагностированию подлежат: – сбои и нарушения функционирования технического обеспечения (серверов) Модуля СЦ; – сбои и нарушения функционирования системного программного обеспечения серверов, используемых для работы Модуля СЦ; – сбои и нарушения функционирования прикладного программного обеспечения серверов, используемых для работы Модуля СЦ; – случаи недоступности (отсутствия ответа) или некорректные ответы внешних систем; – сбои и нарушения функционирования СУБД; – сбои при выполнении регламентных операций резервного копирования. При возникновении аварийных ситуаций либо ошибок в программном обеспечении диагностические инструменты должны позволять сохранять набор информации, необходимой для идентификации и устранения проблемы. Модуль СЦ и ее компоненты должны обеспечивать возможность диагностики своей работоспособности с возможностью интеграции с модулем мониторинга АСУ ТК. Набор передаваемых журналов и метрик должен быть определен на этапе технического проектирования 4.5.4. Требования к надежности Должно быть предусмотрено сохранение работоспособности Модуля СЦ при некорректных действиях пользователя и сохранение целостности данных при нештатном завершении работы Модуля СЦ (отказ рабочей станции, потеря сетевого доступа и т.п.). Модуль СЦ должен предоставлять механизмы обеспечения сохранности данных через применение процедур резервного копирования и восстановления, описанных в документации на Систему. Ключевые показатели надежности информационной системы — допустимое время на восстановление работоспособности Модуля СЦ (RTO - recovery time objective) и/или допустимый интервал времени потери изменений в данных при сбоях/отказах (RPO – recovery point objective) должны быть определены Подрядчиком и согласованы с Заказчиком на этапе технического проектирования 4.2.6. Взаимосвязи с внешними автоматизированными системами (1 очередь) Способы взаимодействия с внешними информационными системами должны быть определены на этапе технического проектирования. Должны быть выполнены следующие доработки: – интеграции с информационными ресурсами в целях получения данных о движении подвижных ТС (воздушные суда, суда водного транспорта); – интеграция с информационным ресурсом в целях получения данных о событиях на железнодорожном транспорте. Реализация интеграций должна включать проектирование и реализацию интеграционных механизмов обмена данными с учетом доступных вариантов реализации, обеспечение защищенных способов взаимодействия, настройку отображения отдельных данных на карте (настройка слоев). Взаимодействия, имеющие каналы связи, выходящие за пределы контролируемой зоны взаимодействующих систем, считаются защищенными, если для их защиты используются программные и/или программно-аппаратные шифровальные (криптографические) средства, сертифицированные ФСБ России (далее – СКЗИ). Выбор СКЗИ, схемы подключения и требуемого класса криптостойкости должен производиться в соответствии с Техническими условиями на подключение к информационным ресурсам ФГБУ «СИЦ Минтранса России» и инструкциями по подключению пользователей к ресурсам инфраструктуры Головного центра обработки данных, утвержденных приказом директора ФБГУ «СИЦ Минтранса России» от 24.05.2024 № 21-ОД 4.3. Требования к оказанию услуг по технической поддержке Модуля СЦ 4.3.1. Общие требования к оказанию Услуг Техническая поддержка Модуля СЦ должна осуществляться с учетом требований постановления Правительства Российской Федерации от 06.07.2015 N 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации». Подрядчик обязан выполнять требования законодательства в сфере защиты информации, требования по защите информации, информационной безопасности, указанные в локальных нормативных актах ФГБУ «СИЦ Минтранса России», регламентирующих условия информационного взаимодействия, защиты информации и подключения к информационным ресурсам ФГБУ «СИЦ Минтранса России», участвующих в информационном взаимодействии в рамках оказания услуг по технической поддержке АСУ ТК в 2026 году 4.3.1.1. Требования к составу и содержанию услуг третьего уровня технической поддержки Оказание услуг по технической поддержке Системы осуществляется в рамках этапов в соответствии с календарным планом. Подрядчик в течение 5 рабочих дней с даты заключения Контракта должен предоставить со своей стороны, а Заказчик со своей стороны Матрицу ответственных за взаимодействия в соответствии с Приложением 1 к Регламенту оказания услуг по третьему уровню технической поддержки Модуля СЦ (далее – Регламент, Приложение В). Подрядчик в течение 10 рабочих дней с даты заключения Контракта должен провести мероприятия по организации третьего уровня технической поддержки в соответствии с Регламентом. Услуги по третьему уровню технической поддержки Модуля СЦ должны включать: – организацию Подрядчиком третьего уровня технической поддержки; – информационно-консультационную поддержку работников Заказчика; – решение инцидентов, связанных с работой ППО; – адаптационное, конфигурационное и коррекционное сопровождение Модуля СЦ (в рамках действующих программных модулей и функциональности); – устранение уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности 4.5.5. Требования к информационной безопасности Работы по защите информации/информационной безопасности, не включенные в состав настоящего раздела, требуемые в соответствии с требованиями постановления Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации», а также нормативно правовых актов в области защиты персональных данных и обеспечения безопасности объектов критической информационной инфраструктуры, будут проведены в рамках исполнения отдельного контракта, заключенного по результатам отдельной закупочной процедуры (не является частью данного ТЗ), включающего: – определение актуальных угроз безопасности информации и актуализация модели угроз безопасности информации (при необходимости); – выполнение требований о согласовании технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России в установленном порядке; – выполнение требований по устранению Подрядчиком замечаний и недостатков, в случае их выявления при согласовании Заказчиком технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России; – выполнение требований к классу защищенности ГИС, уровню защищенности персональных данных и категории значимости объекта КИИ РФ, установленных для Головного центра обработки данных ФГБУ «СИЦ Минтранса России» (далее – ГЦОД); – определение перечня объектов защиты информационной системы; – описание (актуализированных) требований к системе защиты информации, а также к мерам защиты информации информационной системы в зависимости от установленных классов защищенности, уровня защищенности персональных данных и категории значимости объектов КИИ РФ (приказы ФСТЭК России № 21, 117, 239); – выполнение требований к мерам по защите ГИС от атак, направленных на отказ в обслуживании, в соответствии с пунктами 30, 34, 59, 63 Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений, утвержденных приказом ФСТЭК России от 11.04.2025 № 117; – описание (актуализированных) требований по защите информации, подлежащих реализации в информационно телекоммуникационной инфраструктуре ГЦОД; – выполнение требований о применении сертифицированных средств защиты информации, включая их классы защиты и уровни доверия; – выполнение требований о запрете использования с 01.01.2025 органами (организациями) средств защиты информации странами происхождения, которых являются иностранные государства в соответствии с пунктом 6 Указа Президента Российской Федерации от 01.05.2022 № 250; – выполнение требований по обеспечению непрерывного взаимодействия с ГосСОПКА в установленном порядке; 4.3.1.2. Требования к общему порядку оказания услуг Техническая поддержка Модуля СЦ должна быть организована на трех уровнях: – первый и второй уровни технической поддержки организуется Заказчиком; – третий уровень технической поддержки организуется Подрядчиком. Перечень действий на каждом уровне технической поддержки указан в Таблице 5: Таблица 5 – Перечень действий на каждом уровне технической поддержки Уровень технической поддержки Доступные действия Условия передачи задачи на следующий уровень Первый уровень технической поддержки (далее – 1-й уровень) – принимает обращения (заявки) пользователей Модуля СЦ и работников Заказчика; – регистрирует обращения в Модуле СЦ регистрации обращений; – присваивает уникальный идентификационный номер, классифицирует обращения; – самостоятельно решает обращения, которые связаны с недостаточной квалификацией пользователей или настройками в рамках своей компетенции; – взаимодействует с пользователями Модуля СЦ при решении проблемы Передает обращение на второй уровень поддержки в случае невозможности решения на своем уровне Второй уровень технической поддержки (далее – 2-й уровень) – принимает обращения от 1-го уровня; – уточняет классификацию обращения в результате дополнительного анализа; – самостоятельно решает обращения в рамках своей компетенции; – осуществляет техническую и консультационную поддержку Модуля СЦ; – взаимодействует с сотрудниками 1-го и 3-го уровня и пользователями Модуля СЦ; – формирует заявки для 3-го уровня и контролирует исполнение Передает обращение на третий уровень поддержки в случае невозможности решения на своем уровне Третий уровень технической поддержки (далее – 3-й уровень) – принимает обращения от 2-го уровня; – обеспечивает выполнение требований, предъявляемых Контрактом и настоящим Техническим заданием к Услугам, оказываемым Подрядчиком Все поступающие обращения должны быть исполнены Подрядчиком Для обеспечения взаимодействия с Заказчиком Подрядчик со своей стороны определяет ответственных лиц, уполномоченных в структуре Подрядчика за своевременное и качественное оказание Услуг в рамках настоящего ТЗ, а также контактную информацию ответственных лиц (телефон, электронную почту). Подрядчик должен предоставить Заказчику единый адрес электронной почты для приема обращений (заявок) в течение 3 (трех) рабочих дней после заключения Контракта. Указанный в настоящем пункте адрес электронной почты (способ направления обращений (заявок) применяется в случае сбоя в работе СРО Заказчика. Со своей стороны, Заказчик предоставляет Подрядчику перечень и контактную информацию (телефон, электронную почту) уполномоченных лиц для осуществления взаимодействия с указанием зон ответственности. О любых изменениях в контактной информации ответственных лиц Стороны должны уведомить друг друга в течение 1 (одного) рабочего дня с момента возникновения таких изменений посредством уведомления на электронную почту ответственных лиц и/или в письменной форме. В результате оказания услуг по настоящему ТЗ не должны быть изменены исходные коды, дистрибутивы и иные компоненты Модуля СЦ вне согласованных с Заказчиком изменений. Любые изменения исходных кодов, дистрибутивов и иных компонентов Модуля СЦ должны производиться только после согласования с Заказчиком уполномоченными лицами по электронной почте или иным заранее согласованным способом. Не должна быть ухудшена надежность и производительность Модуля СЦ. Оказание услуг по Контракту не должно нарушать требования к информационной безопасности, описанной в документации на Модуль СЦ – выполнение требований по обеспечению в автоматизированном режиме с Национальной системой противодействия DDoS-атакам (НСПА) Центра мониторинга и управления сетью связи общего пользования ФГУП «ГРЧЦ» в рамках реализации мер по защите ГИС от атак, направленных на отказ в обслуживании; – детализированные требования к составу и содержанию работ по аттестации, а также к их результатам в соответствии с пунктами 13, 15 и 16 требований приказа ФСТЭК России от 29.04.2021 № 77 «Об утверждении Порядка организации и проведения работ по аттестации объектов информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну» 4.5.5.1. Требования к безопасности исходного кода Процесс разработки исходного кода должен соответствовать требованиям законодательства, нормативным правовым актам Российской Федерации, приказу ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по безопасности значимых объектов критической информационной инфраструктуры Российской Федерации», а также учитывать отраслевые практики безопасной разработки. Подрядчик должен предоставить Заказчику Руководство по безопасной разработке программного обеспечения (далее – Руководство), применяемое при разработке исходного кода Модуля СЦ. Руководство должно содержать: · описание процесса безопасной разработки и ролевой модели, отражающей зоны ответственности сотрудников Подрядчика; · описание процессов моделирования, оценки и формирования мер предотвращения угроз, применяемых Подрядчиком; · описание методик, применяемых Подрядчиком при разработке исходного кода (правила написания кода); · описание методик, периодичности проведения и инструментария статического, динамического, композитного и фаззинг тестирования исходного кода, включающего критерии отбора релизных версий ПО, применяемые Подрядчиком в процессе разработки; · описание механизмов безопасности в процессе сборки и доставки (безопасность образов, безопасность секретов, безопасность окружения и сборочной среды), применяемые Подрядчиком; · утвержденные шаблоны отчетной документации (в том числе акты), в соответствии с которыми Заказчик принимает результаты проверок (артефакты сборочного процесса), проведенных Подрядчиком; · описание процедур отслеживания и исправления обнаруженных ошибок и уязвимостей программного обеспечения; · описание способов и сроков доведения Подрядчиком до Заказчика информации об уязвимостях программного обеспечения, о компенсирующих мерах по защите информации или ограничениях по применению программного обеспечения, способов получения пользователями программного обеспечения его обновлений, проверки их целостности и подлинности Подрядчик должен обеспечить реализацию и проведение внутренних проверок мер по разработке безопасного ПО, приведенных в Руководстве. Подрядчик должен провести анализ угроз безопасности информации программного обеспечения в соответствии с ГОСТ 58412-2019 «Защита информации. Разработка безопасного программного обеспечения. Угрозы безопасности информации при разработке программного обеспечения». Подрядчик должен провести испытания по выявлению уязвимостей в программном обеспечении Системы: · проведение статического анализа исходного кода программы; · проведение динамического анализа исходного кода программы; · проведение композитного анализа исходного кода и образов программы; · проведение фаззинг-тестирования программы, направленного на выявление в ней уязвимостей. Испытания по выявлению уязвимостей в программном обеспечении Системы должны быть проведены в рамках: · предварительных испытаний; · опытной эксплуатации; · приемочных испытаний Оказание услуг в рамках данного технического задания осуществляется Подрядчиком по обращению (заявке) Заказчика, направляемой посредством СРО Заказчика. Регистрация обращений, поступивших непосредственно в Модуль СЦ регистрации обращений Заказчика, производится сотрудниками Заказчика, которые обеспечивают первый уровень технической поддержки Модуля СЦ. В случае назначения приоритета «Критический» или «Высокий», информация о назначении также дублируется оповещением ответственных представителей Подрядчика посредством звонка на предоставленные номера телефонов. Обращение (заявка) должна содержать следующую информацию: – контакты пользователя/организации; – приоритет обращения, соответствующий Приложению 2 к Регламенту; – время обнаружения; – наименование компонента АСУ ТК - Модуль СЦ; Информация может быть расширена по согласованию с Заказчиком. Обращения (заявки) сотрудников Заказчика должны приниматься Подрядчиком через веб-интерфейс СРО. В процессе обработки обращений (заявок) Подрядчик должен обеспечить выполнение следующих процедур: – прием обращений(заявок) от сотрудников Заказчика; – оказание информационно-консультационной поддержки в соответствии с требованиями настоящего Технического задания; – информирование сотрудников Заказчика о статусе обработки и результатах обработки обращений(заявок). Подрядчик осуществляет обязательную регистрацию и учет всех обращений и заявок, поступивших к Подрядчику от представителей Заказчика в рамках оказания настоящих услуг Примечание: в случае приостановки работы по обращению или заявке (обращение или заявка находится в статусе «Приостановлено»), указываются причины, по которым работы по обращению или заявке приостановлены с указанием перечня действий/информации, запрошенных у инициатора обращения, а также даты, формы и адресата такого запроса. В случае отклонения обращения или заявки (заполняется в случае, если обращению или заявке присваивается статус «Отклонено»), указываются подробно причины такого отклонения, а также фиксируется дата и время перехода в статус «Отклонено». В случае, если обращение или заявка отклонены (отменены) самим Инициатором, то указывается дата и способ, которым от инициатора получено соответствующее уведомление. В случае невыполнения Подрядчиком регламентного времени реагирования или решения обращения (заявки) Заказчик вправе отозвать обращение и направить его Подрядчику повторно. При этом каждое отозванное обращение учитывается в Отчёте об оказанных услугах, как обращение с превышением времени реагирования или решения, но оплате не подлежит. В случае, если обращение (заявка) связано с некачественным выполнением Подрядчиком другой задачи, такое обращение решается в регламентное время, установленное Техническим заданием, при этом оплате такие обращения не подлежат, о чем указывается в Отчете об оказанных услугах в графе «Примечание» По результатам анализа угроз безопасности информации программного обеспечения и испытаний по выявлению уязвимостей в программном обеспечении Системы должна быть предоставлена отчетная документация по формам, утвержденным в Руководстве, и артефакты сборочной среды, подтверждающие проведение испытаний по выявлению уязвимостей в программном обеспечении Систем. Уязвимости подлежат устранению в сроки, обозначенные Заказчиком. В случае обнаружения уязвимого компонента Подрядчик должен заменить/обновить библиотеки. В случае, если уязвимость не подлежит исправлению на программном уровне, Подрядчик должен разработать меры предотвращения угроз безопасности, в том числе правила безопасности для наложенных средств защиты, рекомендации по безопасной настройке конфигурации для устранения потенциальных уязвимостей и снижения рисков информационной безопасности. Уязвимости, найденные ФСБ России, ФСТЭК России, Минцифры России, Роскомнадзором в ходе исполнения Контракта, а также в течение гарантийного периода, должны быть устранены Подрядчиком за свой счет в сроки, согласованные с Заказчиком 4.5.6. Требования к эргономике и технической эстетике Взаимодействие пользователей с Модулем СЦ должно осуществляться посредством визуального графического интерфейса. Ввод-вывод данных, прием управляющих команд и отображение результатов их исполнения должны выполняться в интерактивном режиме. Интерфейс должен быть рассчитан на преимущественное использование манипулятора типа «мышь», то есть управление Модулем СЦ должно осуществляться с помощью набора экранных меню, кнопок, значков и т. п. элементов. Клавиатурный режим ввода должен использоваться главным образом при заполнении и/или редактировании текстовых и числовых полей экранных форм. Все надписи экранных форм, а также сообщения, выдаваемые пользователю (кроме системных сообщений), должны быть на русском языке. Модуль СЦ должен обеспечивать проверку вводимых пользователем данных и предупреждать о некорректно введённых значениях Экранные формы должны проектироваться с учетом требований унификации: – все экранные формы пользовательского интерфейса должны быть выполнены в едином графическом дизайне, с одинаковым расположением основных элементов управления и навигации; – для обозначения сходных операций должны использоваться сходные графические элементы, кнопки и другие управляющие (навигационные) элементы. Термины, используемые для обозначения типовых операций, а также последовательности действий пользователя при их выполнении должны быть унифицированы; – внешнее поведение сходных элементов интерфейса (реакция на наведение указателя «мыши», переключение фокуса, нажатие кнопки) должно реализовываться одинаково. Структура размещения информации и представление этой структуры в Модуле СЦ должны соответствовать следующим требованиям: – пункты меню в пользовательском веб-интерфейсе должны быть сгруппированы в соответствии с тематикой информации, функциональными задачами и технологией работы; – каждому пункту меню должна соответствовать только одна выполняемая функция; – при совершении пользователями ошибочных действий должны выдаваться сообщения об ошибках. Эскизы визуального оформления компонента «Интерактивная карта» представлены в Приложении А. 5. СОСТАВ И СОДЕРЖАНИЕ РАБОТ ПО РАЗВИТИЮ И ТЕХНИЧЕСКОЙ ПОДДЕРЖКЕ МОДУЛЯ СЦ (КАЛЕНДАРНЫЙ ПЛАН) Сдача-приемка результатов выполненных работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная техническая документация, а также результаты работ предоставляются Заказчику в порядке, предусмотренном Контрактом и ТЗ, до размещения Подрядчиком в ЕИС документа о приемке. Документ о приемке размещается в ЕИС по каждому этапу в соответствии с условиями Контракта. Этапы выполнения работ по развитию Модуля СЦ приведены в Таблице 11. Таблица 11. Этапы выполнения работ по развитию Модуля СЦ. № этапа Наименование этапа Результат (отчетная документация) Срок исполнения этапа Значение характеристики не может изменяться участником закупки 1 Техническое проектирование Сопроводительным письмом предоставляются Заказчику: · Технический проект, включая следующие документы: – Ведомость технического проекта; – Ведомость машинных носителей информации – Пояснительная записка; – Описание информационного обеспечения системы; – Описание автоматизируемых функций; – Схема функциональной структуры; – Описание организации информационной базы; – Описание программного обеспечения; · Макеты экранных форм компонента «Интерактивная карта»; · Руководство по безопасной разработке программного обеспечения; · Документ о приемке Начало: с даты заключения контракта Окончание: не позднее 31.07.2026 2 Услуги по технической поддержке Модуля СЦ (с даты заключения контракта по 10.09.2026) По окончании оказания Услуг сопроводительным письмом предоставляются Заказчику: – Отчет об оказанных Услугах по технической поддержке; – Актуальные на дату окончания оказания Услуг по данному этапу исходные коды прикладного ПО на электронном носителе (в случае внесения изменений); – Инструкция по сборке и развертыванию (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство пользователя (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство администратора (в случае внесения изменений); – Документ о приемке Начало: с даты заключения контракта Окончание: не позднее 10.09.2026 3 Разработка программного обеспечения (1 очередь, пп. 4.2.1, 4.2.6 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ; – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 1 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 1 очереди; – Руководство по резервному копированию; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 16.09.2026 4 Разработка программного обеспечения (2 очередь, пп. 4.2.3, 4.2.4 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ. – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 2 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 2 очереди; – Руководство по резервному копированию; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 25.09.2026 5 Разработка программного обеспечения (3 очередь, пп. 4.2.2, 4.2.5 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ; – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 3 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 3 очереди; – Руководство по резервному копированию; – Описание ролевой модели; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 09.10.2026 6 Опытная эксплуатация (1 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акт о завершении опытной эксплуатации 1 очереди; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке 17.09.2026 Окончание: не позднее 26.10.2026 7 Опытная эксплуатация (2 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акт о завершении опытной эксплуатации 2 очереди; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке 26.09.2026 Окончание: не позднее 26.10.2026 8 Опытная эксплуатация (3 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Акт о завершении опытной эксплуатации 3 очереди; – Документ о приемке Начало: с 10.10.2026 Окончание: не позднее 26.10.2026 9 Приемочные испытания Сопроводительным письмом предоставляются Заказчику: – Программа и методика приёмочных испытаний; – Протокол приемочных испытаний; – Исходные коды и дистрибутивы на электронном носителе (при условии внесения изменений, с учетом доработок по результатам опытной эксплуатации и проведенных испытаний); – Комплект рабочей документации на Модуль СЦ (при условии внесения изменений, с учетом доработок по результатам опытной эксплуатации и проведенных испытаний); – Акт приемки Системы в эксплуатацию; – Акт приемки-передачи исключительных прав на объект; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке; – Документы в соответствии с разделом 4.5.9 ТЗ; – Обеспечение гарантийных обязательств Начало: с 27.10.2026 Окончание: не позднее 10.11.2026 10 Услуги по технической поддержке Модуля СЦ (с 11.09.2026 по 15.12.2026) По окончании оказания Услуг сопроводительным письмом предоставляются Заказчику: – Отчет об оказанных Услугах по технической поддержке; – Актуальные на дату окончания оказания Услуг по данному этапу исходные коды прикладного ПО на электронном носителе (в случае внесения изменений); – Инструкция по сборке и развертыванию (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство пользователя (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство администратора (в случае внесения изменений); – Документ о приемке Начало: с 11.09.2026 Окончание: не позднее 15.12.2026 Работы по развитию Системы (за исключением этапов проведения опытной эксплуатации и услуг по технической поддержке) могут быть выполнены досрочно. При досрочном выполнении работ (этапов работ) Подрядчик в письменной форме уведомляет Заказчика о готовности представить для приемки результаты проведения работ в соответствии с требованиями Контракта. Подрядчик также вправе досрочно приступать к работам в рамках очередного этапа при наличии технической, организационной готовности - при условии получения соответствующего согласования Заказчиком. Сдача-приемка результатов выполненных работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная, техническая документация, а также результаты Работ по каждому этапу предоставляется Заказчику в порядке, предусмотренном Контрактом и настоящим Техническим заданием, до размещения Подрядчиком в Единой информационной системе в сфере закупок документа о приемке. Документ о приемке размещается в ЕИС по каждому этапу в соответствии с условиями Контракта. Согласование документов осуществляется в электронном виде посредством переписки с адресов электронной почты Заказчика и Подрядчика, указанных в контракте. 6. ПОРЯДОК РАЗРАБОТКИ МОДУЛЯ СЦ Проектирование Модуля СЦ должно включать разработку следующих документов: – Ведомость технического проекта; – Ведомость машинных носителей информации – Пояснительная записка; – Описание информационного обеспечения системы; – Описание автоматизируемых функций; – Схема функциональной структуры; – Описание организации информационной базы; – Руководство по безопасной разработке программного обеспечения; – Описание программного обеспечения; – Макеты экранных форм компонента «Интерактивная карта». Структура документов должна соответствовать ГОСТ Р 59795-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов». Разработка Модуля СЦ должна включать в себя: – разработку программного обеспечения в части новых функций Модуля СЦ; – сборка исходного кода, развертывание и настройку доработанного программного обеспечения Модуля СЦ на вычислительных мощностях Заказчика (тестовый контур); – Комплект рабочей документации на Модуль СЦ; – разработку документа «Программа и методика предварительных испытаний»; – разработку документа «Программа и методика приемочных испытаний»; – разработку документа «Программа опытной эксплуатации». Структура документов должна соответствовать ГОСТ Р 59795-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов». В ходе выполнения работ формируется правоустанавливающая, отчетная, рабочая и техническая документация в соответствии с Контрактом и Календарным планом, приведенном в разделе 5. Значение характеристики не может изменяться участником закупки 6.1. Сведения о гарантийном обслуживании Модуля СЦ Под гарантией понимается устранение Подрядчиком своими силами и за свой счет допущенных по его вине недостатков, выявленных после приемки выполненных Работ, как в работе самой Модуля СЦ, так и недостатков в отчетной документации. Если в период гарантийного срока обнаружатся недостатки, то Подрядчик обязан устранить их за свой счет, в сроки, установленные Заказчиком. Гарантийный срок в этом случае продлевается на период устранения недостатков. Срок гарантии: 1 год с даты приемки Заказчиком результатов исполнения Этапа № 9 контракта. Подрядчиком должны быть внесены соответствующие исправления в техническую и рабочую документацию (указанную в пунктах 5 и 6 настоящего ТЗ), связанные с устранением замечаний к работе Модуля СЦ или в случае выявления Заказчиком недостатков в такой документации в период гарантийного срока. Внесение изменений в документацию технического и рабочего проектирования осуществляется в соответствии с ГОСТ 2.503-2023 и ГОСТ Р 2.504-2021. 7. ПОРЯДОК КОНТРОЛЯ И ПРИЕМКИ РЕЗУЛЬТАТОВ ВЫПОЛНЕНИЯ РАБОТ ПО РАЗВИТИЮ МОДУЛЯ СЦ Испытания должны быть организованы и проведены в соответствии с ГОСТ Р 59792-2021 «Информационная технология. Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем». Должны быть проведены следующие виды испытаний: – предварительные испытания; – опытная эксплуатация; – приемочные испытания. Указанные виды испытаний проводятся в отношении не функциональных требований и функциональных возможностей, разрабатываемых в соответствии с настоящим ТЗ. Отдельные виды испытаний проводятся поэтапно в сроки, установленные Календарным планом. Предварительные испытания, опытная эксплуатация, приемочные испытания проводятся комиссией, создаваемой организационно-распорядительным документом Заказчика, который должен определять состав комиссии, порядок ее работы. Методы предварительных испытаний и порядок их проведения должны быть определены в документе «Программа и методика предварительных испытаний», который должен быть утвержден Заказчиком до начала предварительных испытаний. По результатам предварительных испытаний оформляется Протокол предварительных испытания и Акт о приемке в опытную эксплуатацию. Порядок проведения и методы испытаний во время опытной эксплуатации должны быть определены в документе «Программа опытной эксплуатации», который должен быть утвержден Заказчиком до начала опытной эксплуатации. Ход и результаты опытной эксплуатации отражаются в документе «Журнал опытной эксплуатации», и учитываются в ходе приемочных испытаний. По результатам опытной эксплуатации подписывается Акт о завершении опытной эксплуатации Значение характеристики не может изменяться участником закупки До момента подключения внешних ИС, Подрядчиком могут быть использованы эмуляторы ИС для прохождения предварительных испытаний, опытной эксплуатации и приемочных испытаний. В рамках опытной эксплуатации должны быть проведены мероприятия по нагрузочному тестированию Модуля СЦ. Документ «Программа и методика приемочных испытаний» должен быть разработан с учетом недостатков, выявленных в ходе опытной эксплуатации, утвержден Заказчиком до начала приемочных испытаний, при этом проверки Модуля СЦ в части не устраненных недостатков, выявленных в процессе опытной эксплуатации, должны быть вынесены в отдельный раздел «Программы и методики приемочных испытаний». В процессе приемочных испытаний должно быть проверено устранение недостатков, полученных в ходе опытной эксплуатации. После завершения устранения всех замечаний, препятствующих приемке Системы в эксплуатацию, перечисленных в Протоколе приемочных испытаний, Подрядчик должен письменно уведомить Заказчика о том, что все замечания устранены, после чего приемочные испытания по решению Заказчика могут быть проведены повторно. Процедура приемочных испытаний проводится до подписания Протокола приемочных испытаний, не содержащего замечаний, препятствующих приемке Системы в эксплуатацию. Приемочные испытания Системы считаются завершенными успешно, если Протокол приемочных испытаний не содержит замечаний, препятствующих приемке Системы в эксплуатацию 8. ТРЕБОВАНИЯ К СОСТАВУ И СОДЕРЖАНИЮ РАБОТ ПО ПОДГОТОВКЕ МОДУЛЯ СЦ К ВВОДУ В ЭКСПЛУАТАЦИЮ По результатам проведения приемочных испытаний оформляется Протокол приемочных испытаний и Акт приемки в эксплуатацию. В случае, если взаимодействие с внешними системами не может быть проверено на средах постоянной эксплуатации взаимодействующих систем (по причине неготовности со стороны внешней системы или иным причинам), функции взаимодействия, разработанные в соответствии с требованиями ТЗ, должны быть проверены на тестовых данных с использованием программ-имитаторов взаимодействия. По результатам выполнения этапа приемочных испытаний должны быть подготовлены материалы для регистрации доработанной версии Модуля СЦ (объекта учета) в НФАП в соответствии с требованиями постановления Правительства Российской Федерации от 30 января 2013?г. №?62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин» (с изменениями и дополнениями) в части обязательности размещения результатов работ в национальном фонде алгоритмов и программ для электронных вычислительных машин. Сдача-приемка результатов выполнения Работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная, техническая документация, а также программное обеспечение предоставляется Заказчику в порядке, предусмотренном Контрактом и ТЗ до размещения Подрядчиком в Единой информационной системе в сфере закупок документа о приемке. Результаты проведения опытной эксплуатации, предварительных и приемочных испытаний должны быть зафиксированы в соответствующих протоколах и актах. Выявленные отклонения от настоящего ТЗ, оформляются как недостатки Модуля СЦ Значение характеристики не может изменяться участником закупки Протоколы предварительных и приемочных испытаний должны содержать вывод о соответствии Модуля СЦ предъявляемым требованиям, а также сроки устранения замечаний и реализации рекомендаций, сформулированных комиссией в ходе предварительных и приемочных испытаний. Условием для передачи Модуля СЦ в промышленную эксплуатацию является устранение всех замечаний. Документация на Модуль СЦ и ее части (техническая и рабочая) должна содержать исчерпывающее описание принятых проектных решений в объеме, достаточном для ее дальнейшего развития и эксплуатации. Техническая и рабочая документация должна содержать описание разработанных результатов работ, в том числе программ для ЭВМ, прикладных программных интерфейсов, алгоритмов и протоколов информационного взаимодействия, технических требований, спецификаций и форматов обмена данными для взаимодействия с другими информационными системами, в объеме, достаточном для их установки, настройки, эксплуатации и развития в дальнейшем без привлечения Подрядчика. Исходные коды передаются в виде и составе, позволяющем провести: – сборку (компиляцию) Модуля СЦ в контролируемой Заказчиком среде; – установку полученной Модуля СЦ на специально подготовленную контролируемую Заказчиком инфраструктуру; – проверку функциональных возможностей Модуля СЦ; – оформление Модуля СЦ в качестве объекта национального фонда алгоритмов и программ для электронных вычислительных машин 8.1. Требования, предъявляемые в соответствии с Приказом Минцифры России от 17.12.2020 № 715 «Об утверждении типовых условий контрактов на выполнение работ по созданию и (или) развитию (модернизации) государственных (муниципальных) и (или) иных информационных систем» Передача исходных кодов, разработанных в ходе выполнения работ, программ для электронных вычислительных машин (далее – программа для ЭВМ) должна сопровождаться передачей всех необходимых для сборки и запуска программы для ЭВМ библиотек зависимостей, программных сценариев (скриптов) для проведения установки (развертывания) программы для ЭВМ. Подрядчик в процессе сдачи-приемки работ по Контракту должен провести демонстрацию процесса и установки (развертывания) разработанных программ для ЭВМ. Документация на Модуль СЦ должна содержать описание принятых проектных решений в объеме, достаточном для ее дальнейшего развития и эксплуатации 9. ТРЕБОВАНИЯ К ДОКУМЕНТИРОВАНИЮ 9.1. Общие требования Документация на Модуль СЦ должна быть разработана в составе, указанном в разделах 5-8 данного ТЗ, и должна удовлетворять требованиям комплекса стандартов и руководящих документов на автоматизированные системы: – ГОСТ Р 2.105-2019 в части оформления текстовых документов; – ГОСТ 34.201-2020 в части наименования и обозначения документов. Документация на Модуль СЦ должны оформляться на листах формата А4. Допускается для размещения рисунков и таблиц использование листов формата А3 с подшивкой по короткой стороне листа. Документы объемом более 25 (двадцати пяти) листов должны содержать информационную часть, состоящую из аннотации и содержания. Исходные коды должны быть представлены в 1 (одном) экземпляре на электронном носителе, отчетные материалы должны быть представлены в 2 (двух) экземплярах на бумажном носителе (по одному экземпляру для Заказчика и Подрядчика) и в 1 (одном) экземпляре на электронном носителе в формате документов DOCX и PDF. При разработке документов на Модуль СЦ допускается отклонение от требований комплекса стандартов, описанных выше. Документам на Модуль СЦ должны в обязательном порядке присваиваться уникальные децимальные номера в соответствии с порядком, установленном в ГОСТ 34.201-2020. Документ «Программа и методика предварительных испытаний» должен включать приложения с формой протокола предварительных испытаний и формой акта приемки в опытную эксплуатацию. Документ «Программа опытной эксплуатации» должен включать приложение с формой журнала опытной эксплуатации. Документ «Программа и методика приемочных испытаний» должен включать приложения с формой протокола приемочных испытаний и формой акта приемки в эксплуатацию Значение характеристики не может изменяться участником закупки 10. ИСТОЧНИКИ РАЗРАБОТКИ 10.1. Список литературы Специальная литература для разработки ТЗ не использовалась. 10.2. Нормативно-методические документы Список используемых нормативно-методических документов представлен в разделе 1.6 технического задания. ? Приложение А Эскизы визуального оформления компонента «Интерактивная карта» Значение характеристики не может изменяться участником закупки Приложение Б Параметры оказания услуг Б.1. Базовые параметры оказания Услуг Базовые параметры оказания Услуг приведены ниже: – режимы оказания Услуг (таблица Б.1.1); – сроки предоставления отчетности (таблица Б.1.2). Таблица Б.1.1 - Режимы оказания Услуг № п/п Параметр Значение Значение характеристики не может изменяться участником закупки 1 Режим работы Системы Круглосуточно (24х7) 2 Режим доступности информационно-консультационной поддержки пользователей Системы 2.1 Прием и регистрация обращений (заявок) в СРО Регистрация обращений (заявок) производится круглосуточно в режиме 24х7, без праздников и выходных дней. Обработка заявок первой линией поддержки осуществляется в рабочие дни с 9 до 18 часов 2.2 Консультирование сотрудников Заказчика и пользователей Системы в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 3 Режим доступности по решению инцидентов, связанных с работой ППО: 3.1 - приоритет «Критический» Круглосуточно (24х7) 3.2 - приоритет «Высокий» Круглосуточно (24х7) 3.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 3.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4 Режим доступности услуг по адаптации, конфигурации и коррекционному сопровождению Системы 4.1 - приоритет «Критический» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.2 - приоритет «Высокий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 5 Режим доступности по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности 5.1 - приоритет «Критический» Круглосуточно (24х7) 5.2 - приоритет «Высокий» Круглосуточно (24х7) 5.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 5.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) Таблица Б.1.2. Сроки предоставления отчетности, с момента получения запроса № п/п Параметр Значение 1 Предоставление отчета об оказанных услугах за произвольный период 10 рабочих дней 2 Предоставление подробной информации по инциденту с приоритетом «Критический» 16 рабочих часов 3 Предоставление актуализированной документации 10 рабочих дней Б.2. Приоритеты и регламентные сроки решения обращений (заявок) В зависимости от уровня сбоя в работе Системы обращению (заявке) присваивается один из следующих приоритетов, а также в зависимости от приоритета обращения (заявки) устанавливаются следующие контрольные сроки решения в соответствии с таблицей ниже (Таблица Б.2.1). Таблица Б.2.1 – Приоритеты и регламентные сроки решения обращений (заявок) № п/п Приоритет Максимальное время реагирования Время решения (срок выполнения) Описание приоритета По информационно-консультационной поддержке сотрудников Заказчика и пользователей Системы 1 - не более 1 часа не более 10 часов - По решению инцидентов, связанных с работой ППО: 1 Критический не более 30 минут не более 4 часов - полная недоступность ППО; - недоступность ключевых функций - ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО; - невозможность информационного обмена с ППО для ИС более 4 часов 2 Высокий не более 1 часа не более 8 часов - ошибки/сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; - снижение быстродействия СПО (время отклика ППО на операции превышает 30 секунд); - недоступность управления правами и ролями пользователей 3 Средний не более 4 часов не более 24 часов - невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым -недоступность функции формирования отчетов 4 Низкий не более 8 часов не более 40 часов - отклонение в работе ППО, не влияющее на корректную работу функций; - другие сбои и ошибки, затрагивающие основные функции ППО По адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) 1 Критический не более 40 минут не более 8 часов - изменения, необходимые при проведении аварийно-восстановительных работ для возобновления работоспособности Системы; - изменения, связанные с критичными ошибками, блокирующими возможность оказания государственных услуг и/или чтение и внесение данных в Систему 2 Высокий не более 1 часа не более 40 часов - изменения, относящиеся к обеспечению работоспособности основной функциональности Системы, устраняют выявленные дефекты в работе Системы, оказывающие существенное влияние на работу пользователей в Системе; - изменения, затрагивающие три и более подсистемы/модуля Системы для адаптации 3 Средний не более 4 часов не более 72 часов - изменения, связанные с развитием/улучшением/оптимизацией Системы и выводом новой функциональности в штатном режиме для одного-двух модулей/подсистем; - изменения, связанные с развитием интеграционных механизмов Системы, например обновление существующих и/или реализация новых видов сведений СМЭВ, обновление существующих и/или реализация новых API, адаптация и/или изменение механизмов импорта и экспорта данных Системы и т.д. 4 Низкий не более 8 часов не более 160 часов - изменения, связанные с ошибками/корректировкой/изменением в отображении информации в пользовательском графическом интерфейсе Системы (графика, текст, органы управления, элементы интерфейса) По устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности 1 Критический не более 30 минут не более 24 часов - критические уязвимости, влияющие на возможную полную недоступность ППО, ключевых функций Системы, ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО без возможности восстановления работоспособности Системы. - Критический уровень CVSS > 8.0 2 Высокий не более 1 часа не более 84 часов - критические уязвимости, влияющие на ошибки и сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО. - Высокий уровень CVSS 5.0 - 8.0 3 Средний не более 4 часов не более 120 часов - уязвимости, влияющие на невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым - Средний уровень CVSS 2.0 - 4.9 4 Низкий не более 8 часов не более 160 часов - уязвимости, влияющие на отклонение в работе ППО, не влияющее на корректную работу функций; - другие сбои и ошибки, затрагивающие основные функции ППО - Низкий уровень CVSS < 2.0 Взаимодействие Заказчика и Подрядчика в части регистрации и контроля времени реагирования и решения обращения (заявки) осуществляется через СРО. Заказчик предоставляет Подрядчику доступ к СРО после заключения Контракта. Поступившие от разных пользователей заявки по поводу однотипных инцидентов или имеющие общую причину должны объединяться в одну заявку. Срок выполнения включает время диагностики инцидента, в ходе которого определяется причина инцидента (проблемы) и способ его устранения. Подрядчик должен обеспечить функционирование Модуля СЦ в соответствии с требованиями и параметрами, указанными в настоящем ТЗ и Регламенте оказании услуг. Основные параметры быстродействия типовых операций в Модуле СЦ указаны в таблице ниже (таблица Б.2.2). Таблица Б.2.2 - Параметры быстродействия Модуля СЦ № п/п Наименование параметра Значение (секунд) 1 Среднее время получения сообщения из очереди сообщений 10 2 Среднее время получения ответа от Системы 5 3 Среднее время открытия карточки реестра 5 Приложение В Регламент оказания услуг 2.2 Общее описание процесса оказания сопровождения (технической поддержки) Системы Процесс оказания технической поддержки Системы включает: 1. Поступление обращений (заявок) от пользователей и их регистрацию. 2. Сопровождение обращений (заявок) в соответствии с их классификацией и приоритизацией, в том числе, с их последующей эскалацией. 3. Определение ролей и регламент их взаимодействия при осуществлении деятельности по процессу. 4. Решение обращений (заявок) в установленные настоящим Регламентом сроки. 5. Взаимодействие между 1-м, 2-м и 3-м уровнями технической поддержки, в том числе, с формированием заданий для сопровождения Системы. 6. Контроль качества выполняемых Исполнителем работ, состоящий из проверки сценария, приводящего к ошибке, зафиксированной в Инциденте, и/или к ошибке воспроизведения, а также тестирование внесенных изменений в рамках ЗНИ. 7. Обеспечение мониторинга и проведение анализа процесса обработки поступающих в техническую поддержку обращений (заявок). Техническая поддержка реализуется путем проведения ответственными сотрудниками соответствующей информационно-консультационной деятельности в соответствии с определенными ролями, а также выполнения Исполнителем конкретных действий по своевременному выявлению причин сбоев и аварийных ситуаций и их устранению, а также по адаптации, конфигурированию, корректировке Системы, включая выполнение процедур тестирования и участия в обновлениях Системы. Все роли подразделяются на уровни поддержки, взаимодействующие между собой в соответствии с блок-схемой процесса технической поддержки. Общая схема процесса рассмотрения обращений (заявок) в соответствии с видами технической поддержки представлена на рисунке 1. . Рисунок 1 - Общая схема процесса рассмотрения обращений (заявок) в соответствии с видами технической поддержки Значение характеристики не может изменяться участником закупки 2.3 Каналы связи Должна быть предусмотрена омниканальность в части приема обращений (заявок). Получение обращений (заявок) технической поддержкой происходит по следующим каналам связи: – СРО; – электронная почта; – телефонная линия. Исполнитель обеспечивает прием обращений (заявок) от Заказчика и предоставляет информацию в рамках оказания услуг по техническому сопровождению Системы, руководствуясь матрицей взаимодействия, приведенной в Приложении 1 к настоящему Регламенту 3 Порядок оказания Услуг 3.1 Типы обращений (заявок) Обращения и заявки Заказчика классифицируются в соответствии с приоритетами и регламентными сроками, указанными в Приложении 2 к настоящему Регламенту. Регистрация обращений и заявок предусматривает создание новой записи в СРО с присвоением поступившему обращению или заявке (новой записи) уникального идентификатора. Запись в СРО должна содержать вопрос или проблему, которую требуется решить или оказать консультацию. Если обращение или заявка автоматически зарегистрированы в СРО при отправке представителем Заказчика, Исполнитель проверяет корректность указанного типа обращения (заявки) и может обратиться к Заказчику с просьбой корректировки, предоставив обоснования в соответствии с настоящей классификацией (Таблица 1) Таблица 1 - Типы обращений (заявок) Тип обращения (заявки) Описание Запрос на обслуживание Подготовка SQL запроса к СУБД для решения прикладной задачи и д р. – запрос на любое действие, не являющееся запросом информации и несовершенный на основе происшествия, прямо или косвенно влияющего на работу Системы Консультация (входит в тип обращения (заявки) «Запрос на обслуживание») «Где взять / куда обратиться...?», «Как сделать / выполнить…», «Как это работает…?» - запрос, имеющий своей целью получение информационной поддержки Инцидент Разбор ошибок/сбоев и подготовка материалов (корректировочных релизов, инструкций) для Заказчика для устранения ошибок/сбоев, которые приводят к частичному и полному нарушению работоспособности всех или отдельных функций ППО. Подготовка изменения и материалов, необходимых для проведения аварийно-восстановительных работ для возобновления работоспособности Системы. ЗНИ Подготовка изменений, связанных с изменением, улучшением/оптимизацией Системы и выводом новой модифицированной функциональности в штатном режиме. Подготовка изменений, связанных с модификацией существующих и/или реализация новых интеграционных механизмов для получения/обработки данных внешних систем. Подготовка изменений графического интерфейса по требованиям Заказчика 3.2 Участники технической поддержки, осуществляющие сопровождение обращений (заявок) Техническая поддержка Системы должна быть организована на трех уровнях: 1. Первый и второй уровни технической поддержки организуется Заказчиком. 2. Третий уровень технической поддержки организуется Исполнителем. Зона ответственности каждого уровня технической поддержки указана в Таблице 2. Таблица 2 - Зона ответственности каждого уровня технической поддержки Участники технической поддержки Описание Первый уровень технической поддержки (далее – 1-й уровень) Группа ответственных сотрудников 1-го уровня Заказчика, осуществляющая прием и первичную обработку обращений (заявок) (описание предмета обращения, первичная классификация и приоритизация, определение назначения, маршрутизация обращений (заявок) по назначению), руководствуется в своей работе настоящим Регламентом и БЗ, наполняемой 2-м уровнем поддержки, самостоятельно решает часть обращений (заявок), связанных с недостаточной квалификацией пользователей или настройками в рамках своей компетенции. В случае невозможности решения обращений (заявок) на 1-ом уровне ответственный сотрудник передает ее на 2-й уровень Второй уровень технической поддержки (далее – 2-й уровень) Группа ответственных сотрудников 2-го уровня Заказчика по установленным компетенциям (информационная безопасность, сопровождение и эксплуатация информационно-аналитических систем, развитие информационно-аналитических систем, техническая поддержка информационно-аналитических систем) отвечает за поддержание работоспособности Системы, обработку обращений (заявок) и их решение в регламентные сроки в соответствии с установленными приоритетами. Осуществляет информационно-консультационную поддержку пользователей Системы в рамках своей компетенции. Оказывает экспертную помощь ответственным сотрудникам 1-го уровня в части формирования БЗ, содержащей ответы на часто задаваемые вопросы пользователей, с целью передачи знаний, навыков и инструментария на 1-й уровень для ускорения решения обращений (заявок). В случае невозможности решения обращения (заявки) на 2-ом уровне ответственный сотрудник передает его на 3-й уровень. При выявлении необходимости изменений в ППО Системы инициирует формирование обращения (заявки) и направляет его на группу ответственных сотрудников 3-го уровня по соответствующему классификатору (ЗНО, ЗНИ, и т.д.) Третий уровень технической поддержки (далее – 3-й уровень) Группа ответственных сотрудников Исполнителя, отвечающая за устранение сбоев и аварий, проведение информационно-консультационной поддержки пользователей Системы, проведение адаптации и конфигурирования Системы в объемах действующих контрактов на оказание технической поддержки 3.3 Перечень и описание статусов обращений (заявок) В Таблице 3 приведен перечень статусов обращений (заявок), действующий в СРО, и их описание. Таблица 3 - Перечень статусов обращений (заявок) и их описание Статус Описание Зарегистрирован Обращение (заявка) принято и зарегистрировано Направлен в группу Присваивается при назначении ответственными сотрудниками 1-го уровня группе ответственных сотрудников 2-го уровня по тематике обращения (заявки) после заполнения всей необходимой информации и полей обращения (заявки), а также при его передаче между группами 2-го уровня Передан в группу Присваивается при передаче обращения (заявки) ответственными сотрудниками 2-го уровня на группу ответственных сотрудников 3-го уровня Назначен Присваивается при назначении обращения (заявки) на ответственного сотрудника для его решения в рамках компетенции В работе Присваивается при приеме обращения (заявки) в работу ответственным сотрудником для его решения Решен Присваивается ответственным сотрудником, выполнившим работы по обращению (заявке) Закрыт Присваивается автоматически при решении запроса по обращению (заявке), а также отсутствии дополнительных запросов пользователя в соответствии с действующим SLA, или при подтверждении решения обращения (заявки) со стороны пользователя Запрос доп. информации Присваивается при необходимости запроса дополнительной информации и/или уточнения предмета обращения по обращению (заявке) у пользователя Ответ предоставлен Присваивается после ответа пользователем на запрос дополнительной информации Отклонен Присваивается, если обращение (заявка) не актуальна (по информации от пользователя), отсутствует техническая возможность решения обращения (заявки), предмет обращения не входит в компетенции технической поддержки, или существует влияние доработки на другие компоненты, что нарушает общий порядок работы Системы Согласование Присваивается при необходимости согласования направления обращения (заявки) ответственным сотрудником Заказчика на 3-й уровень Анализ Присваивается при проведении анализа на предмет возможности внесения изменений, связанных с развитием/улучшением/оптимизацией Системы и выводом новой функциональности и оценке ресурсоемкости Тестирование Присваивается Исполнителем при завершении разработки и проведенном предварительном тестировании для последующего осуществления приемочного тестирования Специалистом 2-го уровня Релиз Присваивается ответственным сотрудником Заказчика при принятии решения о возможности вывода доработки в продуктивную среду Утверждение заказчиком Присваивается при согласовании группой профильных специалистов на 2-м уровне поддержки с пользователем технического задания для внесения изменений, связанных с развитием/улучшением/оптимизацией Системы и выводом новой функциональности Доработка Присваивается в случае несогласования Заказчиком работ, проведенных Исполнителем в рамках контрактных обязательств, по внесению изменений, связанных с развитием/улучшением/оптимизацией Системы и выводом новой функциональности в штатном режиме, и необходимости последующего направления Исполнителю для ее доработки Отложен Присваивается в случае невозможности выполнения запроса, изложенного в обращении (заявке), в связи с необходимостью запроса дополнительной информации у третьих сторон 3.4 Порядок регистрации и сопровождения Заявок Порядок регистрации и сопровождения обращений (заявок) в рамках оказываемых услуг по технической поддержке Системы зависит от типа обращения (заявки): 1. Услуга по решению инцидентов, связанных с работой ППО – тип обращения (заявки) «Инцидент». 2. Услуга по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности – тип обращения (заявки) «Инцидент». 3. Услуга информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы – тип обращения (заявки) «Запрос на обслуживание» (в том числе, консультационный запрос). 4. Услуга адаптационного, конфигурационного и коррекционного сопровождения Системы (в рамках действующих программных модулей и функциональностей) – тип обращения (заявки) «Запрос на изменение». В случае недоступности СРО взаимодействие и информирование Исполнителем о ходе оказания услуги по обращению (заявке), изменению статусов обращений (заявок) осуществляется по согласованию с Заказчиком в соответствии с матрицей взаимодействия, представленной в Приложении 1 к настоящему Регламенту. 3.4.1 Инцидент На рисунке 2 представлена функциональная схема регистрации и сопровождения обращений (заявок) типа «Инцидент». Рисунок 2 - Функциональная схема регистрации и сопровождения обращений (заявок) типа «Инцидент» 3.4.2 Запрос на обслуживание На рисунке 3 представлена функциональная схема регистрации и сопровождения обращения (заявки) типа «ЗНО». Рисунок 3 - Функциональная схема регистрации и сопровождения обращения (заявки) типа «ЗНО» 3.4.3 Запрос на изменение На рисунке 4 представлена функциональная схема регистрации и сопровождения обращений (заявок) типа «ЗНИ». Рисунок 4 - Функциональная схема регистрации и сопровождения обращений (заявок) типа «ЗНИ» 3.5 Порядок классификации и приоритизации обращений (заявок) Классификация является начальной стадией процесса оказания технической поддержки, необходимой для идентификации обращения (заявки) и определения соответствующих действий для его обработки. Для проведения первичной классификации необходимо получить от пользователя и зафиксировать в описании обращения (заявки) подробные сведения о сути запроса, в том числе, для Инцидентов зафиксировать сценарий воспроизведения обнаруженной ошибки. Для проведения вторичной классификации необходимо провести анализ и диагностику для определения корневой причины и затронутой Инцидентом функциональной области (инфраструктура, сеть, ППО). В процессе классификации осуществляется первичная диагностика и оценка проблемы, описанной пользователем Системы в обращении (заявке), в части функционирования и/или удобства использования Системы. Корректная классификация позволяет увеличить скорость обработки обращения (заявки) и решения описанной в обращении (заявке) проблемы при минимальном привлечении ресурсов, в частности, за счет использования известных решений для типовых обращений (заявок), которые должны описываться в БЗ СРО. Классификация позволяет произвести первоначальное назначение обращения (заявки) на ответственного сотрудника и выставить приоритет с учетом приоритизации. Приоритизация применяется для определения критичности описанной в обращении (заявке) проблемы для функционирования ППО Системы. Приоритет рассмотрения обращения (заявки) определяется в процессе ее классификации на основании ряда параметров, вводимых при заполнении обращения (заявки). Приоритизация используется для того, чтобы при одновременном наличии нескольких обращений (заявок) в первую очередь рассматривалась обращения (заявки) с наивысшим приоритетом и не позднее установленных для данного приоритета сроков Изменение приоритета уже зарегистрированного обращения (заявки) используется в случае появления новых обстоятельств, которые ведут к изменению влияния и/или срочности существующего обращения (заявки). При регистрации обращения (заявки) необходимо провести его приоритизацию. В процессе управления обращениями (заявками) каждому обращению (заявке) присваивается приоритет, принимающий одно из значений: Низкий, Средний, Высокий или Критический. В соответствии с приоритетом определяется время, очередность устранения, , ресурсы, привлекаемые для работ по обращению (заявке), а также может определяться порядок/процедура действий при работе с обращением (заявкой). Заказчиком в зависимости от уровня сбоя в работе Системы обращению (заявке) присваивается приоритет с указанием максимального времени реакции и решения в соответствии с требованиями, указанными в Приложении 2 к настоящему Регламенту 4 Формы обращений (заявок) на оказание услуг по технической поддержке Системы, заполняемые в СРО 4.1. Форма обращения (заявки) на оказание услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы При подаче обращения (заявки) типа «ЗНО» в СРО указывается (Таблица 5): Таблица 5 – Описание атрибутов формы обращения (заявки) на оказание услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 5) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 5) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 5) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 5) Категория обращения: информационно-консультационная поддержка Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 5) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 5) Текст запроса на оказание услуги по информационно-консультационной поддержке сотрудников Заказчика Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 5) На рисунке 5 приведена форма обращения (заявки) типа «ЗНО» в СРО. Рисунок 5 - Форма обращения (заявки) типа «ЗНО» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы, заполненную в свободной форме. 4.2. Форма обращения (заявки) на оказание услуги по решению инцидентов, связанных с работой ППО При подаче обращения (заявки) типа «Инцидент» в СРО указывается (Таблица 6): Таблица 6 – Описание атрибутов формы обращения (заявки) на оказание услуги по решению инцидентов, связанных с работой ППО Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 6) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 6) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 6,) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 6) Категория обращения (заявки): инцидент Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 6) Приоритет изменения Время - одно из значений: Низкий, Средний, Высокий или Критический. Определяет, очередность решения обращения (заявки), ресурсы, привлекаемые для решения обращения (заявки), порядок/процедура действий при решении обращения (заявки) – поле СРО «Приоритет» (см. рисунок 6,) Тип изменения Справочник, классифицирующий типовые запросы характерные для Системы – поле СРО «Предмет обращения» (см. рисунок 6) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 6) Полное описание инцидента, включая скриншоты и описание шагов, приведших к неисправности Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 6) Однократность/неоднократность Круг пользователей или компьютеров, затронутых данным инцидентом Действия, предпринятые для самостоятельного решения инцидента (при наличии) Версии используемого программного обеспечения на клиентской рабочей станции, где воспроизводится ошибка (операционная система, прикладное программное обеспечение) Дополнительная информация На рисунке 6 приведена форма обращения (заявки) типа «Инцидент» в СРО. Рисунок 6 - Форма обращения (заявки) типа «Инцидент» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуги по решению инцидентов, связанных с работой ППО, заполненную в свободной форме 4.3. Форма обращения (заявки) на оказание услуг по адаптационному конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) При подаче обращения (заявки) типа «ЗНИ» в СРО указывается (Таблица 7): Таблица 7 – Описание атрибутов формы обращения (заявки) на оказание услуг по адаптационному, конфигурационному и коррекционному сопровождению Системы Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 10) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 9) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 10) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 10) Категория обращения (заявки): запрос на изменение Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 7) Приоритет изменения Время, очередность решения обращения (заявки), ресурсы, привлекаемые для решения обращения (заявки), порядок/процедура действий при решении обращения (заявки) – поле СРО «Приоритет» (см. рисунок 7) Тип изменения Справочник, классифицирующий типовые запросы характерные для Системы – поле СРО «Предмет обращения» (см. рисунок 7) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 7) Текст запроса на оказание услуги по адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 7) На рисунке 7 приведена форма обращения (заявки) типа «ЗНИ» в СРО. Рисунок 7 - Форма обращения (заявки) типа «ЗНИ» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуг по адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей), заполненную в свободной форме 4.4. Форма обращения (заявки) на оказание услуги по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности При подаче обращения (заявки) типа «Инцидент» в СРО указывается (Таблица 8): Таблица 8 – Описание атрибутов формы обращения (заявки) на оказание услуг по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 8) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 8) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 8) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 8) Категория обращения (заявки): инцидент Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 8) Приоритет Время, очередность решения обращения (заявки), ресурсы, привлекаемые для решения обращения (заявки), порядок/процедура действий при решении обращения (заявки) – поле СРО «Приоритет» (см. рисунок 8) Тип изменения Справочник, классифицирующий типовые запросы характерные для Системы – поле СРО «Предмет обращения» (см. рисунок 8) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 8) Текст запроса на оказание услуги по обновлению или удалению уязвимых компонентов (библиотек) ППО в соответствии с требованиями к обеспечению информационной безопасности Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 8) На рисунке 8 приведена форма обращения (заявки) типа «Инцидент» в СРО. Рисунок 8 - Форма обращения (заявки) типа «Инцидент» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуги по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности, заполненную в свободной форме Приложение 1 к Регламенту Матрица ответственных за взаимодействия в рамках выполнения работ по техническому сопровождению Системы Таблица 1 – Ответственные за взаимодействия в рамках выполнения работ по техническому сопровождению Системы со стороны Исполнителя ФИО Должность Адрес электронной почты Телефон — — — Общий контакт Приложение 2 к Регламенту Приоритеты и регламентные сроки решения обращений (заявок) Приоритеты и регламентные сроки решения обращений (заявок) приведены в таблице 1. Таблица 1 – Приоритеты и регламентные сроки решения обращений (заявок) № п/п Приоритет Максимальное время реагирования Время решения (срок выполнения) Описание приоритета По информационно-консультационной поддержке сотрудников Заказчика и пользователей Системы 1 – не более 1 часа не более 10 часов – По решению инцидентов, связанных с работой ППО 1 Критический не более 30 минут не более 4 часов – полная недоступность ППО; – недоступность ключевых функций; – ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО; – невозможность информационного обмена с ППО для ИС более 4 часов 2 Высокий не более 1 часа не более 8 часов – ошибки/сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; – снижение быстродействия СПО (время отклика ППО на операции превышает 30 секунд); – невозможность управления правами и ролями пользователей 3 Средний не более 4 часов не более 24 часов – невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым недоступность функции формирования отчетов 4 Низкий не более 8 часов не более 40 часов – отклонение в работе ППО, не влияющее на корректную работу функций; – другие сбои и ошибки, затрагивающие основные функции ППО По адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) 1 Критический не более 40 минут не более 8 часов – изменения необходимые при проведении аварийно-восстановительных работ для возобновления работоспособности Системы; – изменения, связанные с критичными ошибками, блокирующими возможность оказания государственных услуг и/или чтение и внесение данных в Систему 2 Высокий не более 1 часа не более 40 часов – изменения относящиеся к обеспечению работоспособности основной функциональности Системы, устраняют выявленные дефекты в работе Системы, оказывающие существенное влияние на процесс оказания государственных услуг и работу пользователей в Системе; – изменения, затрагивающие три и более подсистемы/модуля Системы для адаптации 3 Средний не более 4 часов не более 72 часов – изменения, связанные с развитием/улучшением/оптимизацией Системы и выводом новой функциональности в штатном режиме для одного-двух модулей/подсистем; – изменения, связанные с развитием интеграционных механизмов Системы, например, обновление существующих и/или реализация новых видов сведений СМЭВ, обновление существующих и/или реализация новых API, адаптация и/или изменение механизмов импорта и экспорта данных Системы и т.д. 4 Низкий не более 8 часов не более 160 часов – изменения, связанные с ошибками/ корректировкой/изменение в отображении информации в пользовательском графическом интерфейсе Системы (графика, текст, органы управления, элементы интерфейса) По устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности 1 Критический не более 30 минут не более 24 часов – критические уязвимости, влияющие на возможную полную недоступность ППО, ключевых функций Системы, ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО без возможности восстановления работоспособности Системы; – Критический уровень CVSS > 8.0 2 Высокий не более 1 часа не более 84 часов – критические уязвимости, влияющие на ошибки и сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; – Высокий уровень CVSS 5.0 - 8.0 3 Средний не более 4 часов не более 120 часов – уязвимости, влияющие на невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым; – Средний уровень CVSS 2.0 - 4.9 4 Низкий не более 8 часов не более 160 часов – уязвимости, влияющие на отклонение в работе ППО, не влияющее на корректную работу функций; – другие сбои и ошибки, затрагивающие основные функции ППО; – Низкий уровень CVSS < 2.0 Приложение Г Форма Отчета об оказанных услугах Отчет об оказанных услугах за этап «наименование этапа» в период с «__» _________ по «__» _________. № п/п Наименование услуги Общее количество Номер ОРС Краткое Описание Время реагирования по ТЗ Время реагирования фактическое Время решения по ТЗ Время решения фактическое Результат соблюдения времени реагирования Результат соблюдения времени решения Примечание 1 Услуги по информационно-консультационной поддержке работников Заказчика 2 546782 Консультация по работе Модуля СЦ 1 2 10 часов 11 часов Нет Нет 567123 Консультация по схеме БД 1 1 10 часов 1 час Да Да 2 … … Заказчик Подрядчик /Должность/ /Должность/ ____________________ /Ф.И.О/ ___________________ /Ф.И.О/ М.П. М.П. «_____»_______________________202_г. «_____»_______________________202_г Приложение 1 к Отчету об оказанных услугах Журнал обращений (заявок) на оказание услуги по информационно-консультационной поддержке пользователей Системы (шаблон) Наименование Исполнителя в этапе «наименование этапа» в период с ________________ по _______________ оказал(о) Услугу по поддержке пользователей Системы в объеме, указанном в Таблице 1 Таблица 1 - Журнал обращений (заявок) пользователей Системы № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. ИТОГО зарегистрировано: Всего обращений (заявок): ________ ИТОГО решено: Всего обращений (заявок): ________ Приложение 2 к Отчету об оказанных услугах Журнал обращений (заявок) по решению инцидентов, связанных с работой ППО (шаблон) Наименование Исполнителя в этапе «наименование этапа» в период с ________________ по _______________ оказал(о) Услугу по решению инцидентов в объеме, указанном в Таблице 1. Таблица 1 - Журнал по решению инцидентов № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. ИТОГО зарегистрировано: Всего инцидентов: ________ ИТОГО решено: Всего инцидентов: ________ Приложение 3 к Отчету об оказанных услугах Журнал обращений (заявок) выполнения адаптационного, конфигурационного и коррекционного сопровождения Системы (шаблон) Журнал выполнения адаптации, конфигурации и коррекции Системы сформирован за этап «наименование этапа» в период с «__» _________ по «__» ____________ и представлен в таблице ниже (Таблица 1). Таблица 1 - Журнал выполнения адаптации, конфигурации и коррекции сопровождения Системы № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. Количество выполненных заявок за этап: ________ Приложение 4 к Отчету об оказанных услугах Журнал обращений (заявок) по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности (шаблон) Журнал обращений (заявок) по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности сформирован за этап «наименование этапа» в период с «__» _________ по «__» ____________ и представлен в таблице ниже (Таблица 1). Таблица 1 - Журнал выполнения заявок по устранению уязвимостей в ППО № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. Количество выполненных заявок за этап: ________ Приложение Д Форма Протокола проверки результатов организационно-штатных и подготовительных мероприятий (шаблон) Протокол проверки результатов организационно-штатных и подготовительных мероприятий Настоящий Протокол содержит результаты проверки организационно-штатных и подготовительных мероприятий, проведенных Исполнителем (Таблица Д.1). Таблица Д.1. Протокол проверки результатов № Мероприятия Подготовительного этапа Результат проверки 1. Определить и направить Заказчику документ «Ответственные за взаимодействия в рамках выполнения работ по техническому сопровождению Системы со стороны Исполнителя». Документ содержит контактную информацию (ФИО, должность, адрес электронной рабочей почты, номер телефона) не менее чем о 2 лицах, ответственных за оказание услуг со стороны Подрядчика Выполнено/Не выполнено 2. Обеспечить подключение специалистов Подрядчика к Системе Выполнено/Не выполнено 3. Обеспечить подключение специалистов Подрядчика к СРО Выполнено/Не выполнено Заказчик Подрядчик /Должность/ /Должность/ ____________________ /Ф.И.О/ ___________________ /Ф.И.О/ М.П. М.П. «_____»_______________________202_г. «_____»_______________________202_г Термины и сокращения В настоящем регламенте используются следующие термины и сокращения на русском и английском языках: Термины/сокращения Полное наименование/описание БЗ (База знаний) База данных Системы регистрации обращений (заявок), созданная для сбора, хранения и поиска способов решения известных проблем в рамках Системы Жизненный цикл обращения (заявки) Совокупность статусов, по которым проходит обращение (заявка), и правила перехода обращения (заявки) из одного статуса в другой Заказчик ФГБУ «СИЦ Минтранса России» – Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» ЗНИ Запрос на изменение – тип заявки, предполагающий внесение изменений в прикладное программное обеспечение Системы ЗНО Запрос на обслуживание – тип заявки, предполагающий работы по предоставлению консультации, предоставление доступа к Системе или стандартизированные типовые изменения конфигураций Системы Инцидент Тип заявки, классифицируемый как нештатное событие в работе компонентов функциональных задач Системы, которое привело или может привести к нарушению или снижению качества функционирования Системы ИС Информационная система Исполнитель Организация, которая определяется по результатам конкурсных процедур Классификация Анализ и заполнение классификационных полей справочными значениями, определяющими последовательность действий и этапов жизненного цикла заявки, а также порядок рассмотрения заявок Консультация Разъяснения по алгоритму работы, требуемых настроек прикладного программного обеспечения и технологии обработки данных при работе с Системой, предоставление информации Маршрутизация Определение процесса движения обращения (заявки) в Системе управления заявками между уровнями технической поддержки и организационными структурами на уровнях поддержки путем назначения обращения (заявки) в соответствии с его классификацией и выставленным приоритетом Обращение (заявка) Устное или письменное обращение пользователя АСУ ТК с вопросом, касающимся работоспособности АСУ ТК, по одному из определённых каналов связи: электронная почта, Система регистрации обращений (заявок) Пользователь Инициатор обращения (заявки) или пользователь Системы ППО Прикладное программное обеспечение Предмет обращения Справочник, классифицирующий типовые запросы в Системе регистрации обращений (заявок), характерные для Системы, выбранное значение определяет маршрутизацию обращения (заявки) (группу ответственных сотрудников) Приоритизация Значение, определяющее время, очередность решения обращений (заявок), ресурсы, привлекаемые для решения обращений (заявок), . Приоритет устанавливается в соответствии с масштабом выявленной проблемы, которая привела или может привести к нарушению или снижению качества функционирования Системы Релиз Выпуск версии прикладного программного обеспечения Системы, от разработки до тестирования и планового обновления Системы на продуктивной среде для установки изменений, связанных с развитием/улучшением/оптимизацией Системы Система, АСУ ТК, Информационно-аналитическая система регулирования на транспорте Информационно-аналитическая система, предназначенная для автоматизации и информационно-аналитического обеспечения процессов управления развитием транспортного комплекса Российской Федерации, обеспечения публичности деятельности органов государственного управления транспортным комплексом, а также обеспечения процессов оказания государственных услуг в электронном виде в сфере транспорта СМЭВ Система межведомственного электронного взаимодействия СПО Системное программное обеспечение СРО Система регистрации обращений (заявок) Статус обращения (заявки) Текущее состояние обращения (заявки) в жизненном цикле процесса оказания технической поддержки Системы СУБД Система управления базами данных Уровень технической поддержки Организационно-структурная часть технической поддержки, имеющая определённые организационно-нормативными документами зоны ответственности, обязанности, а также временные нормативы, в течение которых эти обязательства должны выполняться либо эскалироваться на следующий уровень технической поддержки Услуги Услуги по технической поддержке Информационно-аналитической системы регулирования на транспорте АСУ ТК ФИО Фамилия, имя, отчество Эскалация Процедура повышения внимания к обращению (заявке) путем повышения его приоритета и/или передачи на следующий уровень технической поддержки, а также привлечение ролей, которые могут принимать решения без передачи на следующий уровень технической поддержки API Англ. Application Programming Interface — программный интерфейс приложения, интерфейс прикладного программирования — описание способов (набор классов, процедур, функций, структур или констант), которыми одна компьютерная программа может взаимодействовать с другой программой CVSS Англ. Common Vulnerability Scoring System - открытый стандарт, используемый для расчета количественных оценок уязвимости в безопасности компьютерной системы, обычно с целью понять приоритет ее исправления. В современном инструментарии информационной безопасности используется версия 3.0 и выше с дополнительными метриками к базовым оценкам ID Англ. Identifier – идентификатор, уникальный признак объекта, позволяющий отличать его от других объектов, то есть, идентифицировать SLA Англ. Service Level Agreement - утвержденные условия по обработке обращения (заявки) с установленными метриками времени, которые определяют пороговые значения для эскалации в зависимости от статуса обращения (заявки) (например, время реакции – время от регистрации до осуществления первичной обработки, время решения – время от регистрации обращения (заявки) до его решения и т.д.) SQL Англ. Structured Query Language — «язык структурированных запросов», — декларативный язык программирования, применяемый для создания, модификации и управления данными в реляционной базе данных, управляемой соответствующей СУБД 1 Общие сведения 1.1 Полное наименование Услуг Оказание услуг по технической поддержке Модуля СЦ АСУ ТК в 2026 году. 1.2 Предмет Регламента оказания услуг Требования Технического задания 2 Общие положения 2.1 Цель и задачи оказания услуг Целью технической поддержки Системы является обеспечение ее стабильного и безопасного функционирования и эксплуатации, предупреждение, выявление и устранение сбоев в работе Системы и минимизация их неблагоприятного влияния. Для достижения поставленной цели требуется решение следующих задач: 1. Обеспечение информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы. 2. Поддержание параметров функционирования ППО Системы, удовлетворяющих требованиям производственных процессов, включая их непрерывность. 3. Обеспечение бесперебойного функционирования ППО и своевременное устранение сбоев и аварийных ситуаций в Системе. 4. Своевременное устранение уязвимостей при выявлении таковых, в соответствии с требованиями к обеспечению информационной безопасности. 5. Адаптация, конфигурирование, коррекция программного обеспечения в соответствии с изменениями нормативно-правовой базы и запросами уполномоченных сотрудников органов государственной власти, включая выполнение процедур тестирования и участие в обновлениях ППО на стендах Заказчика. 6. Обеспечение сохранения работоспособности ППО в изменяемой среде эксплуатации. 7. Ведение документации по настоящему контракту и инициирование актуализации документации на Систему по результатам обработки запросов Заказчика и внесения соответствующих изменений в ППО - Наименование характеристики - Значение характеристики - Единица измерения характеристики - Инструкция по заполнению характеристик в заявке - ОПРЕДЕЛЕНИЯ, ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ - Автоматизированная система (АС) Система, состоящая из комплекса средств автоматизации, реализующего информационную технологию выполнения установленных функций, и персонала, обеспечивающего его функционирование (ГОСТ Р 59853-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения») АРМ Автоматизированное рабочее место АСУ ТК, Система Информационно-аналитическая система регулирования на транспорте АТС Автоматическая телефонная станция БД База данных ГИС Государственная информационная система ГОСТ Государственный стандарт ГЦОД СИЦ Минтранса России, ГЦОД Головной центр обработки данных ФГБУ «СИЦ Минтранса России» Дашборд Интерактивная аналитическая панель, графический интерфейс. ЕИС Единая информационная система в сфере закупок ЕСИА Единая система идентификации и аутентификации Заказчик Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» КИИ Критическая информационная инфраструктура Кластер Кла?стер (англ. cluster) – объединение нескольких однородных элементов, которое может рассматриваться как самостоятельная единица, обладающая определёнными свойствами Компонент Часть АС, выделенная по определенному признаку или совокупности признаков и рассматриваемая как единое целое (ГОСТ Р 59853-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения») Контракт Контракт на выполнение работ по развитию и оказанию услуг по технической поддержке Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК в 2026 году, заключаемый по результатам проведения конкурентной процедуры закупки в соответствии с требованиями Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» - - Значение характеристики не может изменяться участником закупки - Модуль iМинтранс Модуль сбора данных и представления показателей деятельности Министерства транспорта Российской Федерации iМинтранс АСУ ТК Модуль СЦ Модуль сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК НС Нештатная ситуация НСИ Нормативно-справочная информация ОТИ Объект транспортной инфраструктуры П-ГИС Геоинформационная подсистема П-ИВ Подсистема информационного взаимодействия П-НСИ Подсистема ведения нормативно-справочной информации и метаданных ПО Программное обеспечение Подрядчик, Исполнитель Организация, с которой будет заключен контракт на выполнение работ по развитию Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК П-СД Подсистема сбора данных Работы Работы по развитию Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК СЗИ Средство защиты информации СМЭВ Система межведомственного электронного взаимодействия СУБД Система управления базами данных ТЗ Техническое задание (настоящий документ) ТС Транспортное средство ТК Транспортный комплекс Учреждение Учреждения в области информационной безопасности - ФГБУ «СИЦ Минтранса России» Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации», Заказчик Федеральный закон № 44-ФЗ Федеральный закон от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» ФЗ Функциональная задача ФЗ «Реестр объектов» Функциональная задача «Формирование и ведение единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации» ФСБ России Федеральная служба безопасности Российской Федерации ФСТЭК России Федеральная служба по техническому и экспортному контролю ЧС Чрезвычайная ситуация ЭВМ Электронно-вычислительная машина API От англ. Application Programming Interface – интерфейс прикладного программирования – совокупность инструментов и функций в виде интерфейса для взаимодействия с программой CSS От англ. Cascading Style Sheets — каскадные таблицы стилей FPS От англ. frame per second - количество кадров в секунду HTML От англ. HyperText Markup Language - стандартный язык разметки документов, создающий основу и структуру всех веб-страниц JSON От англ. JavaScript Object Notation – текстовый формат обмена данными, основанный на JavaScript WebAssembly (Wasm) Открытый стандарт, представляющий собой низкоуровневый бинарный формат инструкций, который позволяет выполнять код, написанный на языках C++, Rust или Go, в браузерах с производительностью, близкой к нативной - 1. ОБЩИЕ СВЕДЕНИЯ - – постановление Правительства Российской Федерации от 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 Федерального закона «Об электронной подписи»; - - Значение характеристики не может изменяться участником закупки - – постановление Правительства Российской Федерации от 08.06.2011 № 451 «Об инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг и исполнения государственных и муниципальных функций в электронной форме»; – постановление Правительства Российской Федерации от 30.01.2013 № 62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин»; – приказ ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации»; – приказ ФСТЭК России от 11.04.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений»; – приказ ФСБ России от 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.7. Сроки начала и окончания работ Начало работ: с даты заключения Контракта. Окончание работ: не позднее 15.12.2026. Работы выполняются в соответствии с этапами. Сроки выполнения этапов работ по развитию и технической поддержке Модуля СЦ определяются Календарным планом. Календарный план, приведен в разделе 5 настоящего ТЗ - 1.8. Общие сведения об источниках и порядке финансирования работ Источником финансирования являются средства субсидии федерального бюджета Российской Федерации, предоставленной в соответствии с абзацем вторым пункта 1 статьи 78.1 Бюджетного кодекса Российской Федерации (код цели 08-01) - 1.9. Порядок оформления и предъявления результатов работ Подрядчик должен передать Заказчику результаты работ в порядке, определенном Контрактом в сроки, установленные п. 5 настоящего ТЗ, в соответствии с Календарным планом - 1.10. Место выполнения Работ Работы выполняются удаленно на комплексе технических средств Заказчика. Адрес размещения комплекса технических средств Заказчика: Московская обл., Богородский район, пос. Горбуша, Радиоцентр. Техническая возможность удаленного подключения обеспечивается Заказчиком (в части предоставления параметров доступа). Оплата телематических и иных услуг, технических и программных средств, необходимых Подрядчику для удаленного подключения и для выполнения требований по информационной безопасности, осуществляется Подрядчиком самостоятельно за свой счет - 1.1. Наименование Системы Полное наименование системы: Информационно-аналитическая система регулирования на транспорте. Условное обозначение системы: АСУ ТК. Полное наименование модуля: Модуль сбора, ведения и анализа информации о нештатных ситуациях на транспорте. Условное обозначение модуля: Модуль СЦ. Модуль СЦ создан в рамках контракта от 05.08.2024 № ОК/24_04 на выполнение работ по развитию АСУ ТК в части создания модуля «Сбора, ведения и анализа информации о нештатных ситуациях на транспорте». Развитие Модуля СЦ осуществлено в рамках контракта от 19.05.2025 № ОК/25_09 на выполнение работ по развитию Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК - 1.2. Шифр темы или номер контракта Присваивается Заказчиком по результатам организации закупочных процедур. 1.2.1. Предмет контракта Выполнение работ по развитию Модуля СЦ. Код по ОКПД2: 62.01.11.000 – услуги по проектированию и разработке информационных технологий для прикладных задач и тестированию программного обеспечения. Оказание услуг по технической поддержке Модуля СЦ. Код по ОКПД2: 62.02.30.000 – услуги по технической поддержке информационных технологий. Выполнение работ по развитию Модуля СЦ предусмотрено с учетом ключевых результатов (ОКР) Ведомственной программы цифровой трансформации Минтранса России на 2026-2028 (далее - ВПЦТ Минтранса России) в составе мероприятия № 103.002 «АСУ ТК» ИТ расхода 103.26.000005 «Развитие Информационно-аналитической системы регулирования на транспорте (АСУ ТК)»: · «Обеспечено информационное взаимодействие с Минобороны о происшествиях на транспортных объектах»; · «Обеспечена автоматизация формирования отчетов о нештатных ситуациях на транспорте, в том числе по данным внешних систем». Выполнение работ по технической поддержке АСУ ТК предусмотрено ВПЦТ Минтранса России в составе мероприятия № 103.002 «АСУ ТК» ИТ расхода 103.26.000021 «Эксплуатация Информационно-аналитической системы регулирования на транспорте (АСУ ТК)» - 1.3. Заказчик Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» (ФГБУ «СИЦ Минтранса России»). Адрес: 107078, Москва, Садовая-Спасская ул., д.18, стр. 1. Оператором Системы является Заказчик - Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» (ФГБУ «СИЦ Минтранса России) - 1.4. Подрядчик Определяется по результатам проведения конкурентной процедуры закупки в соответствии с требованиями Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (далее – Федеральный закон № 44-ФЗ) - 1.5. Основания для выполнения работ Работы осуществляются на основании следующих документов: – постановление Правительства Российской Федерации от 30.12.2003 № 794 «О единой государственной системе предупреждения и ликвидации чрезвычайных ситуаций»; – постановление Правительства Российской Федерации от 08.11.2013 № 1007 «О силах и средствах единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций»; – распоряжение Правительства Российской Федерации от 27.11.2021 № 3363-р «О Транспортной стратегии Российской Федерации до 2030 года с прогнозом на период до 2035 года»; – Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 26.08.2025 №ЕФ-3; – Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 27.11.2025 №ЕФ-23; - – Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 19.02.2026 №ЕФ-1; – План мероприятий по профилактике случаев непроизводственного травматизма граждан на железнодорожном транспорте, являющийся приложением к постановлению коллегии Министерства транспорта Российской Федерации от 11.03.2026 № 2 - 1.6. Перечень документов, требования которых должны быть учтены при выполнении работ – Федеральный закон Российской Федерации от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации»; – Федеральный закон Российской Федерации от 27.07.2006 № 152-ФЗ «О персональных данных»; – Федеральный закон Российской Федерации от 06.04.2011 № 63-ФЗ «Об электронной подписи»; – Федеральный закон Российской Федерации от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации»; – Указ Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации»; – Указ Президента Российской Федерации от 01.05.2022 № 250 «О дополнительных мерах по обеспечению информационной безопасности Российской Федерации»; – Указ Президента Российской Федерации от 31.03.2010 № 403 «О создании комплексной системы обеспечения безопасности населения на транспорте»; – постановление Правительства Российской Федерации от 30.07.2004 № 395 «Об утверждении Положения о Министерстве транспорта Российской Федерации»; – постановление Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации»; – постановление Правительства Российской Федерации от 16.11.2015 № 1236 «Об установлении запрета на допуск программного обеспечения, происходящего из иностранных государств, для целей осуществления закупок для обеспечения государственных и муниципальных нужд»; – постановление Правительства Российской Федерации от 23.12.2024 № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц»; - 2. ЦЕЛИ И НАЗНАЧЕНИЕ ВЫПОЛНЕНИЯ РАБОТ - 2.1. Назначение АСУ ТК АСУ ТК предназначена для автоматизации и информационно-аналитического обеспечения процессов управления развитием транспортного комплекса Российской Федерации, обеспечения публичности деятельности органов государственного управления транспортным комплексом. Основными целями АСУ ТК являются: – повышение эффективности процессов управления функционированием и развитием транспортного комплекса на основе создания единой информационной среды и комплекса информационно-аналитических услуг на уровне органов государственного управления ТК; – повышение уровня безопасности ТК на базе получения полной, достоверной и оперативной информации о происходящих изменениях, своевременного выявления негативных тенденций и для принятия соответствующих мер по их устранению и ликвидации последствий - - Значение характеристики не может изменяться участником закупки - Основными задачами АСУ ТК являются: – автоматизация процессов прогнозирования развития транспортного комплекса и поддержки принятия управленческих решений; – автоматизация процессов мониторинга безопасности и устойчивости транспортного комплекса, управления в чрезвычайных и нештатных ситуациях; – автоматизация процессов управления программами и проектами развития и модернизации транспортного комплекса; – автоматизация процессов мониторинга состояния транспортного комплекса, в том числе с использованием набора ключевых показателей эффективности деятельности транспортного комплекса; – информационно-технологическая поддержка взаимодействия субъектов транспортного комплекса Российской Федерации, органов государственного управления и контроля, международных организаций на основе создания единой технологической среды взаимодействия и управления движением данных (и связанных с ними документов) в транспортном комплексе; – использование в процессах управления транспортным комплексом РФ современных технологий электронного документооборота и электронного обмена данными; – организация межведомственного электронного взаимодействия подразделений Министерства транспорта Российской Федерации, подведомственных агентств и службы с другими организациями - 2.2. Назначение и цели развития и технической поддержки Модуля СЦ Назначение Модуля СЦ: – оперативный мониторинг нештатных и чрезвычайных ситуаций на транспорте ; – оповещение заинтересованных лиц и структур о нештатных и чрезвычайных ситуациях; – сбор, обработка и хранение данных о нештатных и чрезвычайных ситуациях. Целями развития Модуля СЦ являются: – расширение состава данных об оперативной обстановке на транспорте; – оптимизация процесса сбора данных об оперативной обстановке на транспорте; – повышение информированности пользователей за счет визуализация данных Модуля СЦ; – автоматизация процесса формирования отчетов о ЧС и нештатной ситуации на транспорте; – обеспечение информационного взаимодействия с заинтересованными организациями по вопросам ведения. - Целями оказания услуг по технической поддержке являются: – обеспечение информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы; – поддержание параметров функционирования ППО Системы, удовлетворяющих требованиям производственных процессов, включая их непрерывность; – обеспечение бесперебойного функционирования ППО и своевременное устранение сбоев и аварийных ситуаций в Системе; – своевременное устранение уязвимостей при выявлении таковых, в соответствии с требованиями к обеспечению информационной безопасности; – адаптация, конфигурирование, коррекция программного обеспечения в соответствии с изменениями нормативно-правовой базы и запросами уполномоченных сотрудников органов государственной власти, включая выполнение процедур тестирования и участие в обновлениях ППО на стендах Заказчика; – обеспечение сохранения работоспособности ППО в изменяемой среде эксплуатации; – ведение документации по настоящему ТЗ, инициирование и актуализация документации на Систему по результатам обработки запросов Заказчика и внесении соответствующих изменений в ППО. Модуль СЦ применяется в деятельности Министерства транспорта Российской Федерации, подведомственных агентств и службы и другими организациями в соответствии с соглашениями об информационном обмене - 3. ХАРАКТЕРИСТИКА ОБЪЕКТА АВТОМАТИЗАЦИИ - 3.1. Описание объекта автоматизации АСУ ТК Объектом автоматизации являются процессы основной и обеспечивающей деятельности, направленные на управление транспортным комплексом, в том числе, процессы информационного взаимодействия с другими организациями и субъектами транспортного комплекса. АСУ ТК относится к государственным информационным системам, а также к информационным системам персональных данных и значимым объектам критической информационной инфраструктуры Российской Федерации. АСУ ТК соответствует требованиям, предъявляемым к: – ГИС второго класса защищенности в соответствии с приказом ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах»; – ИС персональных данных при обеспечении третьего уровня защищенности персональных данных в соответствии с требованиями постановления Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»; – значимым объектам КИИ Российской Федерации второй категории значимости с постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении Правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений». Модуль СЦ является подсистемой АСУ ТК. Перечень платформенных решений и функциональных задач АСУ ТК представлен в Таблице 1 - - Значение характеристики не может изменяться участником закупки - Таблица 1 – Перечень платформенных решений и функциональных задач АСУ ТК № Наименование подсистемы/ функциональной задачи/ модуля Назначение 1 Подсистема сбора данных и централизованного хранилища данных Подсистема обеспечивает выполнение сбора данных в АСУ ТК, и в т. ч., в рамках функциональных задач «Формирование и ведение межрегионального транспортного баланса пассажирских перевозок в дальнем (межрегиональном) сообщении» и «Формирование и ведение транспортного паспорта региона» 2 Подсистема информационного взаимодействия Подсистема информационного предназначена для обеспечения информационного взаимодействия подсистем АСУ ТК, а также, взаимодействия АСУ ТК с АС федеральных органов исполнительной власти 3 Подсистема ведения нормативно-справочной информации и метаданных Подсистема предназначена для автоматизации функций формирования и актуализации справочников, классификаторов, реестров и регистров, необходимых для обеспечения информационной поддержки пользователей НСИ и интеграции подсистем АСУ ТК в части применения НСИ 4 Модуль СМЭВ Модуль взаимодействия со СМЭВ представляет собой набор сервисов взаимодействия: сервис синхронного взаимодействия и сервис отправки, осуществляющих дополнительную обработку сообщений, отправляемых в СМЭВ и принимаемых из СМЭВ 5 Геоинформационная подсистема Программное обеспечение геоинформационной подсистемы предназначено для обеспечения смежных подсистем АСУ ТК возможностью работы с картографической информацией, в том числе, отображения на электронных картах объектов транспортной инфраструктуры и получения информации о местоположении, характеристиках контролируемых транспортных объектов 6 Подсистема информационного портала АСУ ТК Подсистема информационного портала предназначена для отображения и входа в функциональные задачи АСУ ТК 7 Подсистема технического портала АСУ ТК Подсистема технического портала АСУ ТК предназначена для управления заявками пользователей и технологического документооборота заявок - 8 Подсистема проектного архива АСУ ТК Подсистема проектного архива АСУ ТК предназначена для автоматизации деловых процессов должностных лиц Министерства транспорта Российской Федерации, подведомственных агентств и службы, в том числе, и процессов информационного взаимодействия внутреннего и внешнего характера 9 ФЗ «Реестр объектов» Функциональная задача предназначена для формирования и ведения единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации 10 ФЗ «СТП» Функциональная задача предназначена для организации информационно-аналитической поддержки процессов территориального планирования Российской Федерации в области федерального транспорта 11 ФЗ «МРТБ ПП» Функциональная задача предназначена для формирования и ведения межрегионального транспортного баланса пассажирских перевозок в дальнем (межрегиональном) сообщении 12 ФЗ «МДД» Функциональная задача предназначена для осуществления мониторинга дорожного движения 13 ФЗ «ТПР» Функциональная задача предназначена для формирования и ведения транспортного паспорта региона 14 ФЗ «Данные по грузообороту» Функциональная задача предназначена для обеспечения подсистем и пользователей АСУ ТК данными по грузообороту между Российской Федерацией и зарубежными странами 15 ФЗ «МЖТ» Функциональная задача предназначена для осуществления мониторинга железнодорожного транспорта 16 ФЗ «МГМП» Функциональная задача предназначена для осуществления мониторинга грузопотоков в морских портах с целью формирования единой цифровой среды мониторинга и планирования перевозок в/из портов Дальнего Востока - 17 Модуль ГЭТ Модуль предназначен для получения, хранения данных инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по отдельно взятому предприятию-перевозчику. Формирования отчетов об инвентаризации с детальными данными по каждому разделу инвентаризации с маршрутизацией в муниципалитет / регион / Минтранс. Содержит агрегированные данные инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по всем перевозчикам, относящихся к данному муниципалитету. Формирует сводный отчет по муниципалитету по каждому разделу инвентаризации с маршрутизацией в регион / Минтранс. Формирует агрегированные данные инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по всем перевозчикам, относящиеся к данному региону и по всем муниципалитетам, относящимся к данному региону. Аналитические и статистические данные о состоянии ГЭТ региона. Содержит данные о видах транспорта, цифровых транспортных сервисах и платежных инструментах Региона. Формирует сводный отчет по каждому разделу инвентаризации с маршрутизацией в Минтранс. Формирует агрегированную статистику и аналитику по всем регионам страны в разрезе транспортных средств, маршрутов, пассажиропотоков, инфраструктуры ГЭТ. Данные о рейтинге регионов и перевозчиков на основании выбранных параметров, документооборот с участниками Системы: получение подписанных печатных форм, их утверждение, возврат на доработку. 18 Модуль iМинтранс Модуль создан для отчета по ключевым показателям транспортного комплекса России (Отраслевые и статистические показатели, исполнение бюджета, исполнение поручений, аналитика СМИ, происшествия по видам транспорта). 19 Модуль СЦ Модуль СЦ предназначен для оперативного мониторинга нештатных ситуаций транспортной отрасли, оповещения заинтересованных лиц и структур и предоставления данных о нештатных ситуациях - АСУ ТК осуществляет идентификацию и авторизацию посредством Единой системы идентификации и аутентификации (ЕСИА). Информационный обмен с внешними информационными системами осуществляется посредством СМЭВ 3 и СМЭВ 4. АСУ ТК развернута на вычислительных мощностях ГЦОД СИЦ Минтранса России - 3.2. Описание и текущее состояние объекта автоматизации Модуля СЦ Объектом автоматизации является процесс организации мониторинга информации о НС и ЧС на транспорте. Предметом деятельности Учреждения являются следующие функции: – информационное обеспечение в области транспортной безопасности, защиты населения и территорий от чрезвычайных ситуаций природного и техногенного характера в транспортном комплексе; – подготовка справочных материалов при угрозе возникновения и возникновении чрезвычайных ситуаций и иных происшествий в транспортном комплексе; – взаимодействие и обмен оперативной информацией с органами управления Единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций; – организация оперативного мониторинга обстановки на объектах транспорта при угрозе и возникновении чрезвычайных ситуаций и иных происшествий. Перечень компонентов Модуля СЦ и выполняемые ими функции представлены в Таблице 2 - Таблица 2. Перечень компонентов Модуля СЦ и их функции № п/п Компонент Выполняемые функции 1 Регистрация событий – ведение карточки события; – удаление комментария; – динамическое отображение существующих событий в заданном радиусе и за заданный период; – возможность автоматической проверки вводимых данных в части количества пострадавших; – отображение карточки ОТИ, ТС в соответствии с ФЗ Реестр объектов; – сохранение и отображение версии карточки события; – привязка события к координатам по картографической основе; – указание признака выполнения действия по отработке события; – перевод статуса события; – закрытие карточки события; – публикация информации о событии в канале мессенджера; – возможность перехода из карточки события на картографическую основу для просмотра местоположения события 2 Визуализация – отображение событий на картографической основе в виде пиктограмм; – масштабирование карты; – отображение краткой карточки события при выборе события на картографической основе; – отображение списка событий; – отображение карточки события; – отображение журнала действий пользователя; – отображение дополнительной информации (текстовая информация и приложенные файлы); – отображение справки о событиях и отчета о событиях; – отображение фильтров и количества отфильтрованных объектов; – отображение результатов поиска; – отображение статистики по событиям на экране; – возможность создания события с картографической основы; – отображения картографических слоев в зависимости от примененных фильтров; – возможность настройки шага картографической сети; – возможность настройки географической точки центра карты; – отображение количества непрочитанных сообщений; – возможность перехода к детальной карточке события из краткой карточки события при выборе события на картографической основе - 3 Информирование – ведение справочника способов оповещения (веб-интерфейс, мессенджер); – формирование сценария выполнения оповещения (настройка условий, способа, параметров оповещения); – выполнение оповещений пользователей 4 Отчетность – формирование отчета и справки о событиях; – фильтрация событий для выгрузки в справку о событиях или в отчет о событиях 5 Администрирование – ведение ролей пользователей; – ведение учетных данных пользователей; – ведение справочника организаций; – ведение справочника групп системы мгновенного обмена сообщениями; – выполнение исходящего звонка на контактный телефонный номер организации; – формирование матрицы эскалации событий Архитектура Модуля СЦ представлена на рисунке 1. Рисунок 1. Архитектура Модуля СЦ - 3.3. Состав используемого ПО Модуля СЦ Программная архитектура Модуля СЦ разработана как трехуровневая клиент-серверная архитектура. Архитектура включает в себя следующие уровни: • уровень представления – презентационный уровень, обеспечивающий взаимодействие с пользователя с клиентскими приложениями с использованием веб-браузера («тонкий» клиент); • уровень приложений – реализован в виде сервисов, обеспечивает обработку запросов, поступающих от клиентских приложений, формирование ответов на запрос в доступном пользователю виде (формирование пользовательских интерфейсов); • уровень хранения данных – реализуется как сервер БД и обеспечивает хранение и целостность хранимых данных, создание резервных копий, ведение журнала транзакций, восстановление данных после сбоев. Программная архитектура Модуля СЦ включает в себя сервисы и интерфейсы, указанные в Таблице 3. Таблица 3. Программная архитектура Модуля СЦ Программный сервис/интерфейс Технологии реализации Уровень представления Интерфейс пользователя и администратора (front-end) Javascript Уровень приложений Сервис (GateWay) Kotlin Сервис геокодирования (geocoding-service) Kotlin Сервис уведомлений (notifiсation-service) Kotlin Сервис работы с файлами (file-service) Kotlin Сервис отчетности (report-service) Kotlin Сервис управления событиями (event-service) Kotlin Сервис информирования через мессенджер (messenger-notifier) Python Сервис внешних интеграций (integration-service) Сбор информации из внешних систем и сервисов Брокер сообщений Kafka Уровень хранения данных Файловое хранилище MinIO S3 СУБД Postgres Pro Enterprise - 3.4. Информационное взаимодействие программных сервисов и интерфейсов Модуля СЦ Объект автоматизации функционирует в распределенной информационной среде. Обмен данными осуществляется по защищенным каналам связи (в том числе ведомственным сетям передачи данных). Источники информации включают: · внешние автоматизированные системы (органов государственной власти); · внутренние базы данных (реестры объектов транспортной инфраструктуры, паспорта регионов и пр.); · оперативная информация от персонала, поступающая через автоматизированные рабочие места (АРМ) и мобильные устройства. 3.4.1. Взаимодействие Модуля СЦ со смежными подсистемами АСУ ТК Модуль СЦ входит в состав АСУ ТК и взаимодействует со следующими ее функциональными задачами и подсистемами: · Функциональной задачей «Формирование и ведение единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации» (ФЗ «Реестр объектов»); · Геоинформационной подсистемой АСУ ТК (П-ГИС); · Подсистемой ведения нормативно-справочной информации и метаданных (П-НСИ); · Подсистемой сбора данных и централизованное хранилище данных (П-СД); · Подсистемой информационного взаимодействия (П-ИВ). 3.4.2. Взаимодействие с внешними информационными системами Список внешних информационных систем, с которыми осуществляется взаимодействие Модуля СЦ: · ЕСИА; · мессенджер; · Яндекс Геокодер; · Информационная система «Централизованная система сбора информации систем-112»; · ПВК «Поиск-Море», АИС РПТ; · облачная АТС - 3.5. Требования к эксплуатации Применяемое в Системе программное обеспечение, программно-аппаратные и аппаратные комплексы должны соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации» - 4. ТРЕБОВАНИЯ К МОДУЛЮ СЦ - 4.3.1.3. Требования к регламенту оказания услуг Подрядчик должен руководствоваться Регламентом оказания услуг по технической поддержке Модуля СЦ. Регламент оказания услуг содержит следующую информацию: – порядок оказания услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Модуля СЦ; – порядок оказания услуги по решению инцидентов, связанных с работой ППО; – порядок оказания услуги адаптационного, конфигурационного и коррекционного сопровождения Модуля СЦ (в рамках действующих программных модулей и функциональностей); – порядок оказания услуги по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности. – Регламент содержит следующие формы заявок на оказание услуг: – форма заявки на оказание услуги по информационно-консультационной поддержке сотрудников Заказчика; – форма заявки на оказание услуги по решению инцидентов, связанных с работой ППО; – форма заявки на оказание услуг адаптационного, конфигурационного и коррекционного сопровождения Модуля СЦ (в рамках действующих программных модулей и функциональностей) (приоритет заявки определяется Заказчиком); – форма заявки на оказание услуги по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности - - Значение характеристики не может изменяться участником закупки - 4.3.2. Требования к режиму обеспечения функционирования Модуля СЦ Режим оказания услуг определен в Приложении Б к настоящему ТЗ. По согласованию с Заказчиком, в целях недопущения остановки функционирования Модуля СЦ в период интенсивной работы пользователей в Модуле СЦ, отдельные услуги могут оказываться по специальному графику (в нерабочее время Подрядчика) в соответствии с заявками Заказчика - 4.3.3. Требования к качеству оказываемых услуг Качество оказываемых услуг поддерживается Подрядчиком в соответствии с определяемыми данным ТЗ условиями и правилами и контролируется Заказчиком на постоянной основе, в том числе по соблюдению сроков исполнения и подтверждениям исполнения от инициаторов обращений и другим параметрам. По результатам выполнения работ по устранению инцидента должна быть устранена корневая причина инцидента с окончательным решением, устраняющим причину возникновения проблемы и исключающим вероятность повторного возникновения проблемы (инцидента). Время устранения корневых причин проблемы (инцидента) не должно составлять более 40 рабочих часов - 4.5.7. Требования по сохранности информации при авариях В случае возникновения аварии или сбоя в процессе выполнения пользовательских задач должно быть обеспечено восстановление баз данных до состояния на момент последней завершенной Модулем СЦ транзакции, и структуры файлового хранилища. Все аварийные ситуации должны обрабатываться программно с выдачей соответствующих сообщений, с корректной обработкой ситуации (завершение транзакций, закрытие файлов и т.п.), без потери обрабатываемой информации. В Модуле СЦ должны быть предусмотрены меры, обеспечивающие целостность данных в случае отказа программного обеспечения или аппаратных средств, исключая случаи физического уничтожения носителя или нарушения функциональности носителя, операционной системы или СУБД по вине их производителя либо обслуживающего персонала. Используемые аппаратные и системные платформы должны обеспечивать сохранность и целостность информации в Модуле СЦ при полном или частичном отключении электропитания, аварии сетей телекоммуникации, полном или частичном отказе технических средств Модуля СЦ. Технические решения должны обеспечивать сохранность информации в случае возникновения следующих событий (аварий, отказов и т.п.): – отказ аппаратного обеспечения на сервере; – отключение питания на сервере; – отказ аппаратного обеспечения на рабочей станции; – отключение питания на рабочей станции администратора; – отказ линий связи, в том числе при осуществлении обмена данными - 4.5.8. Требования к защите от влияния внешних воздействий Требования к защите от влияния внешних воздействий не предъявляются - 4.5.9. Требования к патентной чистоте и патентоспособности 4.5.9.1. Исключительные права на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, базы данных, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, принадлежат Российской Федерации в лице Заказчика. Право собственности на результаты работ, отчетные документы и материалы, полученные в ходе выполнения работ по Контракту, принадлежат Российской Федерации в лице Заказчика и считаются переданными с момента подписания Сторонами Акта сдачи-приемки выполненных работ. Разработанное программное обеспечение поставляется вместе с исходными кодами. 4.5.9.2. Все проектные и технические решения должны отвечать требованиям четвертой части Гражданского кодекса Российской Федерации. Результаты Работ должны быть свободными от возможности предъявления любых прав и притязаний третьих лиц, основанных на промышленной, интеллектуальной или другой собственности. 4.5.9.3 Результаты выполненных Работ не должны повлечь необходимость осуществления Заказчиком закупок программного обеспечения (как исключительных, так и неисключительных прав) для обеспечения функциональности Системы в соответствии с Техническим заданием. При выполнении работ Подрядчик должен использовать только объекты интеллектуальной собственности, права на которые приобретены (получены) и используются без нарушений прав на интеллектуальную собственность третьих лиц или предоставлены Заказчиком - 4.3.4. Требования к документированию результатов оказываемых услуг Для обеспечения контроля оказываемых услуг по поддержке Модуля СЦ со стороны Заказчика, по окончании каждого отчетного периода по контракту в соответствии с календарным планом, Подрядчик обязан предоставить Заказчику Отчет об оказанных услугах. Отчет должен содержать детальную информацию об оказанных услугах с указанием даты выполненных мероприятий и приложением обосновывающих документов (заявок, запросов, требований) или ссылкой на такие документы, если они содержатся в Модуле СЦ. Информация о выполненных мероприятиях по заявкам должна быть сформирована на основании соответствующих записей СРО по каждому этапу исполнения Контракта. В случае оказания услуги адаптационного, конфигурационного и коррекционного сопровождения Модуля СЦ, должны быть предоставлены документы, подтверждающие выполнение требований п. 29.3 приказа ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации». Фактическое время реагирования и время решения по всем обращениям, поступившим в СРО, формируется в СРО по итогам отчетного периода в разделе «Отчеты». Фактическое время реагирования и время решения по обращениям учитывает суммарное время, затраченное на реагирование и, соответственно, на работу по обращению с момента назначения обращения специалисту Подрядчика или группе исполнителей, ответственным за оказание услуг технической поддержки 3 уровня от начала до завершения работ Подрядчиком. При этом принимается суммарное время нахождения заявки в соответствующих статусах заявки СРО на стороне Подрядчика - 4.3.5. Требования к классификации обращений и заявок Обращения и заявки Заказчика классифицируются в соответствии с приоритетами и регламентными сроками, указанными в Приложении 2 к Регламенту. Регистрация обращений и заявок предусматривает создание новой записи в СРО с присвоением поступившему обращению или заявке (новой записи) уникального идентификатора. Запись в СРО должна содержать вопрос или проблему, которую требуется решить или оказать консультацию. Состав обязательной информации, которую должно содержать обращение или заявка, зафиксирован в Регламенте оказания Услуг. Если обращение или заявка автоматически зарегистрированы в СРО при отправке представителем Заказчика, Подрядчик проверяет корректность классификации обращения или заявки и может обратиться к Заказчику с просьбой корректировки, предоставив обоснования в соответствии с настоящей классификацией (Таблица 6) - 4.5.9.4. Подрядчик подтверждает, что обладает всеми правами на передачу Заказчику исключительных прав в соответствии с требованиями настоящего раздела Технического задания. В случае, если к Заказчику по вине Подрядчика будут предъявлены претензии в этой части, иски третьих лиц, связанные с нарушением их прав, Подрядчик принимает на себя такие претензии и иски и возмещает Заказчику все расходы и весь ущерб, понесенный в связи с ними. 4.5.9.5. Подрядчик обязан согласовать с Заказчиком необходимость использования при выполнении работ охраняемых результатов интеллектуальной деятельности, права на которые принадлежат Подрядчику или третьим лицам. 4.5.9.6. В случае, если при выполнении Работ используется готовое программное обеспечение (платформа, подсистема, СУБД и т.д.), которое становится частью (компонентом) Системы, Заказчику передаются полные исключительные права, или неисключительные права (путем заключения лицензионного/сублицензионного договора/соглашения) на такое программное обеспечение со следующими возможностями: – права передаются бессрочно (на весь срок действия исключительных прав); – территория действия Российская Федерация; – должно быть обеспечено право Российской Федерации (в лице Заказчика) передавать, дорабатывать, распространять, развивать результаты работ, созданные в процессе исполнения Контракта, а также перерабатывать такое программное обеспечение. Лицензионное (сублицензионное) соглашение (договор), Акт передачи прав, подписанные Подрядчиком, согласие правообладателя, оформленное в соответствии с положениями Гражданского кодекса Российской Федерации (в случае, если Подрядчик не является правообладателем такого программного обеспечения), инструкция по инсталляции, руководство администратора, руководство пользователя передаются Заказчику в сроки, установленные Техническим заданием для соответствующего функционала Системы - Лицензионное (сублицензионное) соглашение (договор) не может возлагать на Заказчика какие-либо обязанности (в т.ч. в части конфиденциальности, предоставления отчетности), не предусмотренные Контрактом. 4.5.9.7. Передача Заказчику исключительных прав, или простых (неисключительных) прав не может повлечь увеличение стоимости Контракта и/или изменение иных существенных условий Контракта. 4.5.9.8. Функциональность Модуля СЦ передается в объеме и в сроки, установленные Техническим заданием. 4.5.9.9. Нарушение условий настоящего раздела Технического задания, в т.ч. отсутствие соответствующего лицензионного (сублицензионного) соглашения (или договора), либо предоставление лицензионного (сублицензионного) соглашения (или договора), не соответствующего требованиям действующего законодательства Российской Федерации или требованиям Контракта, является нарушением существенных условий Контракта. 4.5.9.10. В случае, если в соответствии с пунктом 4.5.9.6 Заказчику передается исключительное право, такая передача осуществляется в порядке, установленном Гражданским кодексом Российской Федерации. 4.5.9.11. В случае, если при выполнении Работ положения пунктов 4.5.9.5-4.5.9.6 не применялись, Подрядчик в составе отчетной документации предоставляет об этом декларацию в свободной форме. Декларация должна содержать сведения о полном соответствии результата Работ требованиям Контракта, а также о неприменении при выполнении работ готового программного обеспечения (платформ, подсистем, СУБД и т.д.), которое стало частью (компонентом) Системы - Таблица 6. Категории обращений и заявок Категория Примеры Запрос на обслуживание Подготовка SQL запроса к СУБД для решения прикладной задачи и д.р. – запрос на любое действие, не являющееся запросом информации и несовершенный на основе происшествия, прямо или косвенно влияющего на работу Модуля СЦ Консультация «Где взять / куда обратиться...?», «Как сделать / выполнить…», «Как это работает…?» - запрос, имеющий своей целью получение информационной поддержки Инцидент Разбор ошибок/сбоев и подготовка материалов (корректировочных релизов, инструкций) для Заказчика для устранения ошибок/сбоев, которые приводят к частичному и полному нарушению работоспособности всех или отдельных функций ППО. Подготовка изменения и материалов, необходимых для проведения аварийно-восстановительных работ для возобновления работоспособности Модуля СЦ ЗНИ Подготовка изменений, связанных с изменением, улучшением/оптимизацией Модуля СЦ и выводом новой модифицированной функциональности в штатном режиме. Подготовка изменений, связанных с модификацией существующих и/или реализация новых интеграционных механизмов для получения/обработки данных внешних систем. Подготовка изменений графического интерфейса по требованиям Заказчика. Перечень статусов обращений (заявок) приведен в пункте 3.3. Регламента оказания Услуг. Назначение обращению (заявке) статуса «Закрыто» осуществляется Заказчиком только после получения от инициатора обращения (заявки) подтверждения о его исполнении или нахождения обращения (заявки) в статусе «Выполнено» и отсутствия повторных вопросов/запросов по данному обращению (заявки) в течение 5 рабочих дней. Категории и статусы обращений (заявок) могут быть скорректированы в процессе оказания услуг исключительно по согласованию с Заказчиком - 4.3.6. Требования к услугам технической поддержки 4.3.6.1. Требования к организации третьего уровня технической поддержки Основными задачами организации третьего уровня технической поддержки в рамках оказания услуг по технической поддержке Модуля СЦ являются организация эксплуатационной службы Подрядчика, проверка готовности технических и программных средств для обеспечения непрерывного функционирования ППО Модуля СЦ. Подрядчиком должны быть проведены организационно-штатные и подготовительные мероприятия (в т. ч. технические) в рамках организации технической поддержки Модуля СЦ. Подрядчик в течение 5 (пяти) рабочих дней с даты заключения Контракта должен: – определить и направить Заказчику документ «Перечень уполномоченных специалистов», содержащий контактную информацию (ФИО, должность, адрес рабочей электронной почты) лиц, ответственных за оказание услуг со стороны Подрядчика; – обеспечить подключение специалистов Подрядчика к Системе регистрации обращений (заявок) (СРО предоставляется Заказчиком) для оказания услуг; – согласовать с Заказчиком способ доступа Подрядчика к Модулю СЦ. Результат выполнения мероприятий фиксируется в Протоколе проверки результатов организационно-штатных и подготовительных мероприятий (см. Приложение Д к настоящему ТЗ) - 4.5.9.12. Передача Заказчику комплекта документов, материалов и сведений, предусмотренных нормативными правовыми актами Российской Федерации в сфере информационных технологий, защиты информации, правовой защиты интересов государства в области интеллектуальной собственности, включая документы, подтверждающие отказ авторов (разработчиков) от исключительных прав на передаваемые объекты интеллектуальной собственности в пользу Подрядчика, с проектами заявок на государственную регистрацию в установленном порядке прав Заказчика на результаты интеллектуальной деятельности, в том числе, но не исключая: изобретения, полезные модели, промышленные образцы, программы для электронных вычислительных машин, базы данных, топологии интегральных микросхем, а также исключительные права на результаты работ, включая объекты авторских прав и потенциально патентоспособные технические решения, секреты производства (ноу-хау), созданные в рамках Контракта, осуществляется Подрядчиком в составе отчетной документации, предусмотренной условиями Контракта. 4.5.9.13. По результатам выполнения работ по развитию системы должны быть подготовлены материалы для регистрации доработанной версии Системы (объекта учета) в НФАП в соответствии с требованиями постановления Правительства Российской Федерации от 30 января 2013?г. №?62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин» (с изменениями и дополнениями) в части обязательности размещения результатов работ в национальном фонде алгоритмов и программ для электронных вычислительных машин - 4.5.10. Требования по стандартизации и унификации К Модулю СЦ предъявляются следующие требования в части стандартизации и унификации: – работы по развитию Модуля СЦ должны производиться в соответствии с действующими стандартами и нормами Российской Федерации; – при создании и модернизации элементов Модуля СЦ следует руководствоваться действующими в Российской Федерации национальными стандартами и другими нормативно-техническими документами; – используемые оборудование и материалы, подлежащие обязательной сертификации, должны иметь соответствующие сертификаты; – ПО Модуля СЦ должно проектироваться и разрабатываться с учётом обеспечения требований унификации; – применяемые при создании Модуля СЦ технические (форматы данных, протоколы передачи и прочие) и организационные (регламенты, требования, инструкции) решения должны быть доступны и документированы в виде, достаточном для независимой (без обращения к Подрядчику) реализации третьими сторонами; – термины, обозначения и наименования, используемые в ПО, должны быть стандартизованы и унифицированы, выполнены на русском языке; – взаимодействие элементов и их внешнее поведение должно быть реализовано одинаково и производиться по единым правилам - 4.3.6.2. Требования к услугам информационно-консультационной поддержки работников Заказчика и пользователей Модуля СЦ Услуги информационно-консультационной поддержки сотрудников Заказчика включают: – обработку обращений и заявок, поступивших от сотрудников Заказчика; – консультирование сотрудников Заказчика и пользователей Модуля СЦ; – актуализацию документации, и других материалов по работе с Модулем СЦ при необходимости. – консультирование и разработку рекомендаций по настройке Модуля СЦ (без изменения программного кода), включая изменение настроек функционирования; – консультации по вопросам использования, настройки и возможностям Модуля СЦ; – консультации по проведению превентивных мер для недопущения аварийных ситуаций в Модуле СЦ; – консультации по предварительной диагностике и локализации возникшей неисправности Модуля СЦ; – консультации по вопросам обеспечения информационной безопасности Модуля СЦ и настройки функций, обеспечивающих корректную работу программного обеспечения для совершения юридически значимых действий в Модуле СЦ; – другие вопросы, связанные с работой Модуля СЦ. 4.3.6.2.1. Требования к порядку оказания услуг информационно-консультационной поддержки работников Заказчика и пользователей Модуля СЦ Подрядчик выполняет консультирование сотрудников Заказчика и пользователей Модуля СЦ. Консультация может быть предоставлена по согласованным с представителем Заказчика каналам коммуникации с регистрацией результата консультации в СРО Подрядчиком. Детальный порядок оказания консультационных услуг определен в Регламенте оказания Услуг - 4.3.6.3. Требования к услугам по решению инцидентов, связанных с работой ППО Подрядчик устраняет неисправности Модуля СЦ, связанные с работой ППО, выявленные в рамках оказания услуг согласно настоящему Техническому заданию, при этом в зону ответственности Подрядчика не входит устранение неисправностей, выявленных на стороне Заказчика и на стороне третьих лиц (провайдера связи, поставщика электропитания и т.д.). Первичная диагностика выявленной неисправности проводится на 1 и 2 уровнях технической поддержки и не входит в зону ответственности Подрядчика. Если при проведении первичной диагностики и попытке устранить неисправности на 1 и 2 уровнях технической поддержки, данную неисправность устранить не удалось и в процессе диагностики было выявлено, что проблема связана с работоспособностью ППО, обращение (заявка) назначается сотруднику Подрядчика, ответственному за оказание услуг технической поддержки 3 уровня. Инцидентами вне зоны ответственности Подрядчика являются: – работоспособность функциональности, выходящая за рамки текущей реализации функций в Модуле СЦ и/или являющаяся расширением требований Заказчика к функциям Модуля СЦ; – проведение профилактических и плановых работ, согласованных с Заказчиком; – нарушение работоспособности функций Модуля СЦ, вызванное проведением работ на стороне Заказчика - 4.5.11. Требования к показателям назначения 4.5.11.1. Требования к показателям назначения мероприятий по развитию Модуля СЦ В рамках выполнения работ по развитию Модуля СЦ, предусмотренных ТЗ, показатель назначения «Количество пользователей» должен соответствовать значениям, приведенным в данном разделе. Пояснения по показателям, связанным с количеством пользователей, приведены в Таблице 8. Таблица 8. Определения показателей, связанных с количеством пользователей в Модуле СЦ № Показатель Определение Расчетное количество пользователей Количество пользователей, работу которых должен обеспечить Модуль СЦ к моменту сдачи работ по Контракту с учетом достижения всех показателей назначения Расчетное количество одновременно работающих пользователей Количество одновременно работающих пользователей, работу которых должен обеспечивать Модуль СЦ к моменту сдачи работ по Контракту с учетом достижения всех показателей назначения Значения показателей количества пользователей, достижение которых необходимо обеспечить, представлено в Таблице 9 - Таблица 9. Значения показателей количества пользователей № Показатель Значение 1. Расчетное количество пользователей 1 000 2. Расчетное среднее количество одновременно работающих пользователей 200 Развитие Модуля СЦ должно быть направлено на достижение следующего эффекта (показателя), подставленного в мероприятии 103.002 «Информационно-аналитическая система регулирования на транспорте (АСУ ТК)» ВПЦТ Минтранса России: Выполнение работ по развитию Модуля СЦ предусмотрено мероприятием по развитию АСУ ТК, приведенном в ВПЦТ Минтранса России на 2026-2028 гг: № 103.002 «АСУ ТК» в составе ИТ расхода 103.26.000005 «Развитие предусматривает реализацию ОКР и эффектов, приведенных в Таблице 10. Таблица 10. ОКР и эффекты, приведенные в ВПЦТ Минтранса России на 2026 г. № ОКР Дата ОКР Эффекты 1 Обеспечено информационное взаимодействие с Минобороны России о происшествиях на транспортных объектах 25.12.2026 Сокращено время сбора и передачи сведений для Минобороны России о ЧС и НС на транспорте с 120 до 10 минут 2 Обеспечена автоматизация формирования отчетов о нештатных ситуациях на транспорте, в том числе по данным внешних систем 25.12.2026 Сокращено время на подготовку отчетов о нештатных ситуациях на транспорте с 20 до 5 минут Реализация остальных ОКР не является предметом данного ТЗ и проводится в рамках отдельного технического задания. - 4.5.11.2. Требования к показателям назначения мероприятий по эксплуатации Модуля СЦ. Работы по эксплуатации Модуля СЦ не должны обеспечивать режимы функционирования Модуля СЦ, приведенные в разделе 4.5.2 данного ТЗ - Работы по устранению неисправности приостанавливаются (по согласованию с Заказчиком) в следующих случаях: – если Подрядчиком в результате диагностики выявлено, что неисправность находится в зоне ответственности Заказчика. Подрядчик информирует Заказчика о выявленной неисправности в зоне его ответственности по согласованным каналам связи; – требуется действие со стороны Заказчика – до момента выполнения данного действия Заказчика. Заказчик информируется о необходимых действиях по согласованным каналам связи; – отсутствие возможности связаться со специалистами Заказчика, участие которых необходимо для устранения неисправности; – требуется доставить оборудование на объект – до момента доставки и установки оборудования. В случаях, представленных выше, время приостановки работ не входит в учет продолжительности устранения неисправности. Учет времени устранения неисправности Подрядчиком считается с момента назначения Инцидента специалисту Подрядчика, ответственному за оказание услуг технической поддержки 3 уровня. Подтверждение необходимости приостановления работ находится в зоне ответственности Подрядчика. Приостановление сроков выполнения задач в соответствии с настоящим пунктом подтверждается Заказчиком по мотивированному обращению Подрядчика в СРО, основанному на данных диагностики или на иных фактических обстоятельствах - В случае непринятия Подрядчиком необходимых мер по информированию Заказчика (отсутствие надлежащего обращения от Подрядчика или отсутствие уведомления о необходимости осуществления каких-либо действий Заказчиком) не может являться основанием для приостановления работ по устранению неисправности. В отдельных случаях Подрядчику может потребоваться выполнение технологических работ для устранения причин неисправности или недопущения повторения их в будущем. Для обеспечения устранения неисправности Модуля СЦ Заказчиком проводится классификация в соответствии с приоритетами по степени срочности их устранения. Продолжительность устранения неисправности, а также периодичность информирования Подрядчиком Заказчика о ходе устранения неисправности, определены в Регламенте оказания услуг. При подаче обращения (заявки) наивысшего приоритета через СРО Заказчик должен дополнительно проинформировать службу поддержки Подрядчика о созданном обращении (заявки) по телефону уполномоченного сотрудника Подрядчика. При этом временем подачи обращения (заявки) считается время подачи обращения (заявки) через СРО - 4.3.6.3.1. Требования к порядку оказания услуги по решению инцидентов, связанных с работой ППО При поступлении от Заказчика обращения (заявки), являющегося неисправностью в работе Модуля СЦ (инцидентом), Исполнитель реагирует на инцидент в СРО в срок не более 30 минут с момента поступления. В случае необходимости, для решения инцидента ответственный специалист должен связаться с инициатором обращения (заявки) для уточнения условий воспроизведения проблемы или для получения дополнительных сведений. После получения необходимых сведений от инициатора обращения (заявки) ответственный специалист производит диагностику с целью выявления причины инцидента и возможных путей устранения. В случае, если инцидент невозможно решить без получения дополнительных сведений от инициатора, и не удается связаться с инициатором в течение пяти рабочих дней, обращение (заявка) отклоняется в связи с недостатком данных для его решения, Заказчику направляется уведомление об отклонении обращения (заявки). Время, в течение которого невозможно связаться с инициатором, вычитается из общего времени обработки обращения (заявки). Все попытки связаться с инициатором должны фиксироваться с указанием даты и времени попытки, используемого способа связи (номер телефона, адрес электронной почты) и результата попытки (не удалось дозвониться, абонент недоступен, и т.д.) - Факт и время решения инцидента должны быть зафиксированы и отражены в СРО. В случае, если причиной сбоя в работе Модуля СЦ является выход из строя аппаратного обеспечения или неработоспособность смежной информационной системы, время работы над инцидентом приостанавливается до момента устранения неисправности. В ходе решения инцидентов могут быть выявлены дефекты ППО Модуля СЦ. В случае обнаружения дефектов ППО, Подрядчик информирует об этом Заказчика. Исполнитель может быть привлечен к проверке результата устранения дефекта по инициативе Заказчика. Приоритеты инцидентов приведены в Приложении Б к ТЗ. Детальный порядок оказания услуги по решению инцидентов, связанных с работой ППО Модуля СЦ определен в Регламенте оказания Услуг - 4.3.6.4. Требования к услугам адаптационного, конфигурационного и коррекционного сопровождения и доработки Модуля СЦ (в рамках действующих программных модулей и функциональностей) Услуги адаптационного, конфигурационного и коррекционного сопровождения и доработки Модуля СЦ включают: – управление изменениями и адаптация функций Модуля СЦ; – изменение настроек функционирования Модуля СЦ; – внесение изменений и/или модификаций Модуля СЦ (в рамках действующих программных модулей и функциональностей), направленных на улучшение их работоспособности и функциональных возможностей; – подготовка и передача Заказчику SQL запросов в СУБД для получения агрегированной информации из Модуля СЦ, которую невозможно получить с использованием графического пользовательского интерфейса; – адаптация модулей интеграций со смежными информационными системами - 4.3.6.4.1. Требования к проведению изменений Основанием для внесения изменений является запрос от Заказчика. Все активности по внесению изменений должны быть согласованы с Заказчиком, а действия Подрядчика при оказании данной услуги должны быть зафиксированы. В рамках данного Технического задания изменениями считаются локальные доработки функционала Модуля СЦ, которые не должны приводить к необходимости выполнения дополнительных аттестационных испытаний или переаттестации АСУ ТК в соответствии с п. 33 приказа от 29.04.2021 № 77 «Об утверждении Порядка организации и проведения работ по аттестации объектов информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну». При необходимости внесения изменений в Модуль СЦ, не связанных с критичным инцидентом, существенно нарушающим работоспособность Модуля СЦ, Заказчик направляет Подрядчику обращение (заявку), в котором излагает суть изменения, которое требуется внести в Модуль СЦ. Исполнитель, в течение 3 (трех) рабочих дней с момента поступления соответствующего обращения (заявки), оценивает техническую возможность реализации запрашиваемого изменения и варианты реализации. По итогу проведения оценки Подрядчик направляет Заказчику заключение о возможности реализации данного изменения с описанием возможных вариантов реализации и согласует с Заказчиком проведение данного изменения - При проведении работ по изменению и адаптации Подрядчик должен: – обеспечить выполнение требований безопасной разработки программного обеспечения; – обеспечить предварительное проектирование технических решений и согласование с Заказчиком проекта реализации изменения; – использовать семантическое версионирование (SemVer) в работе, передать Заказчику все артефакты разработки (исходный код и сторонние библиотеки, конфигурации, сборочные и собранные образы и др.); – подготовить полноценное описание функционала, включенного в релиз, с необходимыми схемами и пояснениями к обновлению на стендах Заказчика; – обеспечить тестирование разработанного функционала на стендах Заказчика силами Подрядчика; – решение о переносе измененного ППО на продуктивный стенд принимается Заказчиком по итогу результатов проведенного тестирования; – обеспечить техническое сопровождение процедуры тестирования ППО и переноса измененного ППО на продуктивный стенд Заказчика; – обеспечить экстренное внесение соответствующих изменений в случае выявления некорректной работы продуктивного стенда Заказчика после проведения обновления по итогам разработанного изменения в кратчайшие сроки; – актуализировать при необходимости комплект эксплуатационной документации: o руководство пользователя; o руководство администратора; o иные документы (при необходимости). Результат выполнения изменений должен быть отражен в Отчете по оказанию услуг. Типы и приоритеты изменений могут быть скорректированы в процессе оказания услуг исключительно по согласованию с Заказчиком - 4.3.6.4.2. Требования к изменению настроек функционирования Изменение настроек функционирования может проводиться в рамках допустимых пределов изменения функционирования, заложенных в архитектуру Модуля СЦ. Изменение настроек функционирования включает в себя изменение данных и справочников, изменение форм документов, формируемых Модулем СЦ, изменение и настройку форматов и версий передачи данных в смежные системы. Доработка программного кода Модуля СЦ может допускаться (в случае необходимости) при выполнении работ по адаптации функций Модуля СЦ в части изменения формата передачи данных в смежные информационные системы при условии соблюдения требований пункта 29.3 приказа ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации» - 4.3.6.5. Требования к услугам по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности По запросу Заказчика Подрядчик должен провести работу по приведению ППО в соответствие с требованиями по обеспечению информационной безопасности. Критичность уязвимости оценивается в соответствии в соответствии с Методическим документом ФСТЭК России «Методика оценки уровня критичности уязвимостей программных, программно-аппаратных средств» (утвержден ФСТЭК России 30.06.2025), а также с учетом ГОСТ 56545-2015 и международными стандартами (CVSS 3.0 и выше), и задает необходимый срок устранения. В процессе проведения Заказчиком обследования Модуля СЦ и выявления уязвимостей в ППО, связанных с исходным кодом Модуля СЦ и/или используемыми компонентами (библиотеками), Заказчик направляет Подрядчику обращение (заявку) на устранение, с указанием критичности и срочности принятия мер по устранению в СРО. - Подрядчик при оказании услуг по обновлению или устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности должен: – провести анализ уязвимостей и связанных с ними исходным кодом и/или используемыми компонентами (библиотеками); – выработать варианты устранения указанных уязвимостей и согласовать с Заказчиком их реализацию; – своевременно внести изменения в исходный код Модуля СЦ и/или используемые компоненты (библиотеки) и подготовить соответствующее обновление; – провести обновление Модуля СЦ в тестовом контуре Заказчика и проинформировать Заказчика о готовности проведения тестирования; – протестировать успешность обновления или устранения уязвимостей в ППО и корректность функционирования Модуля СЦ на тестовом контуре, совместно с Заказчиком; – при невозможности незамедлительного устранения уязвимости приоритетов «Критический» и «Высокий» Подрядчик обязан предоставить исчерпывающий список причин и согласовать план достаточных компенсирующих мер с ответственными сотрудниками Заказчика. Результат внесения изменений отображается в соответствующей записи в СРО и в составе Отчета об оказанных услугах - 4.3.6.5.1. Требования к порядку оказания услуг по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности Подрядчик в соответствии с приоритетами обращений и контрольными сроками исполнения (см. Приложение Б к ТЗ) оценивает техническую возможность и сроки устранения уязвимостей, и реализацию обновления Модуля СЦ. По итогу проведения оценки Подрядчик направляет в заявке СРО Заказчику заключение о возможности устранения уязвимостей и/или обновления в ППО и согласует с Заказчиком проведение данных работ - При проведении работ по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности необходимо выполнить следующее: – Заказчику сформировать заявку на устранение (обновление) в СРО с полным списком обнаруженных уязвимостей и планируемыми работами; – согласовать в рабочем порядке время начала и завершения работ, перечень работ, выполняемых в рамках обновления или устранения уязвимостей в ППО с Заказчиком; – оповестить Заказчика о начале проведения работ на тестовом контуре; – провести работы по обновлению или устранению уязвимостей в ППО на тестовом контуре Модуля СЦ в установленные сроки; – протестировать выполнение работ в тестовом контуре и проинформировать Заказчика о готовности переноса ППО на продуктивный контур; – силами Заказчика обновить продуктивный контур Модуля СЦ, в соответствии с планом устранения и выполненными работами; – совместно с Заказчиком проверить корректность функционирования Модуля СЦ и устранения уязвимостей в продуктивном контуре Модуля СЦ по результатам обновления; – при необходимости актуализировать документацию (описание архитектуры, анкеты постановки на мониторинг и иные документы). Любые изменения в части обновления или устранения уязвимостей в ППО на промышленном контуре Модуля СЦ должны применяться только в случае успешного проведения аналогичных работ на тестовом контуре. Детальный порядок оказания услуги по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности определен в Регламенте оказания Услуг - 4.4. Требования к видам обеспечения 4.4.1. Требования к лингвистическому обеспечению Документация на Модуль СЦ должна разрабатываться на русском языке. Взаимодействие пользователей с Модулем СЦ посредством графического интерфейса должно происходить на русском языке за исключением сообщений, зависящих от настроек системного программного обеспечения, установленного на рабочих местах пользователей. При разработке программных решений Модуля СЦ должно быть предусмотрено использование языков программирования высокого уровня, приведенных в Таблице 7. Таблица 7. Языки и средства разработки, специального программного обеспечения Модуля СЦ Категория Наименование Назначение Языки программирования Kotlin Разработка серверной логики и сервисов (backend) JavaScript / TypeScript Разработка клиентской части (frontend) Python Разработка скриптов интеграции, обработки данных и автоматизации Фреймворки и библиотеки Vue.JS Разработка пользовательских интерфейсов (веб-интерфейсы компонентов визуализации и отчетности) React Разработка пользовательских интерфейсов (при необходимости создания сложных интерактивных компонентов) Решения по лингвистическому обеспечению, включая перечень используемых языков программирования, должны быть согласованы с Заказчиком на этапе технического проектирования - 4.4.2. Требования к математическому обеспечению Требования к математическому обеспечению не предъявляются. 4.4.3. Требования к метрологическому обеспечению Требования к метрологическому обеспечению не предъявляются. 4.4.4. Требования к организационному обеспечению Требования к организационному обеспечению не предъявляются. 4.4.5. Требования к методическому обеспечению Задачи методического обеспечения Модуля СЦ должны быть обеспечены за счет использования технологических и методических документов касающихся вопросов функционирования транспортного комплекса и разработки и эксплуатации ПО. 4.4.6. Требования к информационному обеспечению Состав, структура и способы организации информационного обеспечения в Модуле СЦ должны быть определены на этапе технического проектирования. Факты информационного обмена с внешними системами должны фиксироваться в соответствующем журнале - 4.1. Требования к структуре Модуля СЦ В процессе работ по развитию Системы должны сохраниться основные требования к построению архитектуры Системы в соответствии с принципами трехуровневой архитектуры: 1. уровень хранения данных или уровень базы данных (сервер СУБД); 2. уровень сервера приложений (сервер аналитической обработки); 3. презентационный уровень, обеспечивающий взаимодействие с клиентскими приложениями. В состав Системы должны входить следующие основные компоненты: 4. сервер баз данных; 5. сервер приложений; 6. веб-сервер. Сервер баз данных должен обеспечивать хранение и целостность хранимых данных, создание резервных копий, ведение журнала транзакций, восстановление данных после сбоев. Сервер приложений должен обеспечивать обработку запросов, поступающих от клиентских приложений (через веб-сервер), формирование ответов на запрос в доступном пользователю виде (формирование пользовательских интерфейсов). Веб-сервер должен обеспечивать взаимодействие с оператором и внешними системами по HTTP / HTTPS протоколу в режиме «запрос-ответ» (получения запросов от пользователя и передачи ответа в виде соответствующей информации, обработанной серверами приложений). Взаимодействие Системы с пользователем должно отвечать требованиям модели «тонкого клиента» (т.е. представлять на стороне клиента (пользователя) лишь графический пользовательский интерфейс). Все составляющие Системы должны использовать единую методологию и отвечать единым принципам взаимодействия, надежности и управления. Перечень компонентов Модуля СЦ представлен в Таблице 4. Таблица 4. Перечень компонентов Модуля СЦ, в отношении которых выполняются работы по развитию № п.п. Наименование компонента Модуля СЦ Раздел ТЗ 1 Компонент регистрации событий 4.2.1. 2 Компонент отчетности 4.2.2 3 Компонент визуализации 4.2.3 4 «Интерактивная карта» (компонент создается) 4.2.4 5 Компонент администрирования 4.2.5 - 4.2. Требования к дорабатываемым функциям модуля СЦ 4.2.1. Развитие компонента регистрации событий (1 очередь) Должны быть выполнены следующие доработки: – обеспечение логирования действий пользователя, связанных с карточкой события; – доработка объектной модели в части создания новых типов сущностей (карточек) с учетом реализуемых интеграций с информационными ресурсами (силы и средства предупреждения и ликвидации ЧС и нештатных ситуаций на транспорте, ТС, ограничения воздушного пространства, неблагоприятные и опасные природные явления); – реализация механизма установления связи между сущностями в Модуле СЦ автоматизированным и ручным способами (события, природные явления, силы и средства предупреждения и ликвидации ЧС и нештатных ситуаций на транспорте, ограничения воздушного пространства, ОТИ, ТС и др.); – отображение в карточке установленных связей между сущностями. - 4.4.7. Требования к программному обеспечению Общесистемное ПО, используемое в составе Модуля СЦ, должно быть зарегистрировано в Едином реестре российских программ для электронных вычислительных машин и баз данных и соответствовать рекомендованным показателям эффективности и соответствующим им значениям индикаторов эффективности перехода подведомственных организаций на использование российского ПО, заданных Приказом Минцифры России от 18.01.2023 № 21 «Об утверждении методических рекомендаций по переходу на использование российского программного обеспечения, в том числе на значимых объектах критической информационной инфраструктуры Российской Федерации, и о реализации мер, направленных на ускоренный переход органов государственной власти и организаций на использование российского программного обеспечения в Российской Федерации». Применяемое в системе программное обеспечение должно соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации, постановления Правительства Российской Федерации от 23 декабря 2024 г. № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц» - Прикладное программное обеспечение должно отвечать следующим требованиям: – совместимость программных продуктов в части используемых технических средств, системного программного обеспечения и общесистемной инфраструктуры в пределах требований к техническому обеспечению, а также их информационная совместимость в пределах требований к информационному обмену; – обеспечение трехуровневой архитектуры с разделением на уровень хранения данных (сервер БД), уровень бизнес-логики (сервер приложений) и уровень представления ( - 4.4.7.1. Требования к инструментам разработки и процессу контроля версий программного обеспечения 4.4.7.1.1. Система контроля версий Для управления исходным кодом должна использоваться система контроля версий кода, развернутая в инфраструктуре Заказчика. 4.4.7.1.2. Правила именования веток Имя ветки должно соответствовать следующему формату: / / Категории веток: ? feature/ — разработка новой функциональности, а также рефакторинг или удаление существующей; ? fix/ — исправление ошибок; ? hotfix/ — срочные исправления, применяемые в обход стандартного процесса разработки; ? test/ — для проведения экспериментов, не влияющих на основную разработку. Идентификатор задачи: после категории указывается ссылка на задачу (issue) в системе контроля версий кода. Описание: добавляется краткое описание решаемой задачи в формате kebab-case (слова разделяются дефисами, например, add-user-auth). Примеры именования веток: ? feature/#123/add-payment-integration; ? fix/#45/correct-calculation-logic; ? hotfix/#67/urgent-database-connection-patch. 4.4.7.1.3. Правила именования коммитов Сообщение коммита должно соответствовать соглашению Conventional Commits и состоять из категории и описания: : ? fix — исправление ошибки. Примеры сообщений коммитов: ? feat: добавление формы регистрации пользователя; ? fix: исправление ошибки валидации email-адреса; ? refactor: оптимизация алгоритма сортировки данных; ? chore: обновление версий в файле dependencies. 4.4.7.1.4. Модель ветвления В процессе разработки используются следующие основные ветви: ? main / master — стабильная ветка, содержит только код, прошедший полное тестирование и развернутый в продуктивных контурах; ? dev — ветка для интеграции завершенных задач, предназначенная для сборки и тестирования в тестовых средах. Попадание кода в main осуществляется только через Merge Request (MR) из dev - 4.2.2. Развитие компонента отчетности (3 очередь) Должна быть обеспечена автоматизация процессов формирования отчетов о ЧС и нештатных ситуациях на транспорте, в т.ч. на основе данных из внешних систем. Включает следующие доработки: – разработка шаблонов отчетов в различных форматах (табличный, текстовый); – реализация выбора фотоматериалов для включения в справку; – форматирование содержимого справок с учетом правил русского языка в отношении окончаний слов (в зависимости от падежа, склонения, числа и рода); – автоматизированное формирование выводов к содержимому справки на основе настраиваемых критериев; – создание интерфейса выбора параметров (фильтрации) для формирования отчетов: o состав полей для включения в отчёт; o настройка диапазонов значений характеристик и дат; o порядок отображения полей; o настройка заголовка. – реализация способа подготовки отчётов в асинхронном режиме (очереди); – реализация интерфейса компонента формирования отчетности для отображения очереди формирования отчетов и статусов их подготовки; – экспорт отчётов в форматы xlsx, csv и справок в форматы pdf, docx. Необходимо разработать не менее 10 шаблонов отчетов и/или справок. Перечень, структура и содержание шаблонов должны быть согласованы с Заказчиком на этапе технического проектирования. - 4.2.3. Развитие компонента визуализации (2 очередь) В рамках развития компонента визуализации должны быть выполнены следующие доработки, обеспечивающие: – вывод перечней (списков) сил и средств предупреждения и ликвидации ЧС и нештатных ситуаций на транспорте с отображением мест их постоянного размещения (дислокации) на карте, включая: o отображение зон ответственности на карте; o возможность их фильтрации (по видам транспорта, регионам и пр.); o реализацию инструмента расчета расстояния (с использованием сети автомобильных и железных дорог) между местом события и местами дислокации сил и средств, а также вывода маршрутов на карте; – отображение зон (полигонов) с установленными ограничениями движения в воздушном пространстве на карте; – отображение термических точек; – реализация возможности отображения данных из паспорта региона, отображаемого в модуле iМинтранс (модуль АСУ ТК); – отображение краткой карточки сущностей и ОТИ (краткой информации и/или динамических характеристик объекта) при выборе объекта на карте с возможностью перехода в полную карточку сущности и ОТИ; – отображение данных от Росгидромета, предусматривающих: o отображение неблагоприятных и опасных природных явлений на карте (с заданным периодом обновления данных); o управление отображением явлений на карте, включая настройку состава отображаемых объектов, поиск, фильтрацию, с использованием соответствующей панели управления; o выведение краткой карточки явления при выборе объекта, с возможностью перехода в полную карточку объекта - – отображение на карте связанных сущностей и ОТИ; – реализация функции выбора темного и светлого стилей отображения элементов интерфейса, карточек сущностей, картографической основы и объектов, отображаемых на карте; – реализация механизма для выбора картографической основы в одном из распространенных форматов WMTS, TMS, MVT и др. Должна быть предусмотрена возможность настройки перечня картографических основ и параметров доступа к ним; – настройка базового набора дашбордов, содержащих преднастроенные виджеты о количестве событий в разрезе видов транспорта с возможностью перехода к исходным данным (карточкам событий, ОТИ и т.д.), с фильтрацией по параметрам. Параметры фильтрации должны быть определены на этапе технического проектирования. Должно быть обеспечено автоматическое и принудительное обновление данных, отображаемых на дашбордах - 4.4.7.1.5. Требования к используемым зависимостям (библиотекам) Все внешние зависимости проекта должны быть зафиксированы с указанием точных версий. Для контроля версий зависимостей в репозиторий обязательно должны быть включены следующие файлы: · Для JavaScript: package-lock.json или yarn.lock; · Для Python: requirements.txt (с зафиксированными версиями) или Pipfile.lock; · Для Go: go.mod и go.sum; Загрузка всех зависимостей должна производиться исключительно через внутренний прокси-репозиторий Заказчика, настроенный в соответствующем системе менеджере пакетов. Запрещается: · Использование плавающих версий (например, ^1.2.3, ~4.5.0, latest); · Использование библиотек, содержащих критические уязвимости, в том числе зарегистрированные в реестре CVE (Common Vulnerabilities and Exposures). 4.4.7.1.6. Требования к процессу непрерывной интеграции (CI) Сборка программного обеспечения, включая этапы компиляции, тестирования и анализа кода, должна выполняться исключительно в инфраструктуре непрерывной интеграции Заказчика. 4.4.7.1.7. Требования к хранению артефактов сборки Все артефакты сборки (результирующие пакеты, Docker-образы и т.д.) подлежат обязательному хранению в предназначенной для этого инфраструктуре Заказчика (артефакторий). Запрещается размещение финальных артефактов сборки на сторонних ресурсах - 4.4.8. Требования к техническому обеспечению Количество серверов, подключаемых и настраиваемых сервисов, их параметров, схемы соединений и настройки межсетевого взаимодействия должны быть согласованы с Заказчиком на этапе № 1 Техническое проектирование. Доступ к комплексу технических средств предоставляется Заказчиком по письменному запросу Подрядчика. Применяемые в Системе программно-аппаратные и аппаратные комплексы должны соответствовать требованиям Указа Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации», требованиям Постановления Правительства Российской Федерации от 23 декабря 2024 г. № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц». Модуль СЦ, работающий в составе АСУ ТК, развернут на вычислительных мощностях ГЦОД СИЦ Минтранса России - 4.5. Общие технические требования 4.5.1. Требования к численности и квалификации персонала и пользователей Модуля СЦ Программное обеспечение Модуля СЦ не должно требовать изменения штатной численности персонала Заказчика. Программное обеспечение Модуля СЦ не должно требовать наличия у пользователей дополнительной квалификации в сфере информационных технологий, кроме базовых знаний в обращении с персональным компьютером, базовых навыков работы в интернет-обозревателях и знаний о Модуле СЦ в объеме документов Руководство пользователя, Руководство администратора - 4.2.4. Создание компонента «Интерактивная карта» (2 очередь) В составе создаваемого компонента должны отображаться данные, доступные в компоненте визуализации. Требования к интерфейсу интерактивной карты: – интерактивная карта должна быть представлена в виде объемной карты с учетом макетов, представленных в Приложении А к ТЗ; – интерфейс должен корректно отображаться на экранах мониторов (разрешение Full HD 1920?1080), телевизоров (разрешение 4К 3840?2160), жидкокристаллических панелей для видеостены, используемой Заказчиком, с параметрами каждой панели: диагональ 55 дюймов, разрешение 1920x1080; – интерфейс должен корректно отображаться на планшетных устройствах с диагональю экрана 10-12 дюймов, конкретные требования должны быть уточнены на этапе технического проектирования; – должна быть обеспечена кластеризация и генерализация отображения объектов на карте при изменении масштаба; – должно быть обеспечено отображение основных характеристик объектов при выборе их на карте; – должно быть обеспечено управление отображением слоев на карте; – должна быть обеспечена настройка цветовой индикации отображаемых объектов транспортной инфраструктуры; – должно быть обеспечено отображение легенды карты, содержащей отображаемые объекты на карте; – должна быть обеспечена возможность одновременного отображения не менее 5 000 ОТИ и ТС на карте. - На интерактивной карте должны быть отображены подвижные объекты совместно с объектами транспортной инфраструктуры (ОТИ), включая следующие возможности: § отображение местоположения транспортных средств (воздушный, водный и автомобильный транспорт) на карте в режиме реального времени (с заданным периодом обновления данных); § отображение маршрутов движения всех ТС за выбранный период времени, в том числе с использованием эффектов анимации; § отображение маршрутов движения ТС, связанных с карточкой события: ТС, являющихся участниками события, и ТС, находящиеся в заданном радиусе от события; § управление отображением сущностей и ОТИ на карте, включая настройку состава отображаемых объектов, поиск, фильтрацию, с использованием соответствующей панели управления и наглядным представлением результатов; § автоматическое изменение вида отображения объектов (цветовая индикация) по заданным условиям (например, при достижении критических значений параметров, характеризующих функционирование объекта); Должна обеспечиваться производительность обновления изображения на экране в 30 кадров в секунду на тестовой конфигурации пользовательского устройства (модель Бештау AIO2402/B560, входящая в Реестр российской промышленной продукции под номером 10394100 или аналог) при одновременном отображении не менее 5 000 объектов и 200 уникальных моделей объектов. Макеты интерфейсов Модуля СЦ должны быть предварительно согласованы с Заказчиком и разработаны с учетом требований ГОСТ Р ИСО 9241-161-2016 «Элементы графического пользовательского интерфейса» - 4.5.2. Требования к режимам функционирования Модуля СЦ Модуль СЦ должен предусматривать наличие следующих режимов работы: – штатный; – регламентный (профилактический); – аварийный. Основным режимом функционирования является штатный. В штатном режиме все компоненты корректно и полностью выполняют свои функции. Перерывов в работе как Модуля СЦ в целом, так и одного, либо нескольких компонентов не предусмотрено. Режим регламентного (профилактического) обслуживания предназначен для проведения работ по обновлению и техническому обслуживанию компонентов Модуля СЦ, а также резервному копированию данных. При работе в данном режиме допускаются перерывы в работе Модуля СЦ с предварительным информированием пользователей. Состав процедур по регламентному обслуживанию Модуля СЦ и их периодичность определяются Подрядчиком в процессе выполнения работ по созданию Модуля СЦ. В режиме регламентного (профилактического) обслуживания Модуль СЦ может функционировать с частичным ограничением своих функциональных возможностей, либо без ограничения, но со снижением показателей надежности и производительности. Перевод в данный режим работы должен осуществляться сразу после начала выполнения любой операции, отнесенной к этому режиму, с последующим возвратом в штатный режим функционирования сразу после ее завершения. Перевод в указанный режим должен осуществляться при возникновении необходимости проведения работ по обновлению и техническому обслуживанию компонентов Модуля СЦ, а также резервному копированию данных с условием предварительного оповещения пользователей. Аварийный режим функционирования характеризуется отказом одной или нескольких подсистем, вызванных выходом из строя аппаратного и/или программного обеспечения, а также в случае временной неработоспособности каналов связи между серверами. - В аварийном режиме осуществляется поиск неисправностей и проведение работ по их устранению. Перевод в аварийный режим должен осуществляться при возникновении сбоев, аварий и прочих незапланированных воздействий, сразу после наступления одной или нескольких аварийных ситуаций, с последующим возвратом в штатный режим функционирования сразу после окончания восстановительных работ. ПО Модуля СЦ должно обладать надежностью, обеспечивающей работу пользователей в произвольном режиме и оперативное восстановление работоспособности при сбоях. В целях обеспечения надежного функционирования ПО должно предусматривать: – сохранение целостности данных при нештатном завершении работы компонентов Модуля СЦ; – сохранение работоспособности программного обеспечения при некорректных действиях пользователя; – резервное копирование базы данных Модуля СЦ. – время восстановления работоспособности Модуля СЦ после отказа не более 4 часов. – отказоустойчивость на уровне 99% при единовременной количестве не менее 200 пользовательских сессий в Модуле СЦ. Указанные характеристики приведены без учета характеристик надежности инфраструктуры и времени передачи информации по каналам связи. При возникновении сбоев в аппаратном обеспечении, включая аварийное отключение электропитания, Модуль СЦ должен автоматически восстанавливать свою работоспособность (не требовать перенастройки) после устранения сбоев и корректного перезапуска аппаратного обеспечения - 4.2.4.1. Требования к технической реализации компонента «Интерактивная карта» При реализации компонента «Интерактивная карта» должны учитываться требования, указанные ниже. 4.2.4.1.1. Требования к отображению элементов Повторяющихся элементы карты (ТС, ОТИ, события и пр.) должны отрисовываться с использованием аппаратного создания экземпляров объектов на пользовательском устройстве (WebGL/WebGPU)). Отрисовка каждого объекта отдельным запросом не допускается, должна обеспечиваться возможность одновременного отображения не менее 5 000 объектов без снижения производительности (30 кадров в секунду на тестовой конфигурации). 4.2.4.1.2. Уровни детализации объектов Для управления отображением сложных объектов должно быть создано не менее 3-х уровней детализации, отображаемых при изменении масштаба с возможностью автоматического переключения между уровнями. Все отображаемые объекты должны масштабироваться с учетом разрешения экрана пользователя с сохранением качества детализации. 4.2.4.1.3. Полигональная оптимизация и текстурирование При реализации компонента «Интерактивная карта» должна обеспечиваться технология рельефного тестурирования объектов. Не должны использоваться высокополигональные трехмерные модели. Все повторяющиеся элементы должны генерироваться единоразово и повторно использоваться при последующих отображениях. 4.2.4.1.4. Управление памятью Требуется реализовать потоковую загрузку на устройство пользователя элементов карты и текстур. Загрузка данных целиком при старте приложения не допускается. Необходимо реализовать механизм очистки памяти от элементов, которые находятся вне области видимости камеры в течение заданного времени. 4.2.4.1.5. Требования к взаимодействию пользователя с интерфейсом компонента «Интерактивная карта» Программная реализация механизмов управление камерой (масштабирование и навигация) должна быть выполнена с поддержкой технологии WebAssembly (WASM). Элементы управления должны являться неотъемлемой частью интерактивной карты. - 4.2.5. Развитие компонента администрирования (3 очередь) Должна быть выполнена доработка ролевой модели. Ролевая модель должна обеспечивать управление доступом к отдельным объектам Модуля СЦ и их элементам (атрибутам) с разграничением по видам транспорта, регионам и пр., в частности: – определение набора конкретных действий, доступных пользователям (выполняемых над объектом доступа, например, удаление записи, редактирование записи, формирование отчета и др.); – реализация возможности объединения пользователей в группы; – определение прав доступа для групп пользователей; – реализация интерфейса визуальной настройки прав доступа пользователей к объектам Модуля СЦ - Технические меры по обеспечению надежности должны предусматривать: – резервирование критически важных компонентов и данных Системы и отсутствие единой точки отказа; – использование программного резервирования (программной избыточности); – изменение конфигурации используемых средств и применение специализированного ПО, обеспечивающего высокую надёжность. Организационные меры по обеспечению надежности должны быть направлены на минимизацию ошибок пользователей (а также обслуживающего персонала при эксплуатации и проведении работ по обслуживанию), минимизацию времени ремонта или замены вышедших из строя компонентов за счёт: – обеспечения для обслуживающего персонала требуемого уровня квалификации; – регламентации и нормативного обеспечения выполнения работ обслуживающим персоналом; – своевременной диагностики неисправностей. Расчетное значение коэффициента доступности Модуля СЦ должно составлять не менее 0,95. - 4.5.3. Требования по диагностированию Модуля СЦ Диагностирование Модуля СЦ должно осуществляться путем анализа записей в системных журналах СУБД, операционных систем серверов, а также с помощью встроенных средств диагностирования общего программного обеспечения Модуля СЦ. Диагностированию подлежат: – сбои и нарушения функционирования технического обеспечения (серверов) Модуля СЦ; – сбои и нарушения функционирования системного программного обеспечения серверов, используемых для работы Модуля СЦ; – сбои и нарушения функционирования прикладного программного обеспечения серверов, используемых для работы Модуля СЦ; – случаи недоступности (отсутствия ответа) или некорректные ответы внешних систем; – сбои и нарушения функционирования СУБД; – сбои при выполнении регламентных операций резервного копирования. При возникновении аварийных ситуаций либо ошибок в программном обеспечении диагностические инструменты должны позволять сохранять набор информации, необходимой для идентификации и устранения проблемы. Модуль СЦ и ее компоненты должны обеспечивать возможность диагностики своей работоспособности с возможностью интеграции с модулем мониторинга АСУ ТК. Набор передаваемых журналов и метрик должен быть определен на этапе технического проектирования - 4.5.4. Требования к надежности Должно быть предусмотрено сохранение работоспособности Модуля СЦ при некорректных действиях пользователя и сохранение целостности данных при нештатном завершении работы Модуля СЦ (отказ рабочей станции, потеря сетевого доступа и т.п.). Модуль СЦ должен предоставлять механизмы обеспечения сохранности данных через применение процедур резервного копирования и восстановления, описанных в документации на Систему. Ключевые показатели надежности информационной системы — допустимое время на восстановление работоспособности Модуля СЦ (RTO - recovery time objective) и/или допустимый интервал времени потери изменений в данных при сбоях/отказах (RPO – recovery point objective) должны быть определены Подрядчиком и согласованы с Заказчиком на этапе технического проектирования - 4.2.6. Взаимосвязи с внешними автоматизированными системами (1 очередь) Способы взаимодействия с внешними информационными системами должны быть определены на этапе технического проектирования. Должны быть выполнены следующие доработки: – интеграции с информационными ресурсами в целях получения данных о движении подвижных ТС (воздушные суда, суда водного транспорта); – интеграция с информационным ресурсом в целях получения данных о событиях на железнодорожном транспорте. Реализация интеграций должна включать проектирование и реализацию интеграционных механизмов обмена данными с учетом доступных вариантов реализации, обеспечение защищенных способов взаимодействия, настройку отображения отдельных данных на карте (настройка слоев). Взаимодействия, имеющие каналы связи, выходящие за пределы контролируемой зоны взаимодействующих систем, считаются защищенными, если для их защиты используются программные и/или программно-аппаратные шифровальные (криптографические) средства, сертифицированные ФСБ России (далее – СКЗИ). Выбор СКЗИ, схемы подключения и требуемого класса криптостойкости должен производиться в соответствии с Техническими условиями на подключение к информационным ресурсам ФГБУ «СИЦ Минтранса России» и инструкциями по подключению пользователей к ресурсам инфраструктуры Головного центра обработки данных, утвержденных приказом директора ФБГУ «СИЦ Минтранса России» от 24.05.2024 № 21-ОД - 4.3. Требования к оказанию услуг по технической поддержке Модуля СЦ 4.3.1. Общие требования к оказанию Услуг Техническая поддержка Модуля СЦ должна осуществляться с учетом требований постановления Правительства Российской Федерации от 06.07.2015 N 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации». Подрядчик обязан выполнять требования законодательства в сфере защиты информации, требования по защите информации, информационной безопасности, указанные в локальных нормативных актах ФГБУ «СИЦ Минтранса России», регламентирующих условия информационного взаимодействия, защиты информации и подключения к информационным ресурсам ФГБУ «СИЦ Минтранса России», участвующих в информационном взаимодействии в рамках оказания услуг по технической поддержке АСУ ТК в 2026 году - 4.3.1.1. Требования к составу и содержанию услуг третьего уровня технической поддержки Оказание услуг по технической поддержке Системы осуществляется в рамках этапов в соответствии с календарным планом. Подрядчик в течение 5 рабочих дней с даты заключения Контракта должен предоставить со своей стороны, а Заказчик со своей стороны Матрицу ответственных за взаимодействия в соответствии с Приложением 1 к Регламенту оказания услуг по третьему уровню технической поддержки Модуля СЦ (далее – Регламент, Приложение В). Подрядчик в течение 10 рабочих дней с даты заключения Контракта должен провести мероприятия по организации третьего уровня технической поддержки в соответствии с Регламентом. Услуги по третьему уровню технической поддержки Модуля СЦ должны включать: – организацию Подрядчиком третьего уровня технической поддержки; – информационно-консультационную поддержку работников Заказчика; – решение инцидентов, связанных с работой ППО; – адаптационное, конфигурационное и коррекционное сопровождение Модуля СЦ (в рамках действующих программных модулей и функциональности); – устранение уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности - 4.5.5. Требования к информационной безопасности Работы по защите информации/информационной безопасности, не включенные в состав настоящего раздела, требуемые в соответствии с требованиями постановления Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации», а также нормативно правовых актов в области защиты персональных данных и обеспечения безопасности объектов критической информационной инфраструктуры, будут проведены в рамках исполнения отдельного контракта, заключенного по результатам отдельной закупочной процедуры (не является частью данного ТЗ), включающего: – определение актуальных угроз безопасности информации и актуализация модели угроз безопасности информации (при необходимости); – выполнение требований о согласовании технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России в установленном порядке; – выполнение требований по устранению Подрядчиком замечаний и недостатков, в случае их выявления при согласовании Заказчиком технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России; – выполнение требований к классу защищенности ГИС, уровню защищенности персональных данных и категории значимости объекта КИИ РФ, установленных для Головного центра обработки данных ФГБУ «СИЦ Минтранса России» (далее – ГЦОД); - – определение перечня объектов защиты информационной системы; – описание (актуализированных) требований к системе защиты информации, а также к мерам защиты информации информационной системы в зависимости от установленных классов защищенности, уровня защищенности персональных данных и категории значимости объектов КИИ РФ (приказы ФСТЭК России № 21, 117, 239); – выполнение требований к мерам по защите ГИС от атак, направленных на отказ в обслуживании, в соответствии с пунктами 30, 34, 59, 63 Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений, утвержденных приказом ФСТЭК России от 11.04.2025 № 117; – описание (актуализированных) требований по защите информации, подлежащих реализации в информационно телекоммуникационной инфраструктуре ГЦОД; – выполнение требований о применении сертифицированных средств защиты информации, включая их классы защиты и уровни доверия; – выполнение требований о запрете использования с 01.01.2025 органами (организациями) средств защиты информации странами происхождения, которых являются иностранные государства в соответствии с пунктом 6 Указа Президента Российской Федерации от 01.05.2022 № 250; – выполнение требований по обеспечению непрерывного взаимодействия с ГосСОПКА в установленном порядке; - 4.3.1.2. Требования к общему порядку оказания услуг Техническая поддержка Модуля СЦ должна быть организована на трех уровнях: – первый и второй уровни технической поддержки организуется Заказчиком; – третий уровень технической поддержки организуется Подрядчиком. Перечень действий на каждом уровне технической поддержки указан в Таблице 5: Таблица 5 – Перечень действий на каждом уровне технической поддержки Уровень технической поддержки Доступные действия Условия передачи задачи на следующий уровень Первый уровень технической поддержки (далее – 1-й уровень) – принимает обращения (заявки) пользователей Модуля СЦ и работников Заказчика; – регистрирует обращения в Модуле СЦ регистрации обращений; – присваивает уникальный идентификационный номер, классифицирует обращения; – самостоятельно решает обращения, которые связаны с недостаточной квалификацией пользователей или настройками в рамках своей компетенции; – взаимодействует с пользователями Модуля СЦ при решении проблемы Передает обращение на второй уровень поддержки в случае невозможности решения на своем уровне Второй уровень технической поддержки (далее – 2-й уровень) – принимает обращения от 1-го уровня; – уточняет классификацию обращения в результате дополнительного анализа; – самостоятельно решает обращения в рамках своей компетенции; – осуществляет техническую и консультационную поддержку Модуля СЦ; – взаимодействует с сотрудниками 1-го и 3-го уровня и пользователями Модуля СЦ; – формирует заявки для 3-го уровня и контролирует исполнение Передает обращение на третий уровень поддержки в случае невозможности решения на своем уровне Третий уровень технической поддержки (далее – 3-й уровень) – принимает обращения от 2-го уровня; – обеспечивает выполнение требований, предъявляемых Контрактом и настоящим Техническим заданием к Услугам, оказываемым Подрядчиком Все поступающие обращения должны быть исполнены Подрядчиком - Для обеспечения взаимодействия с Заказчиком Подрядчик со своей стороны определяет ответственных лиц, уполномоченных в структуре Подрядчика за своевременное и качественное оказание Услуг в рамках настоящего ТЗ, а также контактную информацию ответственных лиц (телефон, электронную почту). Подрядчик должен предоставить Заказчику единый адрес электронной почты для приема обращений (заявок) в течение 3 (трех) рабочих дней после заключения Контракта. Указанный в настоящем пункте адрес электронной почты (способ направления обращений (заявок) применяется в случае сбоя в работе СРО Заказчика. Со своей стороны, Заказчик предоставляет Подрядчику перечень и контактную информацию (телефон, электронную почту) уполномоченных лиц для осуществления взаимодействия с указанием зон ответственности. О любых изменениях в контактной информации ответственных лиц Стороны должны уведомить друг друга в течение 1 (одного) рабочего дня с момента возникновения таких изменений посредством уведомления на электронную почту ответственных лиц и/или в письменной форме. В результате оказания услуг по настоящему ТЗ не должны быть изменены исходные коды, дистрибутивы и иные компоненты Модуля СЦ вне согласованных с Заказчиком изменений. Любые изменения исходных кодов, дистрибутивов и иных компонентов Модуля СЦ должны производиться только после согласования с Заказчиком уполномоченными лицами по электронной почте или иным заранее согласованным способом. Не должна быть ухудшена надежность и производительность Модуля СЦ. Оказание услуг по Контракту не должно нарушать требования к информационной безопасности, описанной в документации на Модуль СЦ - – выполнение требований по обеспечению в автоматизированном режиме с Национальной системой противодействия DDoS-атакам (НСПА) Центра мониторинга и управления сетью связи общего пользования ФГУП «ГРЧЦ» в рамках реализации мер по защите ГИС от атак, направленных на отказ в обслуживании; – детализированные требования к составу и содержанию работ по аттестации, а также к их результатам в соответствии с пунктами 13, 15 и 16 требований приказа ФСТЭК России от 29.04.2021 № 77 «Об утверждении Порядка организации и проведения работ по аттестации объектов информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну» - 4.5.5.1. Требования к безопасности исходного кода Процесс разработки исходного кода должен соответствовать требованиям законодательства, нормативным правовым актам Российской Федерации, приказу ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по безопасности значимых объектов критической информационной инфраструктуры Российской Федерации», а также учитывать отраслевые практики безопасной разработки. Подрядчик должен предоставить Заказчику Руководство по безопасной разработке программного обеспечения (далее – Руководство), применяемое при разработке исходного кода Модуля СЦ. Руководство должно содержать: · описание процесса безопасной разработки и ролевой модели, отражающей зоны ответственности сотрудников Подрядчика; · описание процессов моделирования, оценки и формирования мер предотвращения угроз, применяемых Подрядчиком; · описание методик, применяемых Подрядчиком при разработке исходного кода (правила написания кода); · описание методик, периодичности проведения и инструментария статического, динамического, композитного и фаззинг тестирования исходного кода, включающего критерии отбора релизных версий ПО, применяемые Подрядчиком в процессе разработки; · описание механизмов безопасности в процессе сборки и доставки (безопасность образов, безопасность секретов, безопасность окружения и сборочной среды), применяемые Подрядчиком; · утвержденные шаблоны отчетной документации (в том числе акты), в соответствии с которыми Заказчик принимает результаты проверок (артефакты сборочного процесса), проведенных Подрядчиком; · описание процедур отслеживания и исправления обнаруженных ошибок и уязвимостей программного обеспечения; · описание способов и сроков доведения Подрядчиком до Заказчика информации об уязвимостях программного обеспечения, о компенсирующих мерах по защите информации или ограничениях по применению программного обеспечения, способов получения пользователями программного обеспечения его обновлений, проверки их целостности и подлинности - Подрядчик должен обеспечить реализацию и проведение внутренних проверок мер по разработке безопасного ПО, приведенных в Руководстве. Подрядчик должен провести анализ угроз безопасности информации программного обеспечения в соответствии с ГОСТ 58412-2019 «Защита информации. Разработка безопасного программного обеспечения. Угрозы безопасности информации при разработке программного обеспечения». Подрядчик должен провести испытания по выявлению уязвимостей в программном обеспечении Системы: · проведение статического анализа исходного кода программы; · проведение динамического анализа исходного кода программы; · проведение композитного анализа исходного кода и образов программы; · проведение фаззинг-тестирования программы, направленного на выявление в ней уязвимостей. Испытания по выявлению уязвимостей в программном обеспечении Системы должны быть проведены в рамках: · предварительных испытаний; · опытной эксплуатации; · приемочных испытаний - Оказание услуг в рамках данного технического задания осуществляется Подрядчиком по обращению (заявке) Заказчика, направляемой посредством СРО Заказчика. Регистрация обращений, поступивших непосредственно в Модуль СЦ регистрации обращений Заказчика, производится сотрудниками Заказчика, которые обеспечивают первый уровень технической поддержки Модуля СЦ. В случае назначения приоритета «Критический» или «Высокий», информация о назначении также дублируется оповещением ответственных представителей Подрядчика посредством звонка на предоставленные номера телефонов. Обращение (заявка) должна содержать следующую информацию: – контакты пользователя/организации; – приоритет обращения, соответствующий Приложению 2 к Регламенту; – время обнаружения; – наименование компонента АСУ ТК - Модуль СЦ; Информация может быть расширена по согласованию с Заказчиком. Обращения (заявки) сотрудников Заказчика должны приниматься Подрядчиком через веб-интерфейс СРО. В процессе обработки обращений (заявок) Подрядчик должен обеспечить выполнение следующих процедур: – прием обращений(заявок) от сотрудников Заказчика; – оказание информационно-консультационной поддержки в соответствии с требованиями настоящего Технического задания; – информирование сотрудников Заказчика о статусе обработки и результатах обработки обращений(заявок). Подрядчик осуществляет обязательную регистрацию и учет всех обращений и заявок, поступивших к Подрядчику от представителей Заказчика в рамках оказания настоящих услуг - Примечание: в случае приостановки работы по обращению или заявке (обращение или заявка находится в статусе «Приостановлено»), указываются причины, по которым работы по обращению или заявке приостановлены с указанием перечня действий/информации, запрошенных у инициатора обращения, а также даты, формы и адресата такого запроса. В случае отклонения обращения или заявки (заполняется в случае, если обращению или заявке присваивается статус «Отклонено»), указываются подробно причины такого отклонения, а также фиксируется дата и время перехода в статус «Отклонено». В случае, если обращение или заявка отклонены (отменены) самим Инициатором, то указывается дата и способ, которым от инициатора получено соответствующее уведомление. В случае невыполнения Подрядчиком регламентного времени реагирования или решения обращения (заявки) Заказчик вправе отозвать обращение и направить его Подрядчику повторно. При этом каждое отозванное обращение учитывается в Отчёте об оказанных услугах, как обращение с превышением времени реагирования или решения, но оплате не подлежит. В случае, если обращение (заявка) связано с некачественным выполнением Подрядчиком другой задачи, такое обращение решается в регламентное время, установленное Техническим заданием, при этом оплате такие обращения не подлежат, о чем указывается в Отчете об оказанных услугах в графе «Примечание» - По результатам анализа угроз безопасности информации программного обеспечения и испытаний по выявлению уязвимостей в программном обеспечении Системы должна быть предоставлена отчетная документация по формам, утвержденным в Руководстве, и артефакты сборочной среды, подтверждающие проведение испытаний по выявлению уязвимостей в программном обеспечении Систем. Уязвимости подлежат устранению в сроки, обозначенные Заказчиком. В случае обнаружения уязвимого компонента Подрядчик должен заменить/обновить библиотеки. В случае, если уязвимость не подлежит исправлению на программном уровне, Подрядчик должен разработать меры предотвращения угроз безопасности, в том числе правила безопасности для наложенных средств защиты, рекомендации по безопасной настройке конфигурации для устранения потенциальных уязвимостей и снижения рисков информационной безопасности. Уязвимости, найденные ФСБ России, ФСТЭК России, Минцифры России, Роскомнадзором в ходе исполнения Контракта, а также в течение гарантийного периода, должны быть устранены Подрядчиком за свой счет в сроки, согласованные с Заказчиком - 4.5.6. Требования к эргономике и технической эстетике Взаимодействие пользователей с Модулем СЦ должно осуществляться посредством визуального графического интерфейса. Ввод-вывод данных, прием управляющих команд и отображение результатов их исполнения должны выполняться в интерактивном режиме. Интерфейс должен быть рассчитан на преимущественное использование манипулятора типа «мышь», то есть управление Модулем СЦ должно осуществляться с помощью набора экранных меню, кнопок, значков и т. п. элементов. Клавиатурный режим ввода должен использоваться главным образом при заполнении и/или редактировании текстовых и числовых полей экранных форм. Все надписи экранных форм, а также сообщения, выдаваемые пользователю (кроме системных сообщений), должны быть на русском языке. Модуль СЦ должен обеспечивать проверку вводимых пользователем данных и предупреждать о некорректно введённых значениях - Экранные формы должны проектироваться с учетом требований унификации: – все экранные формы пользовательского интерфейса должны быть выполнены в едином графическом дизайне, с одинаковым расположением основных элементов управления и навигации; – для обозначения сходных операций должны использоваться сходные графические элементы, кнопки и другие управляющие (навигационные) элементы. Термины, используемые для обозначения типовых операций, а также последовательности действий пользователя при их выполнении должны быть унифицированы; – внешнее поведение сходных элементов интерфейса (реакция на наведение указателя «мыши», переключение фокуса, нажатие кнопки) должно реализовываться одинаково. Структура размещения информации и представление этой структуры в Модуле СЦ должны соответствовать следующим требованиям: – пункты меню в пользовательском веб-интерфейсе должны быть сгруппированы в соответствии с тематикой информации, функциональными задачами и технологией работы; – каждому пункту меню должна соответствовать только одна выполняемая функция; – при совершении пользователями ошибочных действий должны выдаваться сообщения об ошибках. Эскизы визуального оформления компонента «Интерактивная карта» представлены в Приложении А. - 5. СОСТАВ И СОДЕРЖАНИЕ РАБОТ ПО РАЗВИТИЮ И ТЕХНИЧЕСКОЙ ПОДДЕРЖКЕ МОДУЛЯ СЦ (КАЛЕНДАРНЫЙ ПЛАН) - Сдача-приемка результатов выполненных работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная техническая документация, а также результаты работ предоставляются Заказчику в порядке, предусмотренном Контрактом и ТЗ, до размещения Подрядчиком в ЕИС документа о приемке. Документ о приемке размещается в ЕИС по каждому этапу в соответствии с условиями Контракта. Этапы выполнения работ по развитию Модуля СЦ приведены в Таблице 11. Таблица 11. Этапы выполнения работ по развитию Модуля СЦ. № этапа Наименование этапа Результат (отчетная документация) Срок исполнения этапа - - Значение характеристики не может изменяться участником закупки - 1 Техническое проектирование Сопроводительным письмом предоставляются Заказчику: · Технический проект, включая следующие документы: – Ведомость технического проекта; – Ведомость машинных носителей информации – Пояснительная записка; – Описание информационного обеспечения системы; – Описание автоматизируемых функций; – Схема функциональной структуры; – Описание организации информационной базы; – Описание программного обеспечения; · Макеты экранных форм компонента «Интерактивная карта»; · Руководство по безопасной разработке программного обеспечения; · Документ о приемке Начало: с даты заключения контракта Окончание: не позднее 31.07.2026 - 2 Услуги по технической поддержке Модуля СЦ (с даты заключения контракта по 10.09.2026) По окончании оказания Услуг сопроводительным письмом предоставляются Заказчику: – Отчет об оказанных Услугах по технической поддержке; – Актуальные на дату окончания оказания Услуг по данному этапу исходные коды прикладного ПО на электронном носителе (в случае внесения изменений); – Инструкция по сборке и развертыванию (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство пользователя (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство администратора (в случае внесения изменений); – Документ о приемке Начало: с даты заключения контракта Окончание: не позднее 10.09.2026 - 3 Разработка программного обеспечения (1 очередь, пп. 4.2.1, 4.2.6 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ; – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 1 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 1 очереди; – Руководство по резервному копированию; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 16.09.2026 - 4 Разработка программного обеспечения (2 очередь, пп. 4.2.3, 4.2.4 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ. – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 2 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 2 очереди; – Руководство по резервному копированию; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 25.09.2026 - 5 Разработка программного обеспечения (3 очередь, пп. 4.2.2, 4.2.5 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ; – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 3 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 3 очереди; – Руководство по резервному копированию; – Описание ролевой модели; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 09.10.2026 - 6 Опытная эксплуатация (1 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акт о завершении опытной эксплуатации 1 очереди; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке 17.09.2026 Окончание: не позднее 26.10.2026 - 7 Опытная эксплуатация (2 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акт о завершении опытной эксплуатации 2 очереди; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке 26.09.2026 Окончание: не позднее 26.10.2026 - 8 Опытная эксплуатация (3 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Акт о завершении опытной эксплуатации 3 очереди; – Документ о приемке Начало: с 10.10.2026 Окончание: не позднее 26.10.2026 - 9 Приемочные испытания Сопроводительным письмом предоставляются Заказчику: – Программа и методика приёмочных испытаний; – Протокол приемочных испытаний; – Исходные коды и дистрибутивы на электронном носителе (при условии внесения изменений, с учетом доработок по результатам опытной эксплуатации и проведенных испытаний); – Комплект рабочей документации на Модуль СЦ (при условии внесения изменений, с учетом доработок по результатам опытной эксплуатации и проведенных испытаний); – Акт приемки Системы в эксплуатацию; – Акт приемки-передачи исключительных прав на объект; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке; – Документы в соответствии с разделом 4.5.9 ТЗ; – Обеспечение гарантийных обязательств Начало: с 27.10.2026 Окончание: не позднее 10.11.2026 - 10 Услуги по технической поддержке Модуля СЦ (с 11.09.2026 по 15.12.2026) По окончании оказания Услуг сопроводительным письмом предоставляются Заказчику: – Отчет об оказанных Услугах по технической поддержке; – Актуальные на дату окончания оказания Услуг по данному этапу исходные коды прикладного ПО на электронном носителе (в случае внесения изменений); – Инструкция по сборке и развертыванию (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство пользователя (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство администратора (в случае внесения изменений); – Документ о приемке Начало: с 11.09.2026 Окончание: не позднее 15.12.2026 - Работы по развитию Системы (за исключением этапов проведения опытной эксплуатации и услуг по технической поддержке) могут быть выполнены досрочно. При досрочном выполнении работ (этапов работ) Подрядчик в письменной форме уведомляет Заказчика о готовности представить для приемки результаты проведения работ в соответствии с требованиями Контракта. Подрядчик также вправе досрочно приступать к работам в рамках очередного этапа при наличии технической, организационной готовности - при условии получения соответствующего согласования Заказчиком. Сдача-приемка результатов выполненных работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная, техническая документация, а также результаты Работ по каждому этапу предоставляется Заказчику в порядке, предусмотренном Контрактом и настоящим Техническим заданием, до размещения Подрядчиком в Единой информационной системе в сфере закупок документа о приемке. Документ о приемке размещается в ЕИС по каждому этапу в соответствии с условиями Контракта. Согласование документов осуществляется в электронном виде посредством переписки с адресов электронной почты Заказчика и Подрядчика, указанных в контракте. - 6. ПОРЯДОК РАЗРАБОТКИ МОДУЛЯ СЦ - Проектирование Модуля СЦ должно включать разработку следующих документов: – Ведомость технического проекта; – Ведомость машинных носителей информации – Пояснительная записка; – Описание информационного обеспечения системы; – Описание автоматизируемых функций; – Схема функциональной структуры; – Описание организации информационной базы; – Руководство по безопасной разработке программного обеспечения; – Описание программного обеспечения; – Макеты экранных форм компонента «Интерактивная карта». Структура документов должна соответствовать ГОСТ Р 59795-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов». Разработка Модуля СЦ должна включать в себя: – разработку программного обеспечения в части новых функций Модуля СЦ; – сборка исходного кода, развертывание и настройку доработанного программного обеспечения Модуля СЦ на вычислительных мощностях Заказчика (тестовый контур); – Комплект рабочей документации на Модуль СЦ; – разработку документа «Программа и методика предварительных испытаний»; – разработку документа «Программа и методика приемочных испытаний»; – разработку документа «Программа опытной эксплуатации». Структура документов должна соответствовать ГОСТ Р 59795-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов». В ходе выполнения работ формируется правоустанавливающая, отчетная, рабочая и техническая документация в соответствии с Контрактом и Календарным планом, приведенном в разделе 5. - - Значение характеристики не может изменяться участником закупки - 6.1. Сведения о гарантийном обслуживании Модуля СЦ Под гарантией понимается устранение Подрядчиком своими силами и за свой счет допущенных по его вине недостатков, выявленных после приемки выполненных Работ, как в работе самой Модуля СЦ, так и недостатков в отчетной документации. Если в период гарантийного срока обнаружатся недостатки, то Подрядчик обязан устранить их за свой счет, в сроки, установленные Заказчиком. Гарантийный срок в этом случае продлевается на период устранения недостатков. Срок гарантии: 1 год с даты приемки Заказчиком результатов исполнения Этапа № 9 контракта. Подрядчиком должны быть внесены соответствующие исправления в техническую и рабочую документацию (указанную в пунктах 5 и 6 настоящего ТЗ), связанные с устранением замечаний к работе Модуля СЦ или в случае выявления Заказчиком недостатков в такой документации в период гарантийного срока. Внесение изменений в документацию технического и рабочего проектирования осуществляется в соответствии с ГОСТ 2.503-2023 и ГОСТ Р 2.504-2021. - 7. ПОРЯДОК КОНТРОЛЯ И ПРИЕМКИ РЕЗУЛЬТАТОВ ВЫПОЛНЕНИЯ РАБОТ ПО РАЗВИТИЮ МОДУЛЯ СЦ - Испытания должны быть организованы и проведены в соответствии с ГОСТ Р 59792-2021 «Информационная технология. Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем». Должны быть проведены следующие виды испытаний: – предварительные испытания; – опытная эксплуатация; – приемочные испытания. Указанные виды испытаний проводятся в отношении не функциональных требований и функциональных возможностей, разрабатываемых в соответствии с настоящим ТЗ. Отдельные виды испытаний проводятся поэтапно в сроки, установленные Календарным планом. Предварительные испытания, опытная эксплуатация, приемочные испытания проводятся комиссией, создаваемой организационно-распорядительным документом Заказчика, который должен определять состав комиссии, порядок ее работы. Методы предварительных испытаний и порядок их проведения должны быть определены в документе «Программа и методика предварительных испытаний», который должен быть утвержден Заказчиком до начала предварительных испытаний. По результатам предварительных испытаний оформляется Протокол предварительных испытания и Акт о приемке в опытную эксплуатацию. Порядок проведения и методы испытаний во время опытной эксплуатации должны быть определены в документе «Программа опытной эксплуатации», который должен быть утвержден Заказчиком до начала опытной эксплуатации. Ход и результаты опытной эксплуатации отражаются в документе «Журнал опытной эксплуатации», и учитываются в ходе приемочных испытаний. По результатам опытной эксплуатации подписывается Акт о завершении опытной эксплуатации - - Значение характеристики не может изменяться участником закупки - До момента подключения внешних ИС, Подрядчиком могут быть использованы эмуляторы ИС для прохождения предварительных испытаний, опытной эксплуатации и приемочных испытаний. В рамках опытной эксплуатации должны быть проведены мероприятия по нагрузочному тестированию Модуля СЦ. Документ «Программа и методика приемочных испытаний» должен быть разработан с учетом недостатков, выявленных в ходе опытной эксплуатации, утвержден Заказчиком до начала приемочных испытаний, при этом проверки Модуля СЦ в части не устраненных недостатков, выявленных в процессе опытной эксплуатации, должны быть вынесены в отдельный раздел «Программы и методики приемочных испытаний». В процессе приемочных испытаний должно быть проверено устранение недостатков, полученных в ходе опытной эксплуатации. После завершения устранения всех замечаний, препятствующих приемке Системы в эксплуатацию, перечисленных в Протоколе приемочных испытаний, Подрядчик должен письменно уведомить Заказчика о том, что все замечания устранены, после чего приемочные испытания по решению Заказчика могут быть проведены повторно. Процедура приемочных испытаний проводится до подписания Протокола приемочных испытаний, не содержащего замечаний, препятствующих приемке Системы в эксплуатацию. Приемочные испытания Системы считаются завершенными успешно, если Протокол приемочных испытаний не содержит замечаний, препятствующих приемке Системы в эксплуатацию - 8. ТРЕБОВАНИЯ К СОСТАВУ И СОДЕРЖАНИЮ РАБОТ ПО ПОДГОТОВКЕ МОДУЛЯ СЦ К ВВОДУ В ЭКСПЛУАТАЦИЮ - По результатам проведения приемочных испытаний оформляется Протокол приемочных испытаний и Акт приемки в эксплуатацию. В случае, если взаимодействие с внешними системами не может быть проверено на средах постоянной эксплуатации взаимодействующих систем (по причине неготовности со стороны внешней системы или иным причинам), функции взаимодействия, разработанные в соответствии с требованиями ТЗ, должны быть проверены на тестовых данных с использованием программ-имитаторов взаимодействия. По результатам выполнения этапа приемочных испытаний должны быть подготовлены материалы для регистрации доработанной версии Модуля СЦ (объекта учета) в НФАП в соответствии с требованиями постановления Правительства Российской Федерации от 30 января 2013?г. №?62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин» (с изменениями и дополнениями) в части обязательности размещения результатов работ в национальном фонде алгоритмов и программ для электронных вычислительных машин. Сдача-приемка результатов выполнения Работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная, техническая документация, а также программное обеспечение предоставляется Заказчику в порядке, предусмотренном Контрактом и ТЗ до размещения Подрядчиком в Единой информационной системе в сфере закупок документа о приемке. Результаты проведения опытной эксплуатации, предварительных и приемочных испытаний должны быть зафиксированы в соответствующих протоколах и актах. Выявленные отклонения от настоящего ТЗ, оформляются как недостатки Модуля СЦ - - Значение характеристики не может изменяться участником закупки - Протоколы предварительных и приемочных испытаний должны содержать вывод о соответствии Модуля СЦ предъявляемым требованиям, а также сроки устранения замечаний и реализации рекомендаций, сформулированных комиссией в ходе предварительных и приемочных испытаний. Условием для передачи Модуля СЦ в промышленную эксплуатацию является устранение всех замечаний. Документация на Модуль СЦ и ее части (техническая и рабочая) должна содержать исчерпывающее описание принятых проектных решений в объеме, достаточном для ее дальнейшего развития и эксплуатации. Техническая и рабочая документация должна содержать описание разработанных результатов работ, в том числе программ для ЭВМ, прикладных программных интерфейсов, алгоритмов и протоколов информационного взаимодействия, технических требований, спецификаций и форматов обмена данными для взаимодействия с другими информационными системами, в объеме, достаточном для их установки, настройки, эксплуатации и развития в дальнейшем без привлечения Подрядчика. Исходные коды передаются в виде и составе, позволяющем провести: – сборку (компиляцию) Модуля СЦ в контролируемой Заказчиком среде; – установку полученной Модуля СЦ на специально подготовленную контролируемую Заказчиком инфраструктуру; – проверку функциональных возможностей Модуля СЦ; – оформление Модуля СЦ в качестве объекта национального фонда алгоритмов и программ для электронных вычислительных машин - 8.1. Требования, предъявляемые в соответствии с Приказом Минцифры России от 17.12.2020 № 715 «Об утверждении типовых условий контрактов на выполнение работ по созданию и (или) развитию (модернизации) государственных (муниципальных) и (или) иных информационных систем» Передача исходных кодов, разработанных в ходе выполнения работ, программ для электронных вычислительных машин (далее – программа для ЭВМ) должна сопровождаться передачей всех необходимых для сборки и запуска программы для ЭВМ библиотек зависимостей, программных сценариев (скриптов) для проведения установки (развертывания) программы для ЭВМ. Подрядчик в процессе сдачи-приемки работ по Контракту должен провести демонстрацию процесса и установки (развертывания) разработанных программ для ЭВМ. Документация на Модуль СЦ должна содержать описание принятых проектных решений в объеме, достаточном для ее дальнейшего развития и эксплуатации - 9. ТРЕБОВАНИЯ К ДОКУМЕНТИРОВАНИЮ - 9.1. Общие требования Документация на Модуль СЦ должна быть разработана в составе, указанном в разделах 5-8 данного ТЗ, и должна удовлетворять требованиям комплекса стандартов и руководящих документов на автоматизированные системы: – ГОСТ Р 2.105-2019 в части оформления текстовых документов; – ГОСТ 34.201-2020 в части наименования и обозначения документов. Документация на Модуль СЦ должны оформляться на листах формата А4. Допускается для размещения рисунков и таблиц использование листов формата А3 с подшивкой по короткой стороне листа. Документы объемом более 25 (двадцати пяти) листов должны содержать информационную часть, состоящую из аннотации и содержания. Исходные коды должны быть представлены в 1 (одном) экземпляре на электронном носителе, отчетные материалы должны быть представлены в 2 (двух) экземплярах на бумажном носителе (по одному экземпляру для Заказчика и Подрядчика) и в 1 (одном) экземпляре на электронном носителе в формате документов DOCX и PDF. При разработке документов на Модуль СЦ допускается отклонение от требований комплекса стандартов, описанных выше. Документам на Модуль СЦ должны в обязательном порядке присваиваться уникальные децимальные номера в соответствии с порядком, установленном в ГОСТ 34.201-2020. Документ «Программа и методика предварительных испытаний» должен включать приложения с формой протокола предварительных испытаний и формой акта приемки в опытную эксплуатацию. Документ «Программа опытной эксплуатации» должен включать приложение с формой журнала опытной эксплуатации. Документ «Программа и методика приемочных испытаний» должен включать приложения с формой протокола приемочных испытаний и формой акта приемки в эксплуатацию - - Значение характеристики не может изменяться участником закупки - 10. ИСТОЧНИКИ РАЗРАБОТКИ - 10.1. Список литературы Специальная литература для разработки ТЗ не использовалась. 10.2. Нормативно-методические документы Список используемых нормативно-методических документов представлен в разделе 1.6 технического задания. ? Приложение А Эскизы визуального оформления компонента «Интерактивная карта» - - Значение характеристики не может изменяться участником закупки - Приложение Б Параметры оказания услуг - Б.1. Базовые параметры оказания Услуг Базовые параметры оказания Услуг приведены ниже: – режимы оказания Услуг (таблица Б.1.1); – сроки предоставления отчетности (таблица Б.1.2). Таблица Б.1.1 - Режимы оказания Услуг № п/п Параметр Значение - - Значение характеристики не может изменяться участником закупки - 1 Режим работы Системы Круглосуточно (24х7) 2 Режим доступности информационно-консультационной поддержки пользователей Системы 2.1 Прием и регистрация обращений (заявок) в СРО Регистрация обращений (заявок) производится круглосуточно в режиме 24х7, без праздников и выходных дней. Обработка заявок первой линией поддержки осуществляется в рабочие дни с 9 до 18 часов 2.2 Консультирование сотрудников Заказчика и пользователей Системы в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 3 Режим доступности по решению инцидентов, связанных с работой ППО: 3.1 - приоритет «Критический» Круглосуточно (24х7) 3.2 - приоритет «Высокий» Круглосуточно (24х7) 3.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 3.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4 Режим доступности услуг по адаптации, конфигурации и коррекционному сопровождению Системы 4.1 - приоритет «Критический» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.2 - приоритет «Высокий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 5 Режим доступности по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности 5.1 - приоритет «Критический» Круглосуточно (24х7) 5.2 - приоритет «Высокий» Круглосуточно (24х7) 5.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 5.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) - Таблица Б.1.2. Сроки предоставления отчетности, с момента получения запроса № п/п Параметр Значение 1 Предоставление отчета об оказанных услугах за произвольный период 10 рабочих дней 2 Предоставление подробной информации по инциденту с приоритетом «Критический» 16 рабочих часов 3 Предоставление актуализированной документации 10 рабочих дней - Б.2. Приоритеты и регламентные сроки решения обращений (заявок) В зависимости от уровня сбоя в работе Системы обращению (заявке) присваивается один из следующих приоритетов, а также в зависимости от приоритета обращения (заявки) устанавливаются следующие контрольные сроки решения в соответствии с таблицей ниже (Таблица Б.2.1). Таблица Б.2.1 – Приоритеты и регламентные сроки решения обращений (заявок) № п/п Приоритет Максимальное время реагирования Время решения (срок выполнения) Описание приоритета По информационно-консультационной поддержке сотрудников Заказчика и пользователей Системы 1 - не более 1 часа не более 10 часов - По решению инцидентов, связанных с работой ППО: 1 Критический не более 30 минут не более 4 часов - полная недоступность ППО; - недоступность ключевых функций - ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО; - невозможность информационного обмена с ППО для ИС более 4 часов 2 Высокий не более 1 часа не более 8 часов - ошибки/сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; - снижение быстродействия СПО (время отклика ППО на операции превышает 30 секунд); - недоступность управления правами и ролями пользователей 3 Средний не более 4 часов не более 24 часов - невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым -недоступность функции формирования отчетов 4 Низкий не более 8 часов не более 40 часов - отклонение в работе ППО, не влияющее на корректную работу функций; - другие сбои и ошибки, затрагивающие основные функции ППО - По адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) 1 Критический не более 40 минут не более 8 часов - изменения, необходимые при проведении аварийно-восстановительных работ для возобновления работоспособности Системы; - изменения, связанные с критичными ошибками, блокирующими возможность оказания государственных услуг и/или чтение и внесение данных в Систему 2 Высокий не более 1 часа не более 40 часов - изменения, относящиеся к обеспечению работоспособности основной функциональности Системы, устраняют выявленные дефекты в работе Системы, оказывающие существенное влияние на работу пользователей в Системе; - изменения, затрагивающие три и более подсистемы/модуля Системы для адаптации 3 Средний не более 4 часов не более 72 часов - изменения, связанные с развитием/улучшением/оптимизацией Системы и выводом новой функциональности в штатном режиме для одного-двух модулей/подсистем; - изменения, связанные с развитием интеграционных механизмов Системы, например обновление существующих и/или реализация новых видов сведений СМЭВ, обновление существующих и/или реализация новых API, адаптация и/или изменение механизмов импорта и экспорта данных Системы и т.д. 4 Низкий не более 8 часов не более 160 часов - изменения, связанные с ошибками/корректировкой/изменением в отображении информации в пользовательском графическом интерфейсе Системы (графика, текст, органы управления, элементы интерфейса) - По устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности 1 Критический не более 30 минут не более 24 часов - критические уязвимости, влияющие на возможную полную недоступность ППО, ключевых функций Системы, ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО без возможности восстановления работоспособности Системы. - Критический уровень CVSS > 8.0 2 Высокий не более 1 часа не более 84 часов - критические уязвимости, влияющие на ошибки и сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО. - Высокий уровень CVSS 5.0 - 8.0 3 Средний не более 4 часов не более 120 часов - уязвимости, влияющие на невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым - Средний уровень CVSS 2.0 - 4.9 4 Низкий не более 8 часов не более 160 часов - уязвимости, влияющие на отклонение в работе ППО, не влияющее на корректную работу функций; - другие сбои и ошибки, затрагивающие основные функции ППО - Низкий уровень CVSS < 2.0 - Взаимодействие Заказчика и Подрядчика в части регистрации и контроля времени реагирования и решения обращения (заявки) осуществляется через СРО. Заказчик предоставляет Подрядчику доступ к СРО после заключения Контракта. Поступившие от разных пользователей заявки по поводу однотипных инцидентов или имеющие общую причину должны объединяться в одну заявку. Срок выполнения включает время диагностики инцидента, в ходе которого определяется причина инцидента (проблемы) и способ его устранения. Подрядчик должен обеспечить функционирование Модуля СЦ в соответствии с требованиями и параметрами, указанными в настоящем ТЗ и Регламенте оказании услуг. Основные параметры быстродействия типовых операций в Модуле СЦ указаны в таблице ниже (таблица Б.2.2). Таблица Б.2.2 - Параметры быстродействия Модуля СЦ № п/п Наименование параметра Значение (секунд) 1 Среднее время получения сообщения из очереди сообщений 10 2 Среднее время получения ответа от Системы 5 3 Среднее время открытия карточки реестра 5 - Приложение В Регламент оказания услуг - 2.2 Общее описание процесса оказания сопровождения (технической поддержки) Системы Процесс оказания технической поддержки Системы включает: 1. Поступление обращений (заявок) от пользователей и их регистрацию. 2. Сопровождение обращений (заявок) в соответствии с их классификацией и приоритизацией, в том числе, с их последующей эскалацией. 3. Определение ролей и регламент их взаимодействия при осуществлении деятельности по процессу. 4. Решение обращений (заявок) в установленные настоящим Регламентом сроки. 5. Взаимодействие между 1-м, 2-м и 3-м уровнями технической поддержки, в том числе, с формированием заданий для сопровождения Системы. 6. Контроль качества выполняемых Исполнителем работ, состоящий из проверки сценария, приводящего к ошибке, зафиксированной в Инциденте, и/или к ошибке воспроизведения, а также тестирование внесенных изменений в рамках ЗНИ. 7. Обеспечение мониторинга и проведение анализа процесса обработки поступающих в техническую поддержку обращений (заявок). Техническая поддержка реализуется путем проведения ответственными сотрудниками соответствующей информационно-консультационной деятельности в соответствии с определенными ролями, а также выполнения Исполнителем конкретных действий по своевременному выявлению причин сбоев и аварийных ситуаций и их устранению, а также по адаптации, конфигурированию, корректировке Системы, включая выполнение процедур тестирования и участия в обновлениях Системы. Все роли подразделяются на уровни поддержки, взаимодействующие между собой в соответствии с блок-схемой процесса технической поддержки. Общая схема процесса рассмотрения обращений (заявок) в соответствии с видами технической поддержки представлена на рисунке 1. . Рисунок 1 - Общая схема процесса рассмотрения обращений (заявок) в соответствии с видами технической поддержки - - Значение характеристики не может изменяться участником закупки - 2.3 Каналы связи Должна быть предусмотрена омниканальность в части приема обращений (заявок). Получение обращений (заявок) технической поддержкой происходит по следующим каналам связи: – СРО; – электронная почта; – телефонная линия. Исполнитель обеспечивает прием обращений (заявок) от Заказчика и предоставляет информацию в рамках оказания услуг по техническому сопровождению Системы, руководствуясь матрицей взаимодействия, приведенной в Приложении 1 к настоящему Регламенту - 3 Порядок оказания Услуг 3.1 Типы обращений (заявок) Обращения и заявки Заказчика классифицируются в соответствии с приоритетами и регламентными сроками, указанными в Приложении 2 к настоящему Регламенту. Регистрация обращений и заявок предусматривает создание новой записи в СРО с присвоением поступившему обращению или заявке (новой записи) уникального идентификатора. Запись в СРО должна содержать вопрос или проблему, которую требуется решить или оказать консультацию. Если обращение или заявка автоматически зарегистрированы в СРО при отправке представителем Заказчика, Исполнитель проверяет корректность указанного типа обращения (заявки) и может обратиться к Заказчику с просьбой корректировки, предоставив обоснования в соответствии с настоящей классификацией (Таблица 1) - Таблица 1 - Типы обращений (заявок) Тип обращения (заявки) Описание Запрос на обслуживание Подготовка SQL запроса к СУБД для решения прикладной задачи и д р. – запрос на любое действие, не являющееся запросом информации и несовершенный на основе происшествия, прямо или косвенно влияющего на работу Системы Консультация (входит в тип обращения (заявки) «Запрос на обслуживание») «Где взять / куда обратиться...?», «Как сделать / выполнить…», «Как это работает…?» - запрос, имеющий своей целью получение информационной поддержки Инцидент Разбор ошибок/сбоев и подготовка материалов (корректировочных релизов, инструкций) для Заказчика для устранения ошибок/сбоев, которые приводят к частичному и полному нарушению работоспособности всех или отдельных функций ППО. Подготовка изменения и материалов, необходимых для проведения аварийно-восстановительных работ для возобновления работоспособности Системы. ЗНИ Подготовка изменений, связанных с изменением, улучшением/оптимизацией Системы и выводом новой модифицированной функциональности в штатном режиме. Подготовка изменений, связанных с модификацией существующих и/или реализация новых интеграционных механизмов для получения/обработки данных внешних систем. Подготовка изменений графического интерфейса по требованиям Заказчика - 3.2 Участники технической поддержки, осуществляющие сопровождение обращений (заявок) Техническая поддержка Системы должна быть организована на трех уровнях: 1. Первый и второй уровни технической поддержки организуется Заказчиком. 2. Третий уровень технической поддержки организуется Исполнителем. Зона ответственности каждого уровня технической поддержки указана в Таблице 2. Таблица 2 - Зона ответственности каждого уровня технической поддержки Участники технической поддержки Описание - Первый уровень технической поддержки (далее – 1-й уровень) Группа ответственных сотрудников 1-го уровня Заказчика, осуществляющая прием и первичную обработку обращений (заявок) (описание предмета обращения, первичная классификация и приоритизация, определение назначения, маршрутизация обращений (заявок) по назначению), руководствуется в своей работе настоящим Регламентом и БЗ, наполняемой 2-м уровнем поддержки, самостоятельно решает часть обращений (заявок), связанных с недостаточной квалификацией пользователей или настройками в рамках своей компетенции. В случае невозможности решения обращений (заявок) на 1-ом уровне ответственный сотрудник передает ее на 2-й уровень - Второй уровень технической поддержки (далее – 2-й уровень) Группа ответственных сотрудников 2-го уровня Заказчика по установленным компетенциям (информационная безопасность, сопровождение и эксплуатация информационно-аналитических систем, развитие информационно-аналитических систем, техническая поддержка информационно-аналитических систем) отвечает за поддержание работоспособности Системы, обработку обращений (заявок) и их решение в регламентные сроки в соответствии с установленными приоритетами. Осуществляет информационно-консультационную поддержку пользователей Системы в рамках своей компетенции. Оказывает экспертную помощь ответственным сотрудникам 1-го уровня в части формирования БЗ, содержащей ответы на часто задаваемые вопросы пользователей, с целью передачи знаний, навыков и инструментария на 1-й уровень для ускорения решения обращений (заявок). В случае невозможности решения обращения (заявки) на 2-ом уровне ответственный сотрудник передает его на 3-й уровень. При выявлении необходимости изменений в ППО Системы инициирует формирование обращения (заявки) и направляет его на группу ответственных сотрудников 3-го уровня по соответствующему классификатору (ЗНО, ЗНИ, и т.д.) - Третий уровень технической поддержки (далее – 3-й уровень) Группа ответственных сотрудников Исполнителя, отвечающая за устранение сбоев и аварий, проведение информационно-консультационной поддержки пользователей Системы, проведение адаптации и конфигурирования Системы в объемах действующих контрактов на оказание технической поддержки - 3.3 Перечень и описание статусов обращений (заявок) В Таблице 3 приведен перечень статусов обращений (заявок), действующий в СРО, и их описание. Таблица 3 - Перечень статусов обращений (заявок) и их описание Статус Описание Зарегистрирован Обращение (заявка) принято и зарегистрировано Направлен в группу Присваивается при назначении ответственными сотрудниками 1-го уровня группе ответственных сотрудников 2-го уровня по тематике обращения (заявки) после заполнения всей необходимой информации и полей обращения (заявки), а также при его передаче между группами 2-го уровня Передан в группу Присваивается при передаче обращения (заявки) ответственными сотрудниками 2-го уровня на группу ответственных сотрудников 3-го уровня Назначен Присваивается при назначении обращения (заявки) на ответственного сотрудника для его решения в рамках компетенции В работе Присваивается при приеме обращения (заявки) в работу ответственным сотрудником для его решения Решен Присваивается ответственным сотрудником, выполнившим работы по обращению (заявке) Закрыт Присваивается автоматически при решении запроса по обращению (заявке), а также отсутствии дополнительных запросов пользователя в соответствии с действующим SLA, или при подтверждении решения обращения (заявки) со стороны пользователя Запрос доп. информации Присваивается при необходимости запроса дополнительной информации и/или уточнения предмета обращения по обращению (заявке) у пользователя Ответ предоставлен Присваивается после ответа пользователем на запрос дополнительной информации Отклонен Присваивается, если обращение (заявка) не актуальна (по информации от пользователя), отсутствует техническая возможность решения обращения (заявки), предмет обращения не входит в компетенции технической поддержки, или существует влияние доработки на другие компоненты, что нарушает общий порядок работы Системы - Согласование Присваивается при необходимости согласования направления обращения (заявки) ответственным сотрудником Заказчика на 3-й уровень Анализ Присваивается при проведении анализа на предмет возможности внесения изменений, связанных с развитием/улучшением/оптимизацией Системы и выводом новой функциональности и оценке ресурсоемкости Тестирование Присваивается Исполнителем при завершении разработки и проведенном предварительном тестировании для последующего осуществления приемочного тестирования Специалистом 2-го уровня Релиз Присваивается ответственным сотрудником Заказчика при принятии решения о возможности вывода доработки в продуктивную среду Утверждение заказчиком Присваивается при согласовании группой профильных специалистов на 2-м уровне поддержки с пользователем технического задания для внесения изменений, связанных с развитием/улучшением/оптимизацией Системы и выводом новой функциональности Доработка Присваивается в случае несогласования Заказчиком работ, проведенных Исполнителем в рамках контрактных обязательств, по внесению изменений, связанных с развитием/улучшением/оптимизацией Системы и выводом новой функциональности в штатном режиме, и необходимости последующего направления Исполнителю для ее доработки Отложен Присваивается в случае невозможности выполнения запроса, изложенного в обращении (заявке), в связи с необходимостью запроса дополнительной информации у третьих сторон - 3.4 Порядок регистрации и сопровождения Заявок Порядок регистрации и сопровождения обращений (заявок) в рамках оказываемых услуг по технической поддержке Системы зависит от типа обращения (заявки): 1. Услуга по решению инцидентов, связанных с работой ППО – тип обращения (заявки) «Инцидент». 2. Услуга по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности – тип обращения (заявки) «Инцидент». 3. Услуга информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы – тип обращения (заявки) «Запрос на обслуживание» (в том числе, консультационный запрос). 4. Услуга адаптационного, конфигурационного и коррекционного сопровождения Системы (в рамках действующих программных модулей и функциональностей) – тип обращения (заявки) «Запрос на изменение». В случае недоступности СРО взаимодействие и информирование Исполнителем о ходе оказания услуги по обращению (заявке), изменению статусов обращений (заявок) осуществляется по согласованию с Заказчиком в соответствии с матрицей взаимодействия, представленной в Приложении 1 к настоящему Регламенту. - 3.4.1 Инцидент На рисунке 2 представлена функциональная схема регистрации и сопровождения обращений (заявок) типа «Инцидент». Рисунок 2 - Функциональная схема регистрации и сопровождения обращений (заявок) типа «Инцидент» 3.4.2 Запрос на обслуживание На рисунке 3 представлена функциональная схема регистрации и сопровождения обращения (заявки) типа «ЗНО». Рисунок 3 - Функциональная схема регистрации и сопровождения обращения (заявки) типа «ЗНО» 3.4.3 Запрос на изменение На рисунке 4 представлена функциональная схема регистрации и сопровождения обращений (заявок) типа «ЗНИ». Рисунок 4 - Функциональная схема регистрации и сопровождения обращений (заявок) типа «ЗНИ» - 3.5 Порядок классификации и приоритизации обращений (заявок) Классификация является начальной стадией процесса оказания технической поддержки, необходимой для идентификации обращения (заявки) и определения соответствующих действий для его обработки. Для проведения первичной классификации необходимо получить от пользователя и зафиксировать в описании обращения (заявки) подробные сведения о сути запроса, в том числе, для Инцидентов зафиксировать сценарий воспроизведения обнаруженной ошибки. Для проведения вторичной классификации необходимо провести анализ и диагностику для определения корневой причины и затронутой Инцидентом функциональной области (инфраструктура, сеть, ППО). В процессе классификации осуществляется первичная диагностика и оценка проблемы, описанной пользователем Системы в обращении (заявке), в части функционирования и/или удобства использования Системы. Корректная классификация позволяет увеличить скорость обработки обращения (заявки) и решения описанной в обращении (заявке) проблемы при минимальном привлечении ресурсов, в частности, за счет использования известных решений для типовых обращений (заявок), которые должны описываться в БЗ СРО. Классификация позволяет произвести первоначальное назначение обращения (заявки) на ответственного сотрудника и выставить приоритет с учетом приоритизации. Приоритизация применяется для определения критичности описанной в обращении (заявке) проблемы для функционирования ППО Системы. Приоритет рассмотрения обращения (заявки) определяется в процессе ее классификации на основании ряда параметров, вводимых при заполнении обращения (заявки). Приоритизация используется для того, чтобы при одновременном наличии нескольких обращений (заявок) в первую очередь рассматривалась обращения (заявки) с наивысшим приоритетом и не позднее установленных для данного приоритета сроков - Изменение приоритета уже зарегистрированного обращения (заявки) используется в случае появления новых обстоятельств, которые ведут к изменению влияния и/или срочности существующего обращения (заявки). При регистрации обращения (заявки) необходимо провести его приоритизацию. В процессе управления обращениями (заявками) каждому обращению (заявке) присваивается приоритет, принимающий одно из значений: Низкий, Средний, Высокий или Критический. В соответствии с приоритетом определяется время, очередность устранения, , ресурсы, привлекаемые для работ по обращению (заявке), а также может определяться порядок/процедура действий при работе с обращением (заявкой). Заказчиком в зависимости от уровня сбоя в работе Системы обращению (заявке) присваивается приоритет с указанием максимального времени реакции и решения в соответствии с требованиями, указанными в Приложении 2 к настоящему Регламенту - 4 Формы обращений (заявок) на оказание услуг по технической поддержке Системы, заполняемые в СРО 4.1. Форма обращения (заявки) на оказание услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы При подаче обращения (заявки) типа «ЗНО» в СРО указывается (Таблица 5): Таблица 5 – Описание атрибутов формы обращения (заявки) на оказание услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 5) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 5) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 5) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 5) Категория обращения: информационно-консультационная поддержка Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 5) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 5) Текст запроса на оказание услуги по информационно-консультационной поддержке сотрудников Заказчика Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 5) - На рисунке 5 приведена форма обращения (заявки) типа «ЗНО» в СРО. Рисунок 5 - Форма обращения (заявки) типа «ЗНО» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы, заполненную в свободной форме. - 4.2. Форма обращения (заявки) на оказание услуги по решению инцидентов, связанных с работой ППО При подаче обращения (заявки) типа «Инцидент» в СРО указывается (Таблица 6): Таблица 6 – Описание атрибутов формы обращения (заявки) на оказание услуги по решению инцидентов, связанных с работой ППО Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 6) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 6) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 6,) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 6) Категория обращения (заявки): инцидент Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 6) Приоритет изменения Время - одно из значений: Низкий, Средний, Высокий или Критический. Определяет, очередность решения обращения (заявки), ресурсы, привлекаемые для решения обращения (заявки), порядок/процедура действий при решении обращения (заявки) – поле СРО «Приоритет» (см. рисунок 6,) - Тип изменения Справочник, классифицирующий типовые запросы характерные для Системы – поле СРО «Предмет обращения» (см. рисунок 6) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 6) Полное описание инцидента, включая скриншоты и описание шагов, приведших к неисправности Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 6) Однократность/неоднократность Круг пользователей или компьютеров, затронутых данным инцидентом Действия, предпринятые для самостоятельного решения инцидента (при наличии) Версии используемого программного обеспечения на клиентской рабочей станции, где воспроизводится ошибка (операционная система, прикладное программное обеспечение) Дополнительная информация - На рисунке 6 приведена форма обращения (заявки) типа «Инцидент» в СРО. Рисунок 6 - Форма обращения (заявки) типа «Инцидент» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуги по решению инцидентов, связанных с работой ППО, заполненную в свободной форме - 4.3. Форма обращения (заявки) на оказание услуг по адаптационному конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) При подаче обращения (заявки) типа «ЗНИ» в СРО указывается (Таблица 7): Таблица 7 – Описание атрибутов формы обращения (заявки) на оказание услуг по адаптационному, конфигурационному и коррекционному сопровождению Системы Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 10) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 9) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 10) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 10) Категория обращения (заявки): запрос на изменение Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 7) Приоритет изменения Время, очередность решения обращения (заявки), ресурсы, привлекаемые для решения обращения (заявки), порядок/процедура действий при решении обращения (заявки) – поле СРО «Приоритет» (см. рисунок 7) Тип изменения Справочник, классифицирующий типовые запросы характерные для Системы – поле СРО «Предмет обращения» (см. рисунок 7) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 7) Текст запроса на оказание услуги по адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 7) - На рисунке 7 приведена форма обращения (заявки) типа «ЗНИ» в СРО. Рисунок 7 - Форма обращения (заявки) типа «ЗНИ» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуг по адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей), заполненную в свободной форме - 4.4. Форма обращения (заявки) на оказание услуги по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности При подаче обращения (заявки) типа «Инцидент» в СРО указывается (Таблица 8): Таблица 8 – Описание атрибутов формы обращения (заявки) на оказание услуг по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности - Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 8) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 8) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 8) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 8) Категория обращения (заявки): инцидент Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 8) Приоритет Время, очередность решения обращения (заявки), ресурсы, привлекаемые для решения обращения (заявки), порядок/процедура действий при решении обращения (заявки) – поле СРО «Приоритет» (см. рисунок 8) Тип изменения Справочник, классифицирующий типовые запросы характерные для Системы – поле СРО «Предмет обращения» (см. рисунок 8) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 8) Текст запроса на оказание услуги по обновлению или удалению уязвимых компонентов (библиотек) ППО в соответствии с требованиями к обеспечению информационной безопасности Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 8) - На рисунке 8 приведена форма обращения (заявки) типа «Инцидент» в СРО. Рисунок 8 - Форма обращения (заявки) типа «Инцидент» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуги по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности, заполненную в свободной форме - Приложение 1 к Регламенту Матрица ответственных за взаимодействия в рамках выполнения работ по техническому сопровождению Системы Таблица 1 – Ответственные за взаимодействия в рамках выполнения работ по техническому сопровождению Системы со стороны Исполнителя ФИО Должность Адрес электронной почты Телефон — — — Общий контакт - Приложение 2 к Регламенту Приоритеты и регламентные сроки решения обращений (заявок) Приоритеты и регламентные сроки решения обращений (заявок) приведены в таблице 1. Таблица 1 – Приоритеты и регламентные сроки решения обращений (заявок) № п/п Приоритет Максимальное время реагирования Время решения (срок выполнения) Описание приоритета - По информационно-консультационной поддержке сотрудников Заказчика и пользователей Системы 1 – не более 1 часа не более 10 часов – - По решению инцидентов, связанных с работой ППО 1 Критический не более 30 минут не более 4 часов – полная недоступность ППО; – недоступность ключевых функций; – ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО; – невозможность информационного обмена с ППО для ИС более 4 часов 2 Высокий не более 1 часа не более 8 часов – ошибки/сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; – снижение быстродействия СПО (время отклика ППО на операции превышает 30 секунд); – невозможность управления правами и ролями пользователей 3 Средний не более 4 часов не более 24 часов – невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым недоступность функции формирования отчетов 4 Низкий не более 8 часов не более 40 часов – отклонение в работе ППО, не влияющее на корректную работу функций; – другие сбои и ошибки, затрагивающие основные функции ППО - По адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) 1 Критический не более 40 минут не более 8 часов – изменения необходимые при проведении аварийно-восстановительных работ для возобновления работоспособности Системы; – изменения, связанные с критичными ошибками, блокирующими возможность оказания государственных услуг и/или чтение и внесение данных в Систему 2 Высокий не более 1 часа не более 40 часов – изменения относящиеся к обеспечению работоспособности основной функциональности Системы, устраняют выявленные дефекты в работе Системы, оказывающие существенное влияние на процесс оказания государственных услуг и работу пользователей в Системе; – изменения, затрагивающие три и более подсистемы/модуля Системы для адаптации 3 Средний не более 4 часов не более 72 часов – изменения, связанные с развитием/улучшением/оптимизацией Системы и выводом новой функциональности в штатном режиме для одного-двух модулей/подсистем; – изменения, связанные с развитием интеграционных механизмов Системы, например, обновление существующих и/или реализация новых видов сведений СМЭВ, обновление существующих и/или реализация новых API, адаптация и/или изменение механизмов импорта и экспорта данных Системы и т.д. 4 Низкий не более 8 часов не более 160 часов – изменения, связанные с ошибками/ корректировкой/изменение в отображении информации в пользовательском графическом интерфейсе Системы (графика, текст, органы управления, элементы интерфейса) - По устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности 1 Критический не более 30 минут не более 24 часов – критические уязвимости, влияющие на возможную полную недоступность ППО, ключевых функций Системы, ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО без возможности восстановления работоспособности Системы; – Критический уровень CVSS > 8.0 2 Высокий не более 1 часа не более 84 часов – критические уязвимости, влияющие на ошибки и сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; – Высокий уровень CVSS 5.0 - 8.0 3 Средний не более 4 часов не более 120 часов – уязвимости, влияющие на невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым; – Средний уровень CVSS 2.0 - 4.9 4 Низкий не более 8 часов не более 160 часов – уязвимости, влияющие на отклонение в работе ППО, не влияющее на корректную работу функций; – другие сбои и ошибки, затрагивающие основные функции ППО; – Низкий уровень CVSS < 2.0 - Приложение Г Форма Отчета об оказанных услугах Отчет об оказанных услугах за этап «наименование этапа» в период с «__» _________ по «__» _________. № п/п Наименование услуги Общее количество Номер ОРС Краткое Описание Время реагирования по ТЗ Время реагирования фактическое Время решения по ТЗ Время решения фактическое Результат соблюдения времени реагирования Результат соблюдения времени решения Примечание 1 Услуги по информационно-консультационной поддержке работников Заказчика 2 546782 Консультация по работе Модуля СЦ 1 2 10 часов 11 часов Нет Нет 567123 Консультация по схеме БД 1 1 10 часов 1 час Да Да 2 … … Заказчик Подрядчик /Должность/ /Должность/ ____________________ /Ф.И.О/ ___________________ /Ф.И.О/ М.П. М.П. «_____»_______________________202_г. «_____»_______________________202_г - Приложение 1 к Отчету об оказанных услугах Журнал обращений (заявок) на оказание услуги по информационно-консультационной поддержке пользователей Системы (шаблон) Наименование Исполнителя в этапе «наименование этапа» в период с ________________ по _______________ оказал(о) Услугу по поддержке пользователей Системы в объеме, указанном в Таблице 1 Таблица 1 - Журнал обращений (заявок) пользователей Системы № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. ИТОГО зарегистрировано: Всего обращений (заявок): ________ ИТОГО решено: Всего обращений (заявок): ________ - Приложение 2 к Отчету об оказанных услугах Журнал обращений (заявок) по решению инцидентов, связанных с работой ППО (шаблон) Наименование Исполнителя в этапе «наименование этапа» в период с ________________ по _______________ оказал(о) Услугу по решению инцидентов в объеме, указанном в Таблице 1. Таблица 1 - Журнал по решению инцидентов № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. ИТОГО зарегистрировано: Всего инцидентов: ________ ИТОГО решено: Всего инцидентов: ________ - Приложение 3 к Отчету об оказанных услугах Журнал обращений (заявок) выполнения адаптационного, конфигурационного и коррекционного сопровождения Системы (шаблон) Журнал выполнения адаптации, конфигурации и коррекции Системы сформирован за этап «наименование этапа» в период с «__» _________ по «__» ____________ и представлен в таблице ниже (Таблица 1). Таблица 1 - Журнал выполнения адаптации, конфигурации и коррекции сопровождения Системы № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. Количество выполненных заявок за этап: ________ - Приложение 4 к Отчету об оказанных услугах Журнал обращений (заявок) по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности (шаблон) Журнал обращений (заявок) по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности сформирован за этап «наименование этапа» в период с «__» _________ по «__» ____________ и представлен в таблице ниже (Таблица 1). Таблица 1 - Журнал выполнения заявок по устранению уязвимостей в ППО № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. Количество выполненных заявок за этап: ________ - Приложение Д Форма Протокола проверки результатов организационно-штатных и подготовительных мероприятий (шаблон) Протокол проверки результатов организационно-штатных и подготовительных мероприятий Настоящий Протокол содержит результаты проверки организационно-штатных и подготовительных мероприятий, проведенных Исполнителем (Таблица Д.1). Таблица Д.1. Протокол проверки результатов № Мероприятия Подготовительного этапа Результат проверки 1. Определить и направить Заказчику документ «Ответственные за взаимодействия в рамках выполнения работ по техническому сопровождению Системы со стороны Исполнителя». Документ содержит контактную информацию (ФИО, должность, адрес электронной рабочей почты, номер телефона) не менее чем о 2 лицах, ответственных за оказание услуг со стороны Подрядчика Выполнено/Не выполнено 2. Обеспечить подключение специалистов Подрядчика к Системе Выполнено/Не выполнено 3. Обеспечить подключение специалистов Подрядчика к СРО Выполнено/Не выполнено Заказчик Подрядчик /Должность/ /Должность/ ____________________ /Ф.И.О/ ___________________ /Ф.И.О/ М.П. М.П. «_____»_______________________202_г. «_____»_______________________202_г - Термины и сокращения В настоящем регламенте используются следующие термины и сокращения на русском и английском языках: Термины/сокращения Полное наименование/описание БЗ (База знаний) База данных Системы регистрации обращений (заявок), созданная для сбора, хранения и поиска способов решения известных проблем в рамках Системы Жизненный цикл обращения (заявки) Совокупность статусов, по которым проходит обращение (заявка), и правила перехода обращения (заявки) из одного статуса в другой Заказчик ФГБУ «СИЦ Минтранса России» – Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» ЗНИ Запрос на изменение – тип заявки, предполагающий внесение изменений в прикладное программное обеспечение Системы ЗНО Запрос на обслуживание – тип заявки, предполагающий работы по предоставлению консультации, предоставление доступа к Системе или стандартизированные типовые изменения конфигураций Системы Инцидент Тип заявки, классифицируемый как нештатное событие в работе компонентов функциональных задач Системы, которое привело или может привести к нарушению или снижению качества функционирования Системы ИС Информационная система Исполнитель Организация, которая определяется по результатам конкурсных процедур Классификация Анализ и заполнение классификационных полей справочными значениями, определяющими последовательность действий и этапов жизненного цикла заявки, а также порядок рассмотрения заявок Консультация Разъяснения по алгоритму работы, требуемых настроек прикладного программного обеспечения и технологии обработки данных при работе с Системой, предоставление информации Маршрутизация Определение процесса движения обращения (заявки) в Системе управления заявками между уровнями технической поддержки и организационными структурами на уровнях поддержки путем назначения обращения (заявки) в соответствии с его классификацией и выставленным приоритетом - Обращение (заявка) Устное или письменное обращение пользователя АСУ ТК с вопросом, касающимся работоспособности АСУ ТК, по одному из определённых каналов связи: электронная почта, Система регистрации обращений (заявок) Пользователь Инициатор обращения (заявки) или пользователь Системы ППО Прикладное программное обеспечение Предмет обращения Справочник, классифицирующий типовые запросы в Системе регистрации обращений (заявок), характерные для Системы, выбранное значение определяет маршрутизацию обращения (заявки) (группу ответственных сотрудников) Приоритизация Значение, определяющее время, очередность решения обращений (заявок), ресурсы, привлекаемые для решения обращений (заявок), . Приоритет устанавливается в соответствии с масштабом выявленной проблемы, которая привела или может привести к нарушению или снижению качества функционирования Системы Релиз Выпуск версии прикладного программного обеспечения Системы, от разработки до тестирования и планового обновления Системы на продуктивной среде для установки изменений, связанных с развитием/улучшением/оптимизацией Системы Система, АСУ ТК, Информационно-аналитическая система регулирования на транспорте Информационно-аналитическая система, предназначенная для автоматизации и информационно-аналитического обеспечения процессов управления развитием транспортного комплекса Российской Федерации, обеспечения публичности деятельности органов государственного управления транспортным комплексом, а также обеспечения процессов оказания государственных услуг в электронном виде в сфере транспорта СМЭВ Система межведомственного электронного взаимодействия СПО Системное программное обеспечение СРО Система регистрации обращений (заявок) Статус обращения (заявки) Текущее состояние обращения (заявки) в жизненном цикле процесса оказания технической поддержки Системы СУБД Система управления базами данных - Уровень технической поддержки Организационно-структурная часть технической поддержки, имеющая определённые организационно-нормативными документами зоны ответственности, обязанности, а также временные нормативы, в течение которых эти обязательства должны выполняться либо эскалироваться на следующий уровень технической поддержки Услуги Услуги по технической поддержке Информационно-аналитической системы регулирования на транспорте АСУ ТК ФИО Фамилия, имя, отчество Эскалация Процедура повышения внимания к обращению (заявке) путем повышения его приоритета и/или передачи на следующий уровень технической поддержки, а также привлечение ролей, которые могут принимать решения без передачи на следующий уровень технической поддержки API Англ. Application Programming Interface — программный интерфейс приложения, интерфейс прикладного программирования — описание способов (набор классов, процедур, функций, структур или констант), которыми одна компьютерная программа может взаимодействовать с другой программой - CVSS Англ. Common Vulnerability Scoring System - открытый стандарт, используемый для расчета количественных оценок уязвимости в безопасности компьютерной системы, обычно с целью понять приоритет ее исправления. В современном инструментарии информационной безопасности используется версия 3.0 и выше с дополнительными метриками к базовым оценкам ID Англ. Identifier – идентификатор, уникальный признак объекта, позволяющий отличать его от других объектов, то есть, идентифицировать SLA Англ. Service Level Agreement - утвержденные условия по обработке обращения (заявки) с установленными метриками времени, которые определяют пороговые значения для эскалации в зависимости от статуса обращения (заявки) (например, время реакции – время от регистрации до осуществления первичной обработки, время решения – время от регистрации обращения (заявки) до его решения и т.д.) SQL Англ. Structured Query Language — «язык структурированных запросов», — декларативный язык программирования, применяемый для создания, модификации и управления данными в реляционной базе данных, управляемой соответствующей СУБД - 1 Общие сведения 1.1 Полное наименование Услуг Оказание услуг по технической поддержке Модуля СЦ АСУ ТК в 2026 году. 1.2 Предмет Регламента оказания услуг Требования Технического задания - 2 Общие положения 2.1 Цель и задачи оказания услуг Целью технической поддержки Системы является обеспечение ее стабильного и безопасного функционирования и эксплуатации, предупреждение, выявление и устранение сбоев в работе Системы и минимизация их неблагоприятного влияния. Для достижения поставленной цели требуется решение следующих задач: 1. Обеспечение информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы. 2. Поддержание параметров функционирования ППО Системы, удовлетворяющих требованиям производственных процессов, включая их непрерывность. 3. Обеспечение бесперебойного функционирования ППО и своевременное устранение сбоев и аварийных ситуаций в Системе. 4. Своевременное устранение уязвимостей при выявлении таковых, в соответствии с требованиями к обеспечению информационной безопасности. 5. Адаптация, конфигурирование, коррекция программного обеспечения в соответствии с изменениями нормативно-правовой базы и запросами уполномоченных сотрудников органов государственной власти, включая выполнение процедур тестирования и участие в обновлениях ППО на стендах Заказчика. 6. Обеспечение сохранения работоспособности ППО в изменяемой среде эксплуатации. 7. Ведение документации по настоящему контракту и инициирование актуализации документации на Систему по результатам обработки запросов Заказчика и внесения соответствующих изменений в ППО

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

ОПРЕДЕЛЕНИЯ, ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ - Автоматизированная система (АС) Система, состоящая из комплекса средств автоматизации, реализующего информационную технологию выполнения установленных функций, и персонала, обеспечивающего его функционирование (ГОСТ Р 59853-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения») АРМ Автоматизированное рабочее место АСУ ТК, Система Информационно-аналитическая система регулирования на транспорте АТС Автоматическая телефонная станция БД База данных ГИС Государственная информационная система ГОСТ Государственный стандарт ГЦОД СИЦ Минтранса России, ГЦОД Головной центр обработки данных ФГБУ «СИЦ Минтранса России» Дашборд Интерактивная аналитическая панель, графический интерфейс. ЕИС Единая информационная система в сфере закупок ЕСИА Единая система идентификации и аутентификации Заказчик Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации» КИИ Критическая информационная инфраструктура Кластер Кла?стер (англ. cluster) – объединение нескольких однородных элементов, которое может рассматриваться как самостоятельная единица, обладающая определёнными свойствами Компонент Часть АС, выделенная по определенному признаку или совокупности признаков и рассматриваемая как единое целое (ГОСТ Р 59853-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения») Контракт Контракт на выполнение работ по развитию и оказанию услуг по технической поддержке Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК в 2026 году, заключаемый по результатам проведения конкурентной процедуры закупки в соответствии с требованиями Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» - - Значение характеристики не может изменяться участником закупки

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

ФГБУ «СИЦ Минтранса России» Федеральное государственное бюджетное учреждение «Ситуационно-информационный центр Министерства транспорта Российской Федерации», Заказчик Федеральный закон № 44-ФЗ Федеральный закон от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» ФЗ Функциональная задача ФЗ «Реестр объектов» Функциональная задача «Формирование и ведение единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации» ФСБ России Федеральная служба безопасности Российской Федерации ФСТЭК России Федеральная служба по техническому и экспортному контролю ЧС Чрезвычайная ситуация ЭВМ Электронно-вычислительная машина API От англ. Application Programming Interface – интерфейс прикладного программирования – совокупность инструментов и функций в виде интерфейса для взаимодействия с программой CSS От англ. Cascading Style Sheets — каскадные таблицы стилей FPS От англ. frame per second - количество кадров в секунду HTML От англ. HyperText Markup Language - стандартный язык разметки документов, создающий основу и структуру всех веб-страниц JSON От англ. JavaScript Object Notation – текстовый формат обмена данными, основанный на JavaScript WebAssembly (Wasm) Открытый стандарт, представляющий собой низкоуровневый бинарный формат инструкций, который позволяет выполнять код, написанный на языках C++, Rust или Go, в браузерах с производительностью, близкой к нативной

1. ОБЩИЕ СВЕДЕНИЯ - – постановление Правительства Российской Федерации от 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 Федерального закона «Об электронной подписи»; - - Значение характеристики не может изменяться участником закупки

– постановление Правительства Российской Федерации от 08.06.2011 № 451 «Об инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг и исполнения государственных и муниципальных функций в электронной форме»; – постановление Правительства Российской Федерации от 30.01.2013 № 62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин»; – приказ ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации»; – приказ ФСТЭК России от 11.04.2025 № 117 «Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений»; – приказ ФСБ России от 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.7. Сроки начала и окончания работ Начало работ: с даты заключения Контракта. Окончание работ: не позднее 15.12.2026. Работы выполняются в соответствии с этапами. Сроки выполнения этапов работ по развитию и технической поддержке Модуля СЦ определяются Календарным планом. Календарный план, приведен в разделе 5 настоящего ТЗ

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

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

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

1.1. Наименование Системы Полное наименование системы: Информационно-аналитическая система регулирования на транспорте. Условное обозначение системы: АСУ ТК. Полное наименование модуля: Модуль сбора, ведения и анализа информации о нештатных ситуациях на транспорте. Условное обозначение модуля: Модуль СЦ. Модуль СЦ создан в рамках контракта от 05.08.2024 № ОК/24_04 на выполнение работ по развитию АСУ ТК в части создания модуля «Сбора, ведения и анализа информации о нештатных ситуациях на транспорте». Развитие Модуля СЦ осуществлено в рамках контракта от 19.05.2025 № ОК/25_09 на выполнение работ по развитию Модуля сбора, ведения и анализа информации о нештатных ситуациях на транспорте АСУ ТК

1.2. Шифр темы или номер контракта Присваивается Заказчиком по результатам организации закупочных процедур. 1.2.1. Предмет контракта Выполнение работ по развитию Модуля СЦ. Код по ОКПД2: 62.01.11.000 – услуги по проектированию и разработке информационных технологий для прикладных задач и тестированию программного обеспечения. Оказание услуг по технической поддержке Модуля СЦ. Код по ОКПД2: 62.02.30.000 – услуги по технической поддержке информационных технологий. Выполнение работ по развитию Модуля СЦ предусмотрено с учетом ключевых результатов (ОКР) Ведомственной программы цифровой трансформации Минтранса России на 2026-2028 (далее - ВПЦТ Минтранса России) в составе мероприятия № 103.002 «АСУ ТК» ИТ расхода 103.26.000005 «Развитие Информационно-аналитической системы регулирования на транспорте (АСУ ТК)»: · «Обеспечено информационное взаимодействие с Минобороны о происшествиях на транспортных объектах»; · «Обеспечена автоматизация формирования отчетов о нештатных ситуациях на транспорте, в том числе по данным внешних систем». Выполнение работ по технической поддержке АСУ ТК предусмотрено ВПЦТ Минтранса России в составе мероприятия № 103.002 «АСУ ТК» ИТ расхода 103.26.000021 «Эксплуатация Информационно-аналитической системы регулирования на транспорте (АСУ ТК)»

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

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

1.5. Основания для выполнения работ Работы осуществляются на основании следующих документов: – постановление Правительства Российской Федерации от 30.12.2003 № 794 «О единой государственной системе предупреждения и ликвидации чрезвычайных ситуаций»; – постановление Правительства Российской Федерации от 08.11.2013 № 1007 «О силах и средствах единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций»; – распоряжение Правительства Российской Федерации от 27.11.2021 № 3363-р «О Транспортной стратегии Российской Федерации до 2030 года с прогнозом на период до 2035 года»; – Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 26.08.2025 №ЕФ-3; – Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 27.11.2025 №ЕФ-23;

– Протокол заседания Комиссии Минтранса России по предупреждению и ликвидации чрезвычайных ситуаций и обеспечению пожарной безопасности, утвержденной приказом Минтранса России от 20.09.2005 № 112 «О функциональной подсистеме транспортного обеспечения ликвидации чрезвычайных ситуаций единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций», под председательством заместителя Министра транспорта Российской Федерации Филиппова Е.С. от 19.02.2026 №ЕФ-1; – План мероприятий по профилактике случаев непроизводственного травматизма граждан на железнодорожном транспорте, являющийся приложением к постановлению коллегии Министерства транспорта Российской Федерации от 11.03.2026 № 2

1.6. Перечень документов, требования которых должны быть учтены при выполнении работ – Федеральный закон Российской Федерации от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации»; – Федеральный закон Российской Федерации от 27.07.2006 № 152-ФЗ «О персональных данных»; – Федеральный закон Российской Федерации от 06.04.2011 № 63-ФЗ «Об электронной подписи»; – Федеральный закон Российской Федерации от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации»; – Указ Президента Российской Федерации от 30.03.2022 № 166 «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации»; – Указ Президента Российской Федерации от 01.05.2022 № 250 «О дополнительных мерах по обеспечению информационной безопасности Российской Федерации»; – Указ Президента Российской Федерации от 31.03.2010 № 403 «О создании комплексной системы обеспечения безопасности населения на транспорте»; – постановление Правительства Российской Федерации от 30.07.2004 № 395 «Об утверждении Положения о Министерстве транспорта Российской Федерации»; – постановление Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации»; – постановление Правительства Российской Федерации от 16.11.2015 № 1236 «Об установлении запрета на допуск программного обеспечения, происходящего из иностранных государств, для целей осуществления закупок для обеспечения государственных и муниципальных нужд»; – постановление Правительства Российской Федерации от 23.12.2024 № 1875 «О мерах по предоставлению национального режима при осуществлении закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд, закупок товаров, работ, услуг отдельными видами юридических лиц»;

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

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

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

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

3. ХАРАКТЕРИСТИКА ОБЪЕКТА АВТОМАТИЗАЦИИ - 3.1. Описание объекта автоматизации АСУ ТК Объектом автоматизации являются процессы основной и обеспечивающей деятельности, направленные на управление транспортным комплексом, в том числе, процессы информационного взаимодействия с другими организациями и субъектами транспортного комплекса. АСУ ТК относится к государственным информационным системам, а также к информационным системам персональных данных и значимым объектам критической информационной инфраструктуры Российской Федерации. АСУ ТК соответствует требованиям, предъявляемым к: – ГИС второго класса защищенности в соответствии с приказом ФСТЭК России от 11.02.2013 № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах»; – ИС персональных данных при обеспечении третьего уровня защищенности персональных данных в соответствии с требованиями постановления Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»; – значимым объектам КИИ Российской Федерации второй категории значимости с постановлением Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении Правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений». Модуль СЦ является подсистемой АСУ ТК. Перечень платформенных решений и функциональных задач АСУ ТК представлен в Таблице 1 - - Значение характеристики не может изменяться участником закупки

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

8 Подсистема проектного архива АСУ ТК Подсистема проектного архива АСУ ТК предназначена для автоматизации деловых процессов должностных лиц Министерства транспорта Российской Федерации, подведомственных агентств и службы, в том числе, и процессов информационного взаимодействия внутреннего и внешнего характера 9 ФЗ «Реестр объектов» Функциональная задача предназначена для формирования и ведения единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации 10 ФЗ «СТП» Функциональная задача предназначена для организации информационно-аналитической поддержки процессов территориального планирования Российской Федерации в области федерального транспорта 11 ФЗ «МРТБ ПП» Функциональная задача предназначена для формирования и ведения межрегионального транспортного баланса пассажирских перевозок в дальнем (межрегиональном) сообщении 12 ФЗ «МДД» Функциональная задача предназначена для осуществления мониторинга дорожного движения 13 ФЗ «ТПР» Функциональная задача предназначена для формирования и ведения транспортного паспорта региона 14 ФЗ «Данные по грузообороту» Функциональная задача предназначена для обеспечения подсистем и пользователей АСУ ТК данными по грузообороту между Российской Федерацией и зарубежными странами 15 ФЗ «МЖТ» Функциональная задача предназначена для осуществления мониторинга железнодорожного транспорта 16 ФЗ «МГМП» Функциональная задача предназначена для осуществления мониторинга грузопотоков в морских портах с целью формирования единой цифровой среды мониторинга и планирования перевозок в/из портов Дальнего Востока

17 Модуль ГЭТ Модуль предназначен для получения, хранения данных инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по отдельно взятому предприятию-перевозчику. Формирования отчетов об инвентаризации с детальными данными по каждому разделу инвентаризации с маршрутизацией в муниципалитет / регион / Минтранс. Содержит агрегированные данные инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по всем перевозчикам, относящихся к данному муниципалитету. Формирует сводный отчет по муниципалитету по каждому разделу инвентаризации с маршрутизацией в регион / Минтранс. Формирует агрегированные данные инвентаризации транспортных средств, маршрутов, пассажиропотоков и инфраструктуры ГЭТ по всем перевозчикам, относящиеся к данному региону и по всем муниципалитетам, относящимся к данному региону. Аналитические и статистические данные о состоянии ГЭТ региона. Содержит данные о видах транспорта, цифровых транспортных сервисах и платежных инструментах Региона. Формирует сводный отчет по каждому разделу инвентаризации с маршрутизацией в Минтранс. Формирует агрегированную статистику и аналитику по всем регионам страны в разрезе транспортных средств, маршрутов, пассажиропотоков, инфраструктуры ГЭТ. Данные о рейтинге регионов и перевозчиков на основании выбранных параметров, документооборот с участниками Системы: получение подписанных печатных форм, их утверждение, возврат на доработку. 18 Модуль iМинтранс Модуль создан для отчета по ключевым показателям транспортного комплекса России (Отраслевые и статистические показатели, исполнение бюджета, исполнение поручений, аналитика СМИ, происшествия по видам транспорта). 19 Модуль СЦ Модуль СЦ предназначен для оперативного мониторинга нештатных ситуаций транспортной отрасли, оповещения заинтересованных лиц и структур и предоставления данных о нештатных ситуациях

АСУ ТК осуществляет идентификацию и авторизацию посредством Единой системы идентификации и аутентификации (ЕСИА). Информационный обмен с внешними информационными системами осуществляется посредством СМЭВ 3 и СМЭВ 4. АСУ ТК развернута на вычислительных мощностях ГЦОД СИЦ Минтранса России

3.2. Описание и текущее состояние объекта автоматизации Модуля СЦ Объектом автоматизации является процесс организации мониторинга информации о НС и ЧС на транспорте. Предметом деятельности Учреждения являются следующие функции: – информационное обеспечение в области транспортной безопасности, защиты населения и территорий от чрезвычайных ситуаций природного и техногенного характера в транспортном комплексе; – подготовка справочных материалов при угрозе возникновения и возникновении чрезвычайных ситуаций и иных происшествий в транспортном комплексе; – взаимодействие и обмен оперативной информацией с органами управления Единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций; – организация оперативного мониторинга обстановки на объектах транспорта при угрозе и возникновении чрезвычайных ситуаций и иных происшествий. Перечень компонентов Модуля СЦ и выполняемые ими функции представлены в Таблице 2

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

3 Информирование – ведение справочника способов оповещения (веб-интерфейс, мессенджер); – формирование сценария выполнения оповещения (настройка условий, способа, параметров оповещения); – выполнение оповещений пользователей 4 Отчетность – формирование отчета и справки о событиях; – фильтрация событий для выгрузки в справку о событиях или в отчет о событиях 5 Администрирование – ведение ролей пользователей; – ведение учетных данных пользователей; – ведение справочника организаций; – ведение справочника групп системы мгновенного обмена сообщениями; – выполнение исходящего звонка на контактный телефонный номер организации; – формирование матрицы эскалации событий Архитектура Модуля СЦ представлена на рисунке 1. Рисунок 1. Архитектура Модуля СЦ

3.3. Состав используемого ПО Модуля СЦ Программная архитектура Модуля СЦ разработана как трехуровневая клиент-серверная архитектура. Архитектура включает в себя следующие уровни: • уровень представления – презентационный уровень, обеспечивающий взаимодействие с пользователя с клиентскими приложениями с использованием веб-браузера («тонкий» клиент); • уровень приложений – реализован в виде сервисов, обеспечивает обработку запросов, поступающих от клиентских приложений, формирование ответов на запрос в доступном пользователю виде (формирование пользовательских интерфейсов); • уровень хранения данных – реализуется как сервер БД и обеспечивает хранение и целостность хранимых данных, создание резервных копий, ведение журнала транзакций, восстановление данных после сбоев. Программная архитектура Модуля СЦ включает в себя сервисы и интерфейсы, указанные в Таблице 3. Таблица 3. Программная архитектура Модуля СЦ Программный сервис/интерфейс Технологии реализации Уровень представления Интерфейс пользователя и администратора (front-end) Javascript Уровень приложений Сервис (GateWay) Kotlin Сервис геокодирования (geocoding-service) Kotlin Сервис уведомлений (notifiсation-service) Kotlin Сервис работы с файлами (file-service) Kotlin Сервис отчетности (report-service) Kotlin Сервис управления событиями (event-service) Kotlin Сервис информирования через мессенджер (messenger-notifier) Python Сервис внешних интеграций (integration-service) Сбор информации из внешних систем и сервисов Брокер сообщений Kafka Уровень хранения данных Файловое хранилище MinIO S3 СУБД Postgres Pro Enterprise

3.4. Информационное взаимодействие программных сервисов и интерфейсов Модуля СЦ Объект автоматизации функционирует в распределенной информационной среде. Обмен данными осуществляется по защищенным каналам связи (в том числе ведомственным сетям передачи данных). Источники информации включают: · внешние автоматизированные системы (органов государственной власти); · внутренние базы данных (реестры объектов транспортной инфраструктуры, паспорта регионов и пр.); · оперативная информация от персонала, поступающая через автоматизированные рабочие места (АРМ) и мобильные устройства. 3.4.1. Взаимодействие Модуля СЦ со смежными подсистемами АСУ ТК Модуль СЦ входит в состав АСУ ТК и взаимодействует со следующими ее функциональными задачами и подсистемами: · Функциональной задачей «Формирование и ведение единой базы пространственных и технических данных по объектам и субъектам транспортного комплекса Российской Федерации» (ФЗ «Реестр объектов»); · Геоинформационной подсистемой АСУ ТК (П-ГИС); · Подсистемой ведения нормативно-справочной информации и метаданных (П-НСИ); · Подсистемой сбора данных и централизованное хранилище данных (П-СД); · Подсистемой информационного взаимодействия (П-ИВ). 3.4.2. Взаимодействие с внешними информационными системами Список внешних информационных систем, с которыми осуществляется взаимодействие Модуля СЦ: · ЕСИА; · мессенджер; · Яндекс Геокодер; · Информационная система «Централизованная система сбора информации систем-112»; · ПВК «Поиск-Море», АИС РПТ; · облачная АТС

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

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

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

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

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

4.5.8. Требования к защите от влияния внешних воздействий Требования к защите от влияния внешних воздействий не предъявляются

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

4.3.4. Требования к документированию результатов оказываемых услуг Для обеспечения контроля оказываемых услуг по поддержке Модуля СЦ со стороны Заказчика, по окончании каждого отчетного периода по контракту в соответствии с календарным планом, Подрядчик обязан предоставить Заказчику Отчет об оказанных услугах. Отчет должен содержать детальную информацию об оказанных услугах с указанием даты выполненных мероприятий и приложением обосновывающих документов (заявок, запросов, требований) или ссылкой на такие документы, если они содержатся в Модуле СЦ. Информация о выполненных мероприятиях по заявкам должна быть сформирована на основании соответствующих записей СРО по каждому этапу исполнения Контракта. В случае оказания услуги адаптационного, конфигурационного и коррекционного сопровождения Модуля СЦ, должны быть предоставлены документы, подтверждающие выполнение требований п. 29.3 приказа ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации». Фактическое время реагирования и время решения по всем обращениям, поступившим в СРО, формируется в СРО по итогам отчетного периода в разделе «Отчеты». Фактическое время реагирования и время решения по обращениям учитывает суммарное время, затраченное на реагирование и, соответственно, на работу по обращению с момента назначения обращения специалисту Подрядчика или группе исполнителей, ответственным за оказание услуг технической поддержки 3 уровня от начала до завершения работ Подрядчиком. При этом принимается суммарное время нахождения заявки в соответствующих статусах заявки СРО на стороне Подрядчика

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

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

Лицензионное (сублицензионное) соглашение (договор) не может возлагать на Заказчика какие-либо обязанности (в т.ч. в части конфиденциальности, предоставления отчетности), не предусмотренные Контрактом. 4.5.9.7. Передача Заказчику исключительных прав, или простых (неисключительных) прав не может повлечь увеличение стоимости Контракта и/или изменение иных существенных условий Контракта. 4.5.9.8. Функциональность Модуля СЦ передается в объеме и в сроки, установленные Техническим заданием. 4.5.9.9. Нарушение условий настоящего раздела Технического задания, в т.ч. отсутствие соответствующего лицензионного (сублицензионного) соглашения (или договора), либо предоставление лицензионного (сублицензионного) соглашения (или договора), не соответствующего требованиям действующего законодательства Российской Федерации или требованиям Контракта, является нарушением существенных условий Контракта. 4.5.9.10. В случае, если в соответствии с пунктом 4.5.9.6 Заказчику передается исключительное право, такая передача осуществляется в порядке, установленном Гражданским кодексом Российской Федерации. 4.5.9.11. В случае, если при выполнении Работ положения пунктов 4.5.9.5-4.5.9.6 не применялись, Подрядчик в составе отчетной документации предоставляет об этом декларацию в свободной форме. Декларация должна содержать сведения о полном соответствии результата Работ требованиям Контракта, а также о неприменении при выполнении работ готового программного обеспечения (платформ, подсистем, СУБД и т.д.), которое стало частью (компонентом) Системы

Таблица 6. Категории обращений и заявок Категория Примеры Запрос на обслуживание Подготовка SQL запроса к СУБД для решения прикладной задачи и д.р. – запрос на любое действие, не являющееся запросом информации и несовершенный на основе происшествия, прямо или косвенно влияющего на работу Модуля СЦ Консультация «Где взять / куда обратиться...?», «Как сделать / выполнить…», «Как это работает…?» - запрос, имеющий своей целью получение информационной поддержки Инцидент Разбор ошибок/сбоев и подготовка материалов (корректировочных релизов, инструкций) для Заказчика для устранения ошибок/сбоев, которые приводят к частичному и полному нарушению работоспособности всех или отдельных функций ППО. Подготовка изменения и материалов, необходимых для проведения аварийно-восстановительных работ для возобновления работоспособности Модуля СЦ ЗНИ Подготовка изменений, связанных с изменением, улучшением/оптимизацией Модуля СЦ и выводом новой модифицированной функциональности в штатном режиме. Подготовка изменений, связанных с модификацией существующих и/или реализация новых интеграционных механизмов для получения/обработки данных внешних систем. Подготовка изменений графического интерфейса по требованиям Заказчика. Перечень статусов обращений (заявок) приведен в пункте 3.3. Регламента оказания Услуг. Назначение обращению (заявке) статуса «Закрыто» осуществляется Заказчиком только после получения от инициатора обращения (заявки) подтверждения о его исполнении или нахождения обращения (заявки) в статусе «Выполнено» и отсутствия повторных вопросов/запросов по данному обращению (заявки) в течение 5 рабочих дней. Категории и статусы обращений (заявок) могут быть скорректированы в процессе оказания услуг исключительно по согласованию с Заказчиком

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

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

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

4.3.6.2. Требования к услугам информационно-консультационной поддержки работников Заказчика и пользователей Модуля СЦ Услуги информационно-консультационной поддержки сотрудников Заказчика включают: – обработку обращений и заявок, поступивших от сотрудников Заказчика; – консультирование сотрудников Заказчика и пользователей Модуля СЦ; – актуализацию документации, и других материалов по работе с Модулем СЦ при необходимости. – консультирование и разработку рекомендаций по настройке Модуля СЦ (без изменения программного кода), включая изменение настроек функционирования; – консультации по вопросам использования, настройки и возможностям Модуля СЦ; – консультации по проведению превентивных мер для недопущения аварийных ситуаций в Модуле СЦ; – консультации по предварительной диагностике и локализации возникшей неисправности Модуля СЦ; – консультации по вопросам обеспечения информационной безопасности Модуля СЦ и настройки функций, обеспечивающих корректную работу программного обеспечения для совершения юридически значимых действий в Модуле СЦ; – другие вопросы, связанные с работой Модуля СЦ. 4.3.6.2.1. Требования к порядку оказания услуг информационно-консультационной поддержки работников Заказчика и пользователей Модуля СЦ Подрядчик выполняет консультирование сотрудников Заказчика и пользователей Модуля СЦ. Консультация может быть предоставлена по согласованным с представителем Заказчика каналам коммуникации с регистрацией результата консультации в СРО Подрядчиком. Детальный порядок оказания консультационных услуг определен в Регламенте оказания Услуг

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

4.5.11. Требования к показателям назначения 4.5.11.1. Требования к показателям назначения мероприятий по развитию Модуля СЦ В рамках выполнения работ по развитию Модуля СЦ, предусмотренных ТЗ, показатель назначения «Количество пользователей» должен соответствовать значениям, приведенным в данном разделе. Пояснения по показателям, связанным с количеством пользователей, приведены в Таблице 8. Таблица 8. Определения показателей, связанных с количеством пользователей в Модуле СЦ № Показатель Определение Расчетное количество пользователей Количество пользователей, работу которых должен обеспечить Модуль СЦ к моменту сдачи работ по Контракту с учетом достижения всех показателей назначения Расчетное количество одновременно работающих пользователей Количество одновременно работающих пользователей, работу которых должен обеспечивать Модуль СЦ к моменту сдачи работ по Контракту с учетом достижения всех показателей назначения Значения показателей количества пользователей, достижение которых необходимо обеспечить, представлено в Таблице 9

Таблица 9. Значения показателей количества пользователей № Показатель Значение 1. Расчетное количество пользователей 1 000 2. Расчетное среднее количество одновременно работающих пользователей 200 Развитие Модуля СЦ должно быть направлено на достижение следующего эффекта (показателя), подставленного в мероприятии 103.002 «Информационно-аналитическая система регулирования на транспорте (АСУ ТК)» ВПЦТ Минтранса России: Выполнение работ по развитию Модуля СЦ предусмотрено мероприятием по развитию АСУ ТК, приведенном в ВПЦТ Минтранса России на 2026-2028 гг: № 103.002 «АСУ ТК» в составе ИТ расхода 103.26.000005 «Развитие предусматривает реализацию ОКР и эффектов, приведенных в Таблице 10. Таблица 10. ОКР и эффекты, приведенные в ВПЦТ Минтранса России на 2026 г. № ОКР Дата ОКР Эффекты 1 Обеспечено информационное взаимодействие с Минобороны России о происшествиях на транспортных объектах 25.12.2026 Сокращено время сбора и передачи сведений для Минобороны России о ЧС и НС на транспорте с 120 до 10 минут 2 Обеспечена автоматизация формирования отчетов о нештатных ситуациях на транспорте, в том числе по данным внешних систем 25.12.2026 Сокращено время на подготовку отчетов о нештатных ситуациях на транспорте с 20 до 5 минут Реализация остальных ОКР не является предметом данного ТЗ и проводится в рамках отдельного технического задания.

4.5.11.2. Требования к показателям назначения мероприятий по эксплуатации Модуля СЦ. Работы по эксплуатации Модуля СЦ не должны обеспечивать режимы функционирования Модуля СЦ, приведенные в разделе 4.5.2 данного ТЗ

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

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

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

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

4.3.6.4. Требования к услугам адаптационного, конфигурационного и коррекционного сопровождения и доработки Модуля СЦ (в рамках действующих программных модулей и функциональностей) Услуги адаптационного, конфигурационного и коррекционного сопровождения и доработки Модуля СЦ включают: – управление изменениями и адаптация функций Модуля СЦ; – изменение настроек функционирования Модуля СЦ; – внесение изменений и/или модификаций Модуля СЦ (в рамках действующих программных модулей и функциональностей), направленных на улучшение их работоспособности и функциональных возможностей; – подготовка и передача Заказчику SQL запросов в СУБД для получения агрегированной информации из Модуля СЦ, которую невозможно получить с использованием графического пользовательского интерфейса; – адаптация модулей интеграций со смежными информационными системами

4.3.6.4.1. Требования к проведению изменений Основанием для внесения изменений является запрос от Заказчика. Все активности по внесению изменений должны быть согласованы с Заказчиком, а действия Подрядчика при оказании данной услуги должны быть зафиксированы. В рамках данного Технического задания изменениями считаются локальные доработки функционала Модуля СЦ, которые не должны приводить к необходимости выполнения дополнительных аттестационных испытаний или переаттестации АСУ ТК в соответствии с п. 33 приказа от 29.04.2021 № 77 «Об утверждении Порядка организации и проведения работ по аттестации объектов информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну». При необходимости внесения изменений в Модуль СЦ, не связанных с критичным инцидентом, существенно нарушающим работоспособность Модуля СЦ, Заказчик направляет Подрядчику обращение (заявку), в котором излагает суть изменения, которое требуется внести в Модуль СЦ. Исполнитель, в течение 3 (трех) рабочих дней с момента поступления соответствующего обращения (заявки), оценивает техническую возможность реализации запрашиваемого изменения и варианты реализации. По итогу проведения оценки Подрядчик направляет Заказчику заключение о возможности реализации данного изменения с описанием возможных вариантов реализации и согласует с Заказчиком проведение данного изменения

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

4.3.6.4.2. Требования к изменению настроек функционирования Изменение настроек функционирования может проводиться в рамках допустимых пределов изменения функционирования, заложенных в архитектуру Модуля СЦ. Изменение настроек функционирования включает в себя изменение данных и справочников, изменение форм документов, формируемых Модулем СЦ, изменение и настройку форматов и версий передачи данных в смежные системы. Доработка программного кода Модуля СЦ может допускаться (в случае необходимости) при выполнении работ по адаптации функций Модуля СЦ в части изменения формата передачи данных в смежные информационные системы при условии соблюдения требований пункта 29.3 приказа ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации»

4.3.6.5. Требования к услугам по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности По запросу Заказчика Подрядчик должен провести работу по приведению ППО в соответствие с требованиями по обеспечению информационной безопасности. Критичность уязвимости оценивается в соответствии в соответствии с Методическим документом ФСТЭК России «Методика оценки уровня критичности уязвимостей программных, программно-аппаратных средств» (утвержден ФСТЭК России 30.06.2025), а также с учетом ГОСТ 56545-2015 и международными стандартами (CVSS 3.0 и выше), и задает необходимый срок устранения. В процессе проведения Заказчиком обследования Модуля СЦ и выявления уязвимостей в ППО, связанных с исходным кодом Модуля СЦ и/или используемыми компонентами (библиотеками), Заказчик направляет Подрядчику обращение (заявку) на устранение, с указанием критичности и срочности принятия мер по устранению в СРО.

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

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

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

4.4. Требования к видам обеспечения 4.4.1. Требования к лингвистическому обеспечению Документация на Модуль СЦ должна разрабатываться на русском языке. Взаимодействие пользователей с Модулем СЦ посредством графического интерфейса должно происходить на русском языке за исключением сообщений, зависящих от настроек системного программного обеспечения, установленного на рабочих местах пользователей. При разработке программных решений Модуля СЦ должно быть предусмотрено использование языков программирования высокого уровня, приведенных в Таблице 7. Таблица 7. Языки и средства разработки, специального программного обеспечения Модуля СЦ Категория Наименование Назначение Языки программирования Kotlin Разработка серверной логики и сервисов (backend) JavaScript / TypeScript Разработка клиентской части (frontend) Python Разработка скриптов интеграции, обработки данных и автоматизации Фреймворки и библиотеки Vue.JS Разработка пользовательских интерфейсов (веб-интерфейсы компонентов визуализации и отчетности) React Разработка пользовательских интерфейсов (при необходимости создания сложных интерактивных компонентов) Решения по лингвистическому обеспечению, включая перечень используемых языков программирования, должны быть согласованы с Заказчиком на этапе технического проектирования

4.4.2. Требования к математическому обеспечению Требования к математическому обеспечению не предъявляются. 4.4.3. Требования к метрологическому обеспечению Требования к метрологическому обеспечению не предъявляются. 4.4.4. Требования к организационному обеспечению Требования к организационному обеспечению не предъявляются. 4.4.5. Требования к методическому обеспечению Задачи методического обеспечения Модуля СЦ должны быть обеспечены за счет использования технологических и методических документов касающихся вопросов функционирования транспортного комплекса и разработки и эксплуатации ПО. 4.4.6. Требования к информационному обеспечению Состав, структура и способы организации информационного обеспечения в Модуле СЦ должны быть определены на этапе технического проектирования. Факты информационного обмена с внешними системами должны фиксироваться в соответствующем журнале

4.1. Требования к структуре Модуля СЦ В процессе работ по развитию Системы должны сохраниться основные требования к построению архитектуры Системы в соответствии с принципами трехуровневой архитектуры: 1. уровень хранения данных или уровень базы данных (сервер СУБД); 2. уровень сервера приложений (сервер аналитической обработки); 3. презентационный уровень, обеспечивающий взаимодействие с клиентскими приложениями. В состав Системы должны входить следующие основные компоненты: 4. сервер баз данных; 5. сервер приложений; 6. веб-сервер. Сервер баз данных должен обеспечивать хранение и целостность хранимых данных, создание резервных копий, ведение журнала транзакций, восстановление данных после сбоев. Сервер приложений должен обеспечивать обработку запросов, поступающих от клиентских приложений (через веб-сервер), формирование ответов на запрос в доступном пользователю виде (формирование пользовательских интерфейсов). Веб-сервер должен обеспечивать взаимодействие с оператором и внешними системами по HTTP / HTTPS протоколу в режиме «запрос-ответ» (получения запросов от пользователя и передачи ответа в виде соответствующей информации, обработанной серверами приложений). Взаимодействие Системы с пользователем должно отвечать требованиям модели «тонкого клиента» (т.е. представлять на стороне клиента (пользователя) лишь графический пользовательский интерфейс). Все составляющие Системы должны использовать единую методологию и отвечать единым принципам взаимодействия, надежности и управления. Перечень компонентов Модуля СЦ представлен в Таблице 4. Таблица 4. Перечень компонентов Модуля СЦ, в отношении которых выполняются работы по развитию № п.п. Наименование компонента Модуля СЦ Раздел ТЗ 1 Компонент регистрации событий 4.2.1. 2 Компонент отчетности 4.2.2 3 Компонент визуализации 4.2.3 4 «Интерактивная карта» (компонент создается) 4.2.4 5 Компонент администрирования 4.2.5

4.2. Требования к дорабатываемым функциям модуля СЦ 4.2.1. Развитие компонента регистрации событий (1 очередь) Должны быть выполнены следующие доработки: – обеспечение логирования действий пользователя, связанных с карточкой события; – доработка объектной модели в части создания новых типов сущностей (карточек) с учетом реализуемых интеграций с информационными ресурсами (силы и средства предупреждения и ликвидации ЧС и нештатных ситуаций на транспорте, ТС, ограничения воздушного пространства, неблагоприятные и опасные природные явления); – реализация механизма установления связи между сущностями в Модуле СЦ автоматизированным и ручным способами (события, природные явления, силы и средства предупреждения и ликвидации ЧС и нештатных ситуаций на транспорте, ограничения воздушного пространства, ОТИ, ТС и др.); – отображение в карточке установленных связей между сущностями.

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

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

4.4.7.1. Требования к инструментам разработки и процессу контроля версий программного обеспечения 4.4.7.1.1. Система контроля версий Для управления исходным кодом должна использоваться система контроля версий кода, развернутая в инфраструктуре Заказчика. 4.4.7.1.2. Правила именования веток Имя ветки должно соответствовать следующему формату: / / Категории веток: ? feature/ — разработка новой функциональности, а также рефакторинг или удаление существующей; ? fix/ — исправление ошибок; ? hotfix/ — срочные исправления, применяемые в обход стандартного процесса разработки; ? test/ — для проведения экспериментов, не влияющих на основную разработку. Идентификатор задачи: после категории указывается ссылка на задачу (issue) в системе контроля версий кода. Описание: добавляется краткое описание решаемой задачи в формате kebab-case (слова разделяются дефисами, например, add-user-auth). Примеры именования веток: ? feature/#123/add-payment-integration; ? fix/#45/correct-calculation-logic; ? hotfix/#67/urgent-database-connection-patch. 4.4.7.1.3. Правила именования коммитов Сообщение коммита должно соответствовать соглашению Conventional Commits и состоять из категории и описания: : ? fix — исправление ошибки. Примеры сообщений коммитов: ? feat: добавление формы регистрации пользователя; ? fix: исправление ошибки валидации email-адреса; ? refactor: оптимизация алгоритма сортировки данных; ? chore: обновление версий в файле dependencies. 4.4.7.1.4. Модель ветвления В процессе разработки используются следующие основные ветви: ? main / master — стабильная ветка, содержит только код, прошедший полное тестирование и развернутый в продуктивных контурах; ? dev — ветка для интеграции завершенных задач, предназначенная для сборки и тестирования в тестовых средах. Попадание кода в main осуществляется только через Merge Request (MR) из dev

4.2.2. Развитие компонента отчетности (3 очередь) Должна быть обеспечена автоматизация процессов формирования отчетов о ЧС и нештатных ситуациях на транспорте, в т.ч. на основе данных из внешних систем. Включает следующие доработки: – разработка шаблонов отчетов в различных форматах (табличный, текстовый); – реализация выбора фотоматериалов для включения в справку; – форматирование содержимого справок с учетом правил русского языка в отношении окончаний слов (в зависимости от падежа, склонения, числа и рода); – автоматизированное формирование выводов к содержимому справки на основе настраиваемых критериев; – создание интерфейса выбора параметров (фильтрации) для формирования отчетов: o состав полей для включения в отчёт; o настройка диапазонов значений характеристик и дат; o порядок отображения полей; o настройка заголовка. – реализация способа подготовки отчётов в асинхронном режиме (очереди); – реализация интерфейса компонента формирования отчетности для отображения очереди формирования отчетов и статусов их подготовки; – экспорт отчётов в форматы xlsx, csv и справок в форматы pdf, docx. Необходимо разработать не менее 10 шаблонов отчетов и/или справок. Перечень, структура и содержание шаблонов должны быть согласованы с Заказчиком на этапе технического проектирования.

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

– отображение на карте связанных сущностей и ОТИ; – реализация функции выбора темного и светлого стилей отображения элементов интерфейса, карточек сущностей, картографической основы и объектов, отображаемых на карте; – реализация механизма для выбора картографической основы в одном из распространенных форматов WMTS, TMS, MVT и др. Должна быть предусмотрена возможность настройки перечня картографических основ и параметров доступа к ним; – настройка базового набора дашбордов, содержащих преднастроенные виджеты о количестве событий в разрезе видов транспорта с возможностью перехода к исходным данным (карточкам событий, ОТИ и т.д.), с фильтрацией по параметрам. Параметры фильтрации должны быть определены на этапе технического проектирования. Должно быть обеспечено автоматическое и принудительное обновление данных, отображаемых на дашбордах

4.4.7.1.5. Требования к используемым зависимостям (библиотекам) Все внешние зависимости проекта должны быть зафиксированы с указанием точных версий. Для контроля версий зависимостей в репозиторий обязательно должны быть включены следующие файлы: · Для JavaScript: package-lock.json или yarn.lock; · Для Python: requirements.txt (с зафиксированными версиями) или Pipfile.lock; · Для Go: go.mod и go.sum; Загрузка всех зависимостей должна производиться исключительно через внутренний прокси-репозиторий Заказчика, настроенный в соответствующем системе менеджере пакетов. Запрещается: · Использование плавающих версий (например, ^1.2.3, ~4.5.0, latest); · Использование библиотек, содержащих критические уязвимости, в том числе зарегистрированные в реестре CVE (Common Vulnerabilities and Exposures). 4.4.7.1.6. Требования к процессу непрерывной интеграции (CI) Сборка программного обеспечения, включая этапы компиляции, тестирования и анализа кода, должна выполняться исключительно в инфраструктуре непрерывной интеграции Заказчика. 4.4.7.1.7. Требования к хранению артефактов сборки Все артефакты сборки (результирующие пакеты, Docker-образы и т.д.) подлежат обязательному хранению в предназначенной для этого инфраструктуре Заказчика (артефакторий). Запрещается размещение финальных артефактов сборки на сторонних ресурсах

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

4.5. Общие технические требования 4.5.1. Требования к численности и квалификации персонала и пользователей Модуля СЦ Программное обеспечение Модуля СЦ не должно требовать изменения штатной численности персонала Заказчика. Программное обеспечение Модуля СЦ не должно требовать наличия у пользователей дополнительной квалификации в сфере информационных технологий, кроме базовых знаний в обращении с персональным компьютером, базовых навыков работы в интернет-обозревателях и знаний о Модуле СЦ в объеме документов Руководство пользователя, Руководство администратора

4.2.4. Создание компонента «Интерактивная карта» (2 очередь) В составе создаваемого компонента должны отображаться данные, доступные в компоненте визуализации. Требования к интерфейсу интерактивной карты: – интерактивная карта должна быть представлена в виде объемной карты с учетом макетов, представленных в Приложении А к ТЗ; – интерфейс должен корректно отображаться на экранах мониторов (разрешение Full HD 1920?1080), телевизоров (разрешение 4К 3840?2160), жидкокристаллических панелей для видеостены, используемой Заказчиком, с параметрами каждой панели: диагональ 55 дюймов, разрешение 1920x1080; – интерфейс должен корректно отображаться на планшетных устройствах с диагональю экрана 10-12 дюймов, конкретные требования должны быть уточнены на этапе технического проектирования; – должна быть обеспечена кластеризация и генерализация отображения объектов на карте при изменении масштаба; – должно быть обеспечено отображение основных характеристик объектов при выборе их на карте; – должно быть обеспечено управление отображением слоев на карте; – должна быть обеспечена настройка цветовой индикации отображаемых объектов транспортной инфраструктуры; – должно быть обеспечено отображение легенды карты, содержащей отображаемые объекты на карте; – должна быть обеспечена возможность одновременного отображения не менее 5 000 ОТИ и ТС на карте.

На интерактивной карте должны быть отображены подвижные объекты совместно с объектами транспортной инфраструктуры (ОТИ), включая следующие возможности: § отображение местоположения транспортных средств (воздушный, водный и автомобильный транспорт) на карте в режиме реального времени (с заданным периодом обновления данных); § отображение маршрутов движения всех ТС за выбранный период времени, в том числе с использованием эффектов анимации; § отображение маршрутов движения ТС, связанных с карточкой события: ТС, являющихся участниками события, и ТС, находящиеся в заданном радиусе от события; § управление отображением сущностей и ОТИ на карте, включая настройку состава отображаемых объектов, поиск, фильтрацию, с использованием соответствующей панели управления и наглядным представлением результатов; § автоматическое изменение вида отображения объектов (цветовая индикация) по заданным условиям (например, при достижении критических значений параметров, характеризующих функционирование объекта); Должна обеспечиваться производительность обновления изображения на экране в 30 кадров в секунду на тестовой конфигурации пользовательского устройства (модель Бештау AIO2402/B560, входящая в Реестр российской промышленной продукции под номером 10394100 или аналог) при одновременном отображении не менее 5 000 объектов и 200 уникальных моделей объектов. Макеты интерфейсов Модуля СЦ должны быть предварительно согласованы с Заказчиком и разработаны с учетом требований ГОСТ Р ИСО 9241-161-2016 «Элементы графического пользовательского интерфейса»

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

В аварийном режиме осуществляется поиск неисправностей и проведение работ по их устранению. Перевод в аварийный режим должен осуществляться при возникновении сбоев, аварий и прочих незапланированных воздействий, сразу после наступления одной или нескольких аварийных ситуаций, с последующим возвратом в штатный режим функционирования сразу после окончания восстановительных работ. ПО Модуля СЦ должно обладать надежностью, обеспечивающей работу пользователей в произвольном режиме и оперативное восстановление работоспособности при сбоях. В целях обеспечения надежного функционирования ПО должно предусматривать: – сохранение целостности данных при нештатном завершении работы компонентов Модуля СЦ; – сохранение работоспособности программного обеспечения при некорректных действиях пользователя; – резервное копирование базы данных Модуля СЦ. – время восстановления работоспособности Модуля СЦ после отказа не более 4 часов. – отказоустойчивость на уровне 99% при единовременной количестве не менее 200 пользовательских сессий в Модуле СЦ. Указанные характеристики приведены без учета характеристик надежности инфраструктуры и времени передачи информации по каналам связи. При возникновении сбоев в аппаратном обеспечении, включая аварийное отключение электропитания, Модуль СЦ должен автоматически восстанавливать свою работоспособность (не требовать перенастройки) после устранения сбоев и корректного перезапуска аппаратного обеспечения

4.2.4.1. Требования к технической реализации компонента «Интерактивная карта» При реализации компонента «Интерактивная карта» должны учитываться требования, указанные ниже. 4.2.4.1.1. Требования к отображению элементов Повторяющихся элементы карты (ТС, ОТИ, события и пр.) должны отрисовываться с использованием аппаратного создания экземпляров объектов на пользовательском устройстве (WebGL/WebGPU)). Отрисовка каждого объекта отдельным запросом не допускается, должна обеспечиваться возможность одновременного отображения не менее 5 000 объектов без снижения производительности (30 кадров в секунду на тестовой конфигурации). 4.2.4.1.2. Уровни детализации объектов Для управления отображением сложных объектов должно быть создано не менее 3-х уровней детализации, отображаемых при изменении масштаба с возможностью автоматического переключения между уровнями. Все отображаемые объекты должны масштабироваться с учетом разрешения экрана пользователя с сохранением качества детализации. 4.2.4.1.3. Полигональная оптимизация и текстурирование При реализации компонента «Интерактивная карта» должна обеспечиваться технология рельефного тестурирования объектов. Не должны использоваться высокополигональные трехмерные модели. Все повторяющиеся элементы должны генерироваться единоразово и повторно использоваться при последующих отображениях. 4.2.4.1.4. Управление памятью Требуется реализовать потоковую загрузку на устройство пользователя элементов карты и текстур. Загрузка данных целиком при старте приложения не допускается. Необходимо реализовать механизм очистки памяти от элементов, которые находятся вне области видимости камеры в течение заданного времени. 4.2.4.1.5. Требования к взаимодействию пользователя с интерфейсом компонента «Интерактивная карта» Программная реализация механизмов управление камерой (масштабирование и навигация) должна быть выполнена с поддержкой технологии WebAssembly (WASM). Элементы управления должны являться неотъемлемой частью интерактивной карты.

4.2.5. Развитие компонента администрирования (3 очередь) Должна быть выполнена доработка ролевой модели. Ролевая модель должна обеспечивать управление доступом к отдельным объектам Модуля СЦ и их элементам (атрибутам) с разграничением по видам транспорта, регионам и пр., в частности: – определение набора конкретных действий, доступных пользователям (выполняемых над объектом доступа, например, удаление записи, редактирование записи, формирование отчета и др.); – реализация возможности объединения пользователей в группы; – определение прав доступа для групп пользователей; – реализация интерфейса визуальной настройки прав доступа пользователей к объектам Модуля СЦ

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

4.5.3. Требования по диагностированию Модуля СЦ Диагностирование Модуля СЦ должно осуществляться путем анализа записей в системных журналах СУБД, операционных систем серверов, а также с помощью встроенных средств диагностирования общего программного обеспечения Модуля СЦ. Диагностированию подлежат: – сбои и нарушения функционирования технического обеспечения (серверов) Модуля СЦ; – сбои и нарушения функционирования системного программного обеспечения серверов, используемых для работы Модуля СЦ; – сбои и нарушения функционирования прикладного программного обеспечения серверов, используемых для работы Модуля СЦ; – случаи недоступности (отсутствия ответа) или некорректные ответы внешних систем; – сбои и нарушения функционирования СУБД; – сбои при выполнении регламентных операций резервного копирования. При возникновении аварийных ситуаций либо ошибок в программном обеспечении диагностические инструменты должны позволять сохранять набор информации, необходимой для идентификации и устранения проблемы. Модуль СЦ и ее компоненты должны обеспечивать возможность диагностики своей работоспособности с возможностью интеграции с модулем мониторинга АСУ ТК. Набор передаваемых журналов и метрик должен быть определен на этапе технического проектирования

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

4.2.6. Взаимосвязи с внешними автоматизированными системами (1 очередь) Способы взаимодействия с внешними информационными системами должны быть определены на этапе технического проектирования. Должны быть выполнены следующие доработки: – интеграции с информационными ресурсами в целях получения данных о движении подвижных ТС (воздушные суда, суда водного транспорта); – интеграция с информационным ресурсом в целях получения данных о событиях на железнодорожном транспорте. Реализация интеграций должна включать проектирование и реализацию интеграционных механизмов обмена данными с учетом доступных вариантов реализации, обеспечение защищенных способов взаимодействия, настройку отображения отдельных данных на карте (настройка слоев). Взаимодействия, имеющие каналы связи, выходящие за пределы контролируемой зоны взаимодействующих систем, считаются защищенными, если для их защиты используются программные и/или программно-аппаратные шифровальные (криптографические) средства, сертифицированные ФСБ России (далее – СКЗИ). Выбор СКЗИ, схемы подключения и требуемого класса криптостойкости должен производиться в соответствии с Техническими условиями на подключение к информационным ресурсам ФГБУ «СИЦ Минтранса России» и инструкциями по подключению пользователей к ресурсам инфраструктуры Головного центра обработки данных, утвержденных приказом директора ФБГУ «СИЦ Минтранса России» от 24.05.2024 № 21-ОД

4.3. Требования к оказанию услуг по технической поддержке Модуля СЦ 4.3.1. Общие требования к оказанию Услуг Техническая поддержка Модуля СЦ должна осуществляться с учетом требований постановления Правительства Российской Федерации от 06.07.2015 N 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации». Подрядчик обязан выполнять требования законодательства в сфере защиты информации, требования по защите информации, информационной безопасности, указанные в локальных нормативных актах ФГБУ «СИЦ Минтранса России», регламентирующих условия информационного взаимодействия, защиты информации и подключения к информационным ресурсам ФГБУ «СИЦ Минтранса России», участвующих в информационном взаимодействии в рамках оказания услуг по технической поддержке АСУ ТК в 2026 году

4.3.1.1. Требования к составу и содержанию услуг третьего уровня технической поддержки Оказание услуг по технической поддержке Системы осуществляется в рамках этапов в соответствии с календарным планом. Подрядчик в течение 5 рабочих дней с даты заключения Контракта должен предоставить со своей стороны, а Заказчик со своей стороны Матрицу ответственных за взаимодействия в соответствии с Приложением 1 к Регламенту оказания услуг по третьему уровню технической поддержки Модуля СЦ (далее – Регламент, Приложение В). Подрядчик в течение 10 рабочих дней с даты заключения Контракта должен провести мероприятия по организации третьего уровня технической поддержки в соответствии с Регламентом. Услуги по третьему уровню технической поддержки Модуля СЦ должны включать: – организацию Подрядчиком третьего уровня технической поддержки; – информационно-консультационную поддержку работников Заказчика; – решение инцидентов, связанных с работой ППО; – адаптационное, конфигурационное и коррекционное сопровождение Модуля СЦ (в рамках действующих программных модулей и функциональности); – устранение уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности

4.5.5. Требования к информационной безопасности Работы по защите информации/информационной безопасности, не включенные в состав настоящего раздела, требуемые в соответствии с требованиями постановления Правительства Российской Федерации от 06.07.2015 № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации», а также нормативно правовых актов в области защиты персональных данных и обеспечения безопасности объектов критической информационной инфраструктуры, будут проведены в рамках исполнения отдельного контракта, заключенного по результатам отдельной закупочной процедуры (не является частью данного ТЗ), включающего: – определение актуальных угроз безопасности информации и актуализация модели угроз безопасности информации (при необходимости); – выполнение требований о согласовании технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России в установленном порядке; – выполнение требований по устранению Подрядчиком замечаний и недостатков, в случае их выявления при согласовании Заказчиком технического задания на развитие информационной системы и (или) технического задания (частного технического задания) на развитие системы защиты информации информационной системы и модели угроз безопасности информации с ФСТЭК России и ФСБ России; – выполнение требований к классу защищенности ГИС, уровню защищенности персональных данных и категории значимости объекта КИИ РФ, установленных для Головного центра обработки данных ФГБУ «СИЦ Минтранса России» (далее – ГЦОД);

– определение перечня объектов защиты информационной системы; – описание (актуализированных) требований к системе защиты информации, а также к мерам защиты информации информационной системы в зависимости от установленных классов защищенности, уровня защищенности персональных данных и категории значимости объектов КИИ РФ (приказы ФСТЭК России № 21, 117, 239); – выполнение требований к мерам по защите ГИС от атак, направленных на отказ в обслуживании, в соответствии с пунктами 30, 34, 59, 63 Требований о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений, утвержденных приказом ФСТЭК России от 11.04.2025 № 117; – описание (актуализированных) требований по защите информации, подлежащих реализации в информационно телекоммуникационной инфраструктуре ГЦОД; – выполнение требований о применении сертифицированных средств защиты информации, включая их классы защиты и уровни доверия; – выполнение требований о запрете использования с 01.01.2025 органами (организациями) средств защиты информации странами происхождения, которых являются иностранные государства в соответствии с пунктом 6 Указа Президента Российской Федерации от 01.05.2022 № 250; – выполнение требований по обеспечению непрерывного взаимодействия с ГосСОПКА в установленном порядке;

4.3.1.2. Требования к общему порядку оказания услуг Техническая поддержка Модуля СЦ должна быть организована на трех уровнях: – первый и второй уровни технической поддержки организуется Заказчиком; – третий уровень технической поддержки организуется Подрядчиком. Перечень действий на каждом уровне технической поддержки указан в Таблице 5: Таблица 5 – Перечень действий на каждом уровне технической поддержки Уровень технической поддержки Доступные действия Условия передачи задачи на следующий уровень Первый уровень технической поддержки (далее – 1-й уровень) – принимает обращения (заявки) пользователей Модуля СЦ и работников Заказчика; – регистрирует обращения в Модуле СЦ регистрации обращений; – присваивает уникальный идентификационный номер, классифицирует обращения; – самостоятельно решает обращения, которые связаны с недостаточной квалификацией пользователей или настройками в рамках своей компетенции; – взаимодействует с пользователями Модуля СЦ при решении проблемы Передает обращение на второй уровень поддержки в случае невозможности решения на своем уровне Второй уровень технической поддержки (далее – 2-й уровень) – принимает обращения от 1-го уровня; – уточняет классификацию обращения в результате дополнительного анализа; – самостоятельно решает обращения в рамках своей компетенции; – осуществляет техническую и консультационную поддержку Модуля СЦ; – взаимодействует с сотрудниками 1-го и 3-го уровня и пользователями Модуля СЦ; – формирует заявки для 3-го уровня и контролирует исполнение Передает обращение на третий уровень поддержки в случае невозможности решения на своем уровне Третий уровень технической поддержки (далее – 3-й уровень) – принимает обращения от 2-го уровня; – обеспечивает выполнение требований, предъявляемых Контрактом и настоящим Техническим заданием к Услугам, оказываемым Подрядчиком Все поступающие обращения должны быть исполнены Подрядчиком

Для обеспечения взаимодействия с Заказчиком Подрядчик со своей стороны определяет ответственных лиц, уполномоченных в структуре Подрядчика за своевременное и качественное оказание Услуг в рамках настоящего ТЗ, а также контактную информацию ответственных лиц (телефон, электронную почту). Подрядчик должен предоставить Заказчику единый адрес электронной почты для приема обращений (заявок) в течение 3 (трех) рабочих дней после заключения Контракта. Указанный в настоящем пункте адрес электронной почты (способ направления обращений (заявок) применяется в случае сбоя в работе СРО Заказчика. Со своей стороны, Заказчик предоставляет Подрядчику перечень и контактную информацию (телефон, электронную почту) уполномоченных лиц для осуществления взаимодействия с указанием зон ответственности. О любых изменениях в контактной информации ответственных лиц Стороны должны уведомить друг друга в течение 1 (одного) рабочего дня с момента возникновения таких изменений посредством уведомления на электронную почту ответственных лиц и/или в письменной форме. В результате оказания услуг по настоящему ТЗ не должны быть изменены исходные коды, дистрибутивы и иные компоненты Модуля СЦ вне согласованных с Заказчиком изменений. Любые изменения исходных кодов, дистрибутивов и иных компонентов Модуля СЦ должны производиться только после согласования с Заказчиком уполномоченными лицами по электронной почте или иным заранее согласованным способом. Не должна быть ухудшена надежность и производительность Модуля СЦ. Оказание услуг по Контракту не должно нарушать требования к информационной безопасности, описанной в документации на Модуль СЦ

– выполнение требований по обеспечению в автоматизированном режиме с Национальной системой противодействия DDoS-атакам (НСПА) Центра мониторинга и управления сетью связи общего пользования ФГУП «ГРЧЦ» в рамках реализации мер по защите ГИС от атак, направленных на отказ в обслуживании; – детализированные требования к составу и содержанию работ по аттестации, а также к их результатам в соответствии с пунктами 13, 15 и 16 требований приказа ФСТЭК России от 29.04.2021 № 77 «Об утверждении Порядка организации и проведения работ по аттестации объектов информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну»

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

Подрядчик должен обеспечить реализацию и проведение внутренних проверок мер по разработке безопасного ПО, приведенных в Руководстве. Подрядчик должен провести анализ угроз безопасности информации программного обеспечения в соответствии с ГОСТ 58412-2019 «Защита информации. Разработка безопасного программного обеспечения. Угрозы безопасности информации при разработке программного обеспечения». Подрядчик должен провести испытания по выявлению уязвимостей в программном обеспечении Системы: · проведение статического анализа исходного кода программы; · проведение динамического анализа исходного кода программы; · проведение композитного анализа исходного кода и образов программы; · проведение фаззинг-тестирования программы, направленного на выявление в ней уязвимостей. Испытания по выявлению уязвимостей в программном обеспечении Системы должны быть проведены в рамках: · предварительных испытаний; · опытной эксплуатации; · приемочных испытаний

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

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

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

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

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

5. СОСТАВ И СОДЕРЖАНИЕ РАБОТ ПО РАЗВИТИЮ И ТЕХНИЧЕСКОЙ ПОДДЕРЖКЕ МОДУЛЯ СЦ (КАЛЕНДАРНЫЙ ПЛАН) - Сдача-приемка результатов выполненных работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная техническая документация, а также результаты работ предоставляются Заказчику в порядке, предусмотренном Контрактом и ТЗ, до размещения Подрядчиком в ЕИС документа о приемке. Документ о приемке размещается в ЕИС по каждому этапу в соответствии с условиями Контракта. Этапы выполнения работ по развитию Модуля СЦ приведены в Таблице 11. Таблица 11. Этапы выполнения работ по развитию Модуля СЦ. № этапа Наименование этапа Результат (отчетная документация) Срок исполнения этапа - - Значение характеристики не может изменяться участником закупки

1 Техническое проектирование Сопроводительным письмом предоставляются Заказчику: · Технический проект, включая следующие документы: – Ведомость технического проекта; – Ведомость машинных носителей информации – Пояснительная записка; – Описание информационного обеспечения системы; – Описание автоматизируемых функций; – Схема функциональной структуры; – Описание организации информационной базы; – Описание программного обеспечения; · Макеты экранных форм компонента «Интерактивная карта»; · Руководство по безопасной разработке программного обеспечения; · Документ о приемке Начало: с даты заключения контракта Окончание: не позднее 31.07.2026

2 Услуги по технической поддержке Модуля СЦ (с даты заключения контракта по 10.09.2026) По окончании оказания Услуг сопроводительным письмом предоставляются Заказчику: – Отчет об оказанных Услугах по технической поддержке; – Актуальные на дату окончания оказания Услуг по данному этапу исходные коды прикладного ПО на электронном носителе (в случае внесения изменений); – Инструкция по сборке и развертыванию (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство пользователя (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство администратора (в случае внесения изменений); – Документ о приемке Начало: с даты заключения контракта Окончание: не позднее 10.09.2026

3 Разработка программного обеспечения (1 очередь, пп. 4.2.1, 4.2.6 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ; – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 1 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 1 очереди; – Руководство по резервному копированию; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 16.09.2026

4 Разработка программного обеспечения (2 очередь, пп. 4.2.3, 4.2.4 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ. – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 2 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 2 очереди; – Руководство по резервному копированию; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 25.09.2026

5 Разработка программного обеспечения (3 очередь, пп. 4.2.2, 4.2.5 ТЗ), Предварительные испытания Сопроводительным письмом предоставляются Заказчику: – Исходные коды и дистрибутивы на электронном носителе; – Акт пуско-наладочных работ; – Инструкция по сборке и развертыванию; – Запись демонстрации процесса сборки исходного кода, развертывания и настройки ПО; – Руководство пользователя; – Руководство администратора; – Ведомость машинных носителей информации; – Ведомость эксплуатационных документов; – Общее описание Системы; – Программа и методика предварительных испытаний 3 очереди; – Протокол предварительных испытаний; – Акт о приемке в опытную эксплуатацию; – Программа опытной эксплуатации 3 очереди; – Руководство по резервному копированию; – Описание ролевой модели; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке Начало: с 01.08.2026 Окончание: не позднее 09.10.2026

6 Опытная эксплуатация (1 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акт о завершении опытной эксплуатации 1 очереди; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке 17.09.2026 Окончание: не позднее 26.10.2026

7 Опытная эксплуатация (2 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акт о завершении опытной эксплуатации 2 очереди; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке 26.09.2026 Окончание: не позднее 26.10.2026

8 Опытная эксплуатация (3 очередь) Сопроводительным письмом предоставляются Заказчику: – Журнал опытной эксплуатации; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Акт о завершении опытной эксплуатации 3 очереди; – Документ о приемке Начало: с 10.10.2026 Окончание: не позднее 26.10.2026

9 Приемочные испытания Сопроводительным письмом предоставляются Заказчику: – Программа и методика приёмочных испытаний; – Протокол приемочных испытаний; – Исходные коды и дистрибутивы на электронном носителе (при условии внесения изменений, с учетом доработок по результатам опытной эксплуатации и проведенных испытаний); – Комплект рабочей документации на Модуль СЦ (при условии внесения изменений, с учетом доработок по результатам опытной эксплуатации и проведенных испытаний); – Акт приемки Системы в эксплуатацию; – Акт приемки-передачи исключительных прав на объект; – Акты инструментальных проверок и артефакты в соответствии с Руководством по разработке безопасного программного обеспечения; – Документ о приемке; – Документы в соответствии с разделом 4.5.9 ТЗ; – Обеспечение гарантийных обязательств Начало: с 27.10.2026 Окончание: не позднее 10.11.2026

10 Услуги по технической поддержке Модуля СЦ (с 11.09.2026 по 15.12.2026) По окончании оказания Услуг сопроводительным письмом предоставляются Заказчику: – Отчет об оказанных Услугах по технической поддержке; – Актуальные на дату окончания оказания Услуг по данному этапу исходные коды прикладного ПО на электронном носителе (в случае внесения изменений); – Инструкция по сборке и развертыванию (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство пользователя (в случае внесения изменений); – Актуальное на дату окончания оказания Услуг по данному этапу руководство администратора (в случае внесения изменений); – Документ о приемке Начало: с 11.09.2026 Окончание: не позднее 15.12.2026

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

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

6.1. Сведения о гарантийном обслуживании Модуля СЦ Под гарантией понимается устранение Подрядчиком своими силами и за свой счет допущенных по его вине недостатков, выявленных после приемки выполненных Работ, как в работе самой Модуля СЦ, так и недостатков в отчетной документации. Если в период гарантийного срока обнаружатся недостатки, то Подрядчик обязан устранить их за свой счет, в сроки, установленные Заказчиком. Гарантийный срок в этом случае продлевается на период устранения недостатков. Срок гарантии: 1 год с даты приемки Заказчиком результатов исполнения Этапа № 9 контракта. Подрядчиком должны быть внесены соответствующие исправления в техническую и рабочую документацию (указанную в пунктах 5 и 6 настоящего ТЗ), связанные с устранением замечаний к работе Модуля СЦ или в случае выявления Заказчиком недостатков в такой документации в период гарантийного срока. Внесение изменений в документацию технического и рабочего проектирования осуществляется в соответствии с ГОСТ 2.503-2023 и ГОСТ Р 2.504-2021.

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

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

8. ТРЕБОВАНИЯ К СОСТАВУ И СОДЕРЖАНИЮ РАБОТ ПО ПОДГОТОВКЕ МОДУЛЯ СЦ К ВВОДУ В ЭКСПЛУАТАЦИЮ - По результатам проведения приемочных испытаний оформляется Протокол приемочных испытаний и Акт приемки в эксплуатацию. В случае, если взаимодействие с внешними системами не может быть проверено на средах постоянной эксплуатации взаимодействующих систем (по причине неготовности со стороны внешней системы или иным причинам), функции взаимодействия, разработанные в соответствии с требованиями ТЗ, должны быть проверены на тестовых данных с использованием программ-имитаторов взаимодействия. По результатам выполнения этапа приемочных испытаний должны быть подготовлены материалы для регистрации доработанной версии Модуля СЦ (объекта учета) в НФАП в соответствии с требованиями постановления Правительства Российской Федерации от 30 января 2013?г. №?62 «О национальном фонде алгоритмов и программ для электронных вычислительных машин» (с изменениями и дополнениями) в части обязательности размещения результатов работ в национальном фонде алгоритмов и программ для электронных вычислительных машин. Сдача-приемка результатов выполнения Работ производится с учетом особенностей, устанавливаемых Контрактом и статьей 94 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (электронная приемка). Отчетная, техническая документация, а также программное обеспечение предоставляется Заказчику в порядке, предусмотренном Контрактом и ТЗ до размещения Подрядчиком в Единой информационной системе в сфере закупок документа о приемке. Результаты проведения опытной эксплуатации, предварительных и приемочных испытаний должны быть зафиксированы в соответствующих протоколах и актах. Выявленные отклонения от настоящего ТЗ, оформляются как недостатки Модуля СЦ - - Значение характеристики не может изменяться участником закупки

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

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

9. ТРЕБОВАНИЯ К ДОКУМЕНТИРОВАНИЮ - 9.1. Общие требования Документация на Модуль СЦ должна быть разработана в составе, указанном в разделах 5-8 данного ТЗ, и должна удовлетворять требованиям комплекса стандартов и руководящих документов на автоматизированные системы: – ГОСТ Р 2.105-2019 в части оформления текстовых документов; – ГОСТ 34.201-2020 в части наименования и обозначения документов. Документация на Модуль СЦ должны оформляться на листах формата А4. Допускается для размещения рисунков и таблиц использование листов формата А3 с подшивкой по короткой стороне листа. Документы объемом более 25 (двадцати пяти) листов должны содержать информационную часть, состоящую из аннотации и содержания. Исходные коды должны быть представлены в 1 (одном) экземпляре на электронном носителе, отчетные материалы должны быть представлены в 2 (двух) экземплярах на бумажном носителе (по одному экземпляру для Заказчика и Подрядчика) и в 1 (одном) экземпляре на электронном носителе в формате документов DOCX и PDF. При разработке документов на Модуль СЦ допускается отклонение от требований комплекса стандартов, описанных выше. Документам на Модуль СЦ должны в обязательном порядке присваиваться уникальные децимальные номера в соответствии с порядком, установленном в ГОСТ 34.201-2020. Документ «Программа и методика предварительных испытаний» должен включать приложения с формой протокола предварительных испытаний и формой акта приемки в опытную эксплуатацию. Документ «Программа опытной эксплуатации» должен включать приложение с формой журнала опытной эксплуатации. Документ «Программа и методика приемочных испытаний» должен включать приложения с формой протокола приемочных испытаний и формой акта приемки в эксплуатацию - - Значение характеристики не может изменяться участником закупки

10. ИСТОЧНИКИ РАЗРАБОТКИ - 10.1. Список литературы Специальная литература для разработки ТЗ не использовалась. 10.2. Нормативно-методические документы Список используемых нормативно-методических документов представлен в разделе 1.6 технического задания. ? Приложение А Эскизы визуального оформления компонента «Интерактивная карта» - - Значение характеристики не может изменяться участником закупки

Приложение Б Параметры оказания услуг - Б.1. Базовые параметры оказания Услуг Базовые параметры оказания Услуг приведены ниже: – режимы оказания Услуг (таблица Б.1.1); – сроки предоставления отчетности (таблица Б.1.2). Таблица Б.1.1 - Режимы оказания Услуг № п/п Параметр Значение - - Значение характеристики не может изменяться участником закупки

1 Режим работы Системы Круглосуточно (24х7) 2 Режим доступности информационно-консультационной поддержки пользователей Системы 2.1 Прием и регистрация обращений (заявок) в СРО Регистрация обращений (заявок) производится круглосуточно в режиме 24х7, без праздников и выходных дней. Обработка заявок первой линией поддержки осуществляется в рабочие дни с 9 до 18 часов 2.2 Консультирование сотрудников Заказчика и пользователей Системы в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 3 Режим доступности по решению инцидентов, связанных с работой ППО: 3.1 - приоритет «Критический» Круглосуточно (24х7) 3.2 - приоритет «Высокий» Круглосуточно (24х7) 3.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 3.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4 Режим доступности услуг по адаптации, конфигурации и коррекционному сопровождению Системы 4.1 - приоритет «Критический» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.2 - приоритет «Высокий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 4.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 5 Режим доступности по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности 5.1 - приоритет «Критический» Круглосуточно (24х7) 5.2 - приоритет «Высокий» Круглосуточно (24х7) 5.3 - приоритет «Средний» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням) 5.4 - приоритет «Низкий» в рабочее время (период времени с 9:00 до 18:00 по Московскому времени по рабочим дням)

Таблица Б.1.2. Сроки предоставления отчетности, с момента получения запроса № п/п Параметр Значение 1 Предоставление отчета об оказанных услугах за произвольный период 10 рабочих дней 2 Предоставление подробной информации по инциденту с приоритетом «Критический» 16 рабочих часов 3 Предоставление актуализированной документации 10 рабочих дней

Б.2. Приоритеты и регламентные сроки решения обращений (заявок) В зависимости от уровня сбоя в работе Системы обращению (заявке) присваивается один из следующих приоритетов, а также в зависимости от приоритета обращения (заявки) устанавливаются следующие контрольные сроки решения в соответствии с таблицей ниже (Таблица Б.2.1). Таблица Б.2.1 – Приоритеты и регламентные сроки решения обращений (заявок) № п/п Приоритет Максимальное время реагирования Время решения (срок выполнения) Описание приоритета По информационно-консультационной поддержке сотрудников Заказчика и пользователей Системы 1 - не более 1 часа не более 10 часов - По решению инцидентов, связанных с работой ППО: 1 Критический не более 30 минут не более 4 часов - полная недоступность ППО; - недоступность ключевых функций - ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО; - невозможность информационного обмена с ППО для ИС более 4 часов 2 Высокий не более 1 часа не более 8 часов - ошибки/сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; - снижение быстродействия СПО (время отклика ППО на операции превышает 30 секунд); - недоступность управления правами и ролями пользователей 3 Средний не более 4 часов не более 24 часов - невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым -недоступность функции формирования отчетов 4 Низкий не более 8 часов не более 40 часов - отклонение в работе ППО, не влияющее на корректную работу функций; - другие сбои и ошибки, затрагивающие основные функции ППО

По адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) 1 Критический не более 40 минут не более 8 часов - изменения, необходимые при проведении аварийно-восстановительных работ для возобновления работоспособности Системы; - изменения, связанные с критичными ошибками, блокирующими возможность оказания государственных услуг и/или чтение и внесение данных в Систему 2 Высокий не более 1 часа не более 40 часов - изменения, относящиеся к обеспечению работоспособности основной функциональности Системы, устраняют выявленные дефекты в работе Системы, оказывающие существенное влияние на работу пользователей в Системе; - изменения, затрагивающие три и более подсистемы/модуля Системы для адаптации 3 Средний не более 4 часов не более 72 часов - изменения, связанные с развитием/улучшением/оптимизацией Системы и выводом новой функциональности в штатном режиме для одного-двух модулей/подсистем; - изменения, связанные с развитием интеграционных механизмов Системы, например обновление существующих и/или реализация новых видов сведений СМЭВ, обновление существующих и/или реализация новых API, адаптация и/или изменение механизмов импорта и экспорта данных Системы и т.д. 4 Низкий не более 8 часов не более 160 часов - изменения, связанные с ошибками/корректировкой/изменением в отображении информации в пользовательском графическом интерфейсе Системы (графика, текст, органы управления, элементы интерфейса)

По устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности 1 Критический не более 30 минут не более 24 часов - критические уязвимости, влияющие на возможную полную недоступность ППО, ключевых функций Системы, ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО без возможности восстановления работоспособности Системы. - Критический уровень CVSS > 8.0 2 Высокий не более 1 часа не более 84 часов - критические уязвимости, влияющие на ошибки и сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО. - Высокий уровень CVSS 5.0 - 8.0 3 Средний не более 4 часов не более 120 часов - уязвимости, влияющие на невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым - Средний уровень CVSS 2.0 - 4.9 4 Низкий не более 8 часов не более 160 часов - уязвимости, влияющие на отклонение в работе ППО, не влияющее на корректную работу функций; - другие сбои и ошибки, затрагивающие основные функции ППО - Низкий уровень CVSS < 2.0

Взаимодействие Заказчика и Подрядчика в части регистрации и контроля времени реагирования и решения обращения (заявки) осуществляется через СРО. Заказчик предоставляет Подрядчику доступ к СРО после заключения Контракта. Поступившие от разных пользователей заявки по поводу однотипных инцидентов или имеющие общую причину должны объединяться в одну заявку. Срок выполнения включает время диагностики инцидента, в ходе которого определяется причина инцидента (проблемы) и способ его устранения. Подрядчик должен обеспечить функционирование Модуля СЦ в соответствии с требованиями и параметрами, указанными в настоящем ТЗ и Регламенте оказании услуг. Основные параметры быстродействия типовых операций в Модуле СЦ указаны в таблице ниже (таблица Б.2.2). Таблица Б.2.2 - Параметры быстродействия Модуля СЦ № п/п Наименование параметра Значение (секунд) 1 Среднее время получения сообщения из очереди сообщений 10 2 Среднее время получения ответа от Системы 5 3 Среднее время открытия карточки реестра 5

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

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

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

Таблица 1 - Типы обращений (заявок) Тип обращения (заявки) Описание Запрос на обслуживание Подготовка SQL запроса к СУБД для решения прикладной задачи и д р. – запрос на любое действие, не являющееся запросом информации и несовершенный на основе происшествия, прямо или косвенно влияющего на работу Системы Консультация (входит в тип обращения (заявки) «Запрос на обслуживание») «Где взять / куда обратиться...?», «Как сделать / выполнить…», «Как это работает…?» - запрос, имеющий своей целью получение информационной поддержки Инцидент Разбор ошибок/сбоев и подготовка материалов (корректировочных релизов, инструкций) для Заказчика для устранения ошибок/сбоев, которые приводят к частичному и полному нарушению работоспособности всех или отдельных функций ППО. Подготовка изменения и материалов, необходимых для проведения аварийно-восстановительных работ для возобновления работоспособности Системы. ЗНИ Подготовка изменений, связанных с изменением, улучшением/оптимизацией Системы и выводом новой модифицированной функциональности в штатном режиме. Подготовка изменений, связанных с модификацией существующих и/или реализация новых интеграционных механизмов для получения/обработки данных внешних систем. Подготовка изменений графического интерфейса по требованиям Заказчика

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

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

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

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

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

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

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

3.4.1 Инцидент На рисунке 2 представлена функциональная схема регистрации и сопровождения обращений (заявок) типа «Инцидент». Рисунок 2 - Функциональная схема регистрации и сопровождения обращений (заявок) типа «Инцидент» 3.4.2 Запрос на обслуживание На рисунке 3 представлена функциональная схема регистрации и сопровождения обращения (заявки) типа «ЗНО». Рисунок 3 - Функциональная схема регистрации и сопровождения обращения (заявки) типа «ЗНО» 3.4.3 Запрос на изменение На рисунке 4 представлена функциональная схема регистрации и сопровождения обращений (заявок) типа «ЗНИ». Рисунок 4 - Функциональная схема регистрации и сопровождения обращений (заявок) типа «ЗНИ»

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

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

4 Формы обращений (заявок) на оказание услуг по технической поддержке Системы, заполняемые в СРО 4.1. Форма обращения (заявки) на оказание услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы При подаче обращения (заявки) типа «ЗНО» в СРО указывается (Таблица 5): Таблица 5 – Описание атрибутов формы обращения (заявки) на оказание услуги информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 5) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 5) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 5) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 5) Категория обращения: информационно-консультационная поддержка Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 5) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 5) Текст запроса на оказание услуги по информационно-консультационной поддержке сотрудников Заказчика Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 5)

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

4.2. Форма обращения (заявки) на оказание услуги по решению инцидентов, связанных с работой ППО При подаче обращения (заявки) типа «Инцидент» в СРО указывается (Таблица 6): Таблица 6 – Описание атрибутов формы обращения (заявки) на оказание услуги по решению инцидентов, связанных с работой ППО Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 6) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 6) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 6,) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 6) Категория обращения (заявки): инцидент Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 6) Приоритет изменения Время - одно из значений: Низкий, Средний, Высокий или Критический. Определяет, очередность решения обращения (заявки), ресурсы, привлекаемые для решения обращения (заявки), порядок/процедура действий при решении обращения (заявки) – поле СРО «Приоритет» (см. рисунок 6,)

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

На рисунке 6 приведена форма обращения (заявки) типа «Инцидент» в СРО. Рисунок 6 - Форма обращения (заявки) типа «Инцидент» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуги по решению инцидентов, связанных с работой ППО, заполненную в свободной форме

4.3. Форма обращения (заявки) на оказание услуг по адаптационному конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) При подаче обращения (заявки) типа «ЗНИ» в СРО указывается (Таблица 7): Таблица 7 – Описание атрибутов формы обращения (заявки) на оказание услуг по адаптационному, конфигурационному и коррекционному сопровождению Системы Атрибут Описание Дата направления обращения (заявки) Дата и время поступления обращения (заявки) в СРО – поле СРО «Создал» (см. рисунок 10) Регистрационный номер обращения (заявки) Номер обращения (заявки), присваиваемый СРО автоматически при поступлении обращения (заявки) (см. рисунок 9) ФИО инициатора обращения (заявки) Персональная информация об инициаторе, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 10) Контактные сведения инициатора обращения (телефон, адрес электронной почты) Контактные данные инициатора, от которого поступило обращение (заявка) – поле СРО «Контакт» (см. рисунок 10) Категория обращения (заявки): запрос на изменение Тип обращения (заявки) в соответствии с перечнем, приведенном в п. 3.1 настоящего Регламента – поле СРО «Тип запроса» (см. рисунок 7) Приоритет изменения Время, очередность решения обращения (заявки), ресурсы, привлекаемые для решения обращения (заявки), порядок/процедура действий при решении обращения (заявки) – поле СРО «Приоритет» (см. рисунок 7) Тип изменения Справочник, классифицирующий типовые запросы характерные для Системы – поле СРО «Предмет обращения» (см. рисунок 7) Краткое содержание обращения (заявки) Краткое описание фиксируемого обращения, отражающее суть обращения – поле СРО «Заголовок» (см. рисунок 7) Текст запроса на оказание услуги по адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) Подробное описание, содержащее развернутую информацию по обращению (заявке) – поле СРО «Описание» (см. рисунок 7)

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

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

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

На рисунке 8 приведена форма обращения (заявки) типа «Инцидент» в СРО. Рисунок 8 - Форма обращения (заявки) типа «Инцидент» в СРО В случае недоступности СРО по техническим причинам Заказчик направляет в службу технической поддержки Исполнителя обращение (заявку) на оказание услуги по устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности, заполненную в свободной форме

Приложение 1 к Регламенту Матрица ответственных за взаимодействия в рамках выполнения работ по техническому сопровождению Системы Таблица 1 – Ответственные за взаимодействия в рамках выполнения работ по техническому сопровождению Системы со стороны Исполнителя ФИО Должность Адрес электронной почты Телефон — — — Общий контакт

Приложение 2 к Регламенту Приоритеты и регламентные сроки решения обращений (заявок) Приоритеты и регламентные сроки решения обращений (заявок) приведены в таблице 1. Таблица 1 – Приоритеты и регламентные сроки решения обращений (заявок) № п/п Приоритет Максимальное время реагирования Время решения (срок выполнения) Описание приоритета

По информационно-консультационной поддержке сотрудников Заказчика и пользователей Системы 1 – не более 1 часа не более 10 часов –

По решению инцидентов, связанных с работой ППО 1 Критический не более 30 минут не более 4 часов – полная недоступность ППО; – недоступность ключевых функций; – ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО; – невозможность информационного обмена с ППО для ИС более 4 часов 2 Высокий не более 1 часа не более 8 часов – ошибки/сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; – снижение быстродействия СПО (время отклика ППО на операции превышает 30 секунд); – невозможность управления правами и ролями пользователей 3 Средний не более 4 часов не более 24 часов – невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым недоступность функции формирования отчетов 4 Низкий не более 8 часов не более 40 часов – отклонение в работе ППО, не влияющее на корректную работу функций; – другие сбои и ошибки, затрагивающие основные функции ППО

По адаптационному, конфигурационному и коррекционному сопровождению Системы (в рамках действующих программных модулей и функциональностей) 1 Критический не более 40 минут не более 8 часов – изменения необходимые при проведении аварийно-восстановительных работ для возобновления работоспособности Системы; – изменения, связанные с критичными ошибками, блокирующими возможность оказания государственных услуг и/или чтение и внесение данных в Систему 2 Высокий не более 1 часа не более 40 часов – изменения относящиеся к обеспечению работоспособности основной функциональности Системы, устраняют выявленные дефекты в работе Системы, оказывающие существенное влияние на процесс оказания государственных услуг и работу пользователей в Системе; – изменения, затрагивающие три и более подсистемы/модуля Системы для адаптации 3 Средний не более 4 часов не более 72 часов – изменения, связанные с развитием/улучшением/оптимизацией Системы и выводом новой функциональности в штатном режиме для одного-двух модулей/подсистем; – изменения, связанные с развитием интеграционных механизмов Системы, например, обновление существующих и/или реализация новых видов сведений СМЭВ, обновление существующих и/или реализация новых API, адаптация и/или изменение механизмов импорта и экспорта данных Системы и т.д. 4 Низкий не более 8 часов не более 160 часов – изменения, связанные с ошибками/ корректировкой/изменение в отображении информации в пользовательском графическом интерфейсе Системы (графика, текст, органы управления, элементы интерфейса)

По устранению уязвимостей в компонентах (библиотеках) ППО в соответствии с требованиями к обеспечению информационной безопасности 1 Критический не более 30 минут не более 24 часов – критические уязвимости, влияющие на возможную полную недоступность ППО, ключевых функций Системы, ошибки/сбои, которые приводят к полной неработоспособности всех функций ППО без возможности восстановления работоспособности Системы; – Критический уровень CVSS > 8.0 2 Высокий не более 1 часа не более 84 часов – критические уязвимости, влияющие на ошибки и сбои, которые приводят к частичному нарушению работоспособности или недоступности отдельных функций ППО; – Высокий уровень CVSS 5.0 - 8.0 3 Средний не более 4 часов не более 120 часов – уязвимости, влияющие на невозможность выполнения ключевых функций для одного пользователя и/или для одного или нескольких объектов данных, обладающих специфическими параметрами, и/или одной или нескольких функций Системы, не относящихся к ключевым; – Средний уровень CVSS 2.0 - 4.9 4 Низкий не более 8 часов не более 160 часов – уязвимости, влияющие на отклонение в работе ППО, не влияющее на корректную работу функций; – другие сбои и ошибки, затрагивающие основные функции ППО; – Низкий уровень CVSS < 2.0

Приложение Г Форма Отчета об оказанных услугах Отчет об оказанных услугах за этап «наименование этапа» в период с «__» _________ по «__» _________. № п/п Наименование услуги Общее количество Номер ОРС Краткое Описание Время реагирования по ТЗ Время реагирования фактическое Время решения по ТЗ Время решения фактическое Результат соблюдения времени реагирования Результат соблюдения времени решения Примечание 1 Услуги по информационно-консультационной поддержке работников Заказчика 2 546782 Консультация по работе Модуля СЦ 1 2 10 часов 11 часов Нет Нет 567123 Консультация по схеме БД 1 1 10 часов 1 час Да Да 2 … … Заказчик Подрядчик /Должность/ /Должность/ ____________________ /Ф.И.О/ ___________________ /Ф.И.О/ М.П. М.П. «_____»_______________________202_г. «_____»_______________________202_г

Приложение 1 к Отчету об оказанных услугах Журнал обращений (заявок) на оказание услуги по информационно-консультационной поддержке пользователей Системы (шаблон) Наименование Исполнителя в этапе «наименование этапа» в период с ________________ по _______________ оказал(о) Услугу по поддержке пользователей Системы в объеме, указанном в Таблице 1 Таблица 1 - Журнал обращений (заявок) пользователей Системы № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. ИТОГО зарегистрировано: Всего обращений (заявок): ________ ИТОГО решено: Всего обращений (заявок): ________

Приложение 2 к Отчету об оказанных услугах Журнал обращений (заявок) по решению инцидентов, связанных с работой ППО (шаблон) Наименование Исполнителя в этапе «наименование этапа» в период с ________________ по _______________ оказал(о) Услугу по решению инцидентов в объеме, указанном в Таблице 1. Таблица 1 - Журнал по решению инцидентов № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. ИТОГО зарегистрировано: Всего инцидентов: ________ ИТОГО решено: Всего инцидентов: ________

Приложение 3 к Отчету об оказанных услугах Журнал обращений (заявок) выполнения адаптационного, конфигурационного и коррекционного сопровождения Системы (шаблон) Журнал выполнения адаптации, конфигурации и коррекции Системы сформирован за этап «наименование этапа» в период с «__» _________ по «__» ____________ и представлен в таблице ниже (Таблица 1). Таблица 1 - Журнал выполнения адаптации, конфигурации и коррекции сопровождения Системы № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. Количество выполненных заявок за этап: ________

Приложение 4 к Отчету об оказанных услугах Журнал обращений (заявок) по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности (шаблон) Журнал обращений (заявок) по устранению уязвимостей в ППО в соответствии с требованиями к обеспечению информационной безопасности сформирован за этап «наименование этапа» в период с «__» _________ по «__» ____________ и представлен в таблице ниже (Таблица 1). Таблица 1 - Журнал выполнения заявок по устранению уязвимостей в ППО № п/п Дата и время регистрации обращения (заявки) Номер записи СРО Статус Инициатор обращения (заявки) Вид обращения (заявки) Краткое описание обращения (заявки) ФИО Исполнителя Дата и время решения обращения (заявки) 1. 2. Количество выполненных заявок за этап: ________

Приложение Д Форма Протокола проверки результатов организационно-штатных и подготовительных мероприятий (шаблон) Протокол проверки результатов организационно-штатных и подготовительных мероприятий Настоящий Протокол содержит результаты проверки организационно-штатных и подготовительных мероприятий, проведенных Исполнителем (Таблица Д.1). Таблица Д.1. Протокол проверки результатов № Мероприятия Подготовительного этапа Результат проверки 1. Определить и направить Заказчику документ «Ответственные за взаимодействия в рамках выполнения работ по техническому сопровождению Системы со стороны Исполнителя». Документ содержит контактную информацию (ФИО, должность, адрес электронной рабочей почты, номер телефона) не менее чем о 2 лицах, ответственных за оказание услуг со стороны Подрядчика Выполнено/Не выполнено 2. Обеспечить подключение специалистов Подрядчика к Системе Выполнено/Не выполнено 3. Обеспечить подключение специалистов Подрядчика к СРО Выполнено/Не выполнено Заказчик Подрядчик /Должность/ /Должность/ ____________________ /Ф.И.О/ ___________________ /Ф.И.О/ М.П. М.П. «_____»_______________________202_г. «_____»_______________________202_г

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

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

Уровень технической поддержки Организационно-структурная часть технической поддержки, имеющая определённые организационно-нормативными документами зоны ответственности, обязанности, а также временные нормативы, в течение которых эти обязательства должны выполняться либо эскалироваться на следующий уровень технической поддержки Услуги Услуги по технической поддержке Информационно-аналитической системы регулирования на транспорте АСУ ТК ФИО Фамилия, имя, отчество Эскалация Процедура повышения внимания к обращению (заявке) путем повышения его приоритета и/или передачи на следующий уровень технической поддержки, а также привлечение ролей, которые могут принимать решения без передачи на следующий уровень технической поддержки API Англ. Application Programming Interface — программный интерфейс приложения, интерфейс прикладного программирования — описание способов (набор классов, процедур, функций, структур или констант), которыми одна компьютерная программа может взаимодействовать с другой программой

CVSS Англ. Common Vulnerability Scoring System - открытый стандарт, используемый для расчета количественных оценок уязвимости в безопасности компьютерной системы, обычно с целью понять приоритет ее исправления. В современном инструментарии информационной безопасности используется версия 3.0 и выше с дополнительными метриками к базовым оценкам ID Англ. Identifier – идентификатор, уникальный признак объекта, позволяющий отличать его от других объектов, то есть, идентифицировать SLA Англ. Service Level Agreement - утвержденные условия по обработке обращения (заявки) с установленными метриками времени, которые определяют пороговые значения для эскалации в зависимости от статуса обращения (заявки) (например, время реакции – время от регистрации до осуществления первичной обработки, время решения – время от регистрации обращения (заявки) до его решения и т.д.) SQL Англ. Structured Query Language — «язык структурированных запросов», — декларативный язык программирования, применяемый для создания, модификации и управления данными в реляционной базе данных, управляемой соответствующей СУБД

1 Общие сведения 1.1 Полное наименование Услуг Оказание услуг по технической поддержке Модуля СЦ АСУ ТК в 2026 году. 1.2 Предмет Регламента оказания услуг Требования Технического задания

2 Общие положения 2.1 Цель и задачи оказания услуг Целью технической поддержки Системы является обеспечение ее стабильного и безопасного функционирования и эксплуатации, предупреждение, выявление и устранение сбоев в работе Системы и минимизация их неблагоприятного влияния. Для достижения поставленной цели требуется решение следующих задач: 1. Обеспечение информационно-консультационной поддержки сотрудников Заказчика и пользователей Системы. 2. Поддержание параметров функционирования ППО Системы, удовлетворяющих требованиям производственных процессов, включая их непрерывность. 3. Обеспечение бесперебойного функционирования ППО и своевременное устранение сбоев и аварийных ситуаций в Системе. 4. Своевременное устранение уязвимостей при выявлении таковых, в соответствии с требованиями к обеспечению информационной безопасности. 5. Адаптация, конфигурирование, коррекция программного обеспечения в соответствии с изменениями нормативно-правовой базы и запросами уполномоченных сотрудников органов государственной власти, включая выполнение процедур тестирования и участие в обновлениях ППО на стендах Заказчика. 6. Обеспечение сохранения работоспособности ППО в изменяемой среде эксплуатации. 7. Ведение документации по настоящему контракту и инициирование актуализации документации на Систему по результатам обработки запросов Заказчика и внесения соответствующих изменений в ППО

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

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

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

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

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

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

Размер обеспечения заявки: 1 065 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, ОКЦ № 1 ГУ Банка России по ЦФО//УФК ПО Г. МОСКВЕ, г Москва, к/c 40102810545370000003

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

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

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

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

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

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

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

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

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

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

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

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

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

Срок, на который предоставляется гарантия и (или) требования к объему предоставления гарантий качества товара, работы, услуги: Гарантийный срок: 1 год с даты приемки Заказчиком результатов исполнения Этапа № 9 контракта. Гарантийные обязательства: Под гарантией понимается устранение Подрядчиком своими силами и за свой счет допущенных по его вине недостатков, выявленных после приемки выполненных Работ, как в работе самой Модуля СЦ, так и недостатков в отчетной документации. Если в период гарантийного срока обнаружатся недостатки, то Подрядчик обязан устранить их за свой счет, в сроки, установленные Заказчиком. Гарантийный срок в этом случае продлевается на период устранения недостатков. Подрядчиком должны быть внесены соответствующие исправления в техническую и рабочую документацию (указанную в пунктах 5 и 6 Технического задания), связанные с устранением замечаний к работе Модуля СЦ или в случае выявления Заказчиком недостатков в такой документации в период гарантийного срока. Внесение изменений в документацию технического и рабочего проектирования осуществляется в соответствии с ГОСТ 2.503-2023 и ГОСТ Р 2.504-2021.

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

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

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

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

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

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

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

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

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

Документы

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

Документы

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